Built a quick extension attribute for Jamf Pro environments to check if TouchID is enabled and report back a string in $result – this could easily be modified and so I commented a few pointers for environments that might need to modify it (e.g. to check for user-level as it’s currently system-level). To see/have the code, check https://github.com/krypted/TouchID_check.
krypted January 18th, 2017
Apple recently introduced a laptop with the same fingerprint technology found in an iPhone as well as a T-1 chip to take the sapphire Touch ID sensor information and store it securely, non-reversibly(ish), on the machine. OS X 10.12 now comes with a tool that can manage the fingerprints, stored as keys, on the device. The bioutil command is simple to use, with a few options that are mostly useful for enabling different features of the new technology.
Let’s get started by enabling the unlock option, using the -r option to see if Touch ID is enabled for the current user and -s to check the system as well:
bioutil -r -s
Now let’s enable Touch ID to be able to unlock the system, with -u (provided it’s not already enabled):
If you’ll be using ApplePay, also use -a (on a per-user basis):
Next, let’s enables Touch ID to unlock the system for the current user:
bioutil -w -u 1
This user will obviously need to provide their fingerprint in order to use Touch ID. Once done, let’s see how many fingerprints they’ve registered using the -c option (which checks for the number of fingerprints registered by the currently enrolled user):
Now let’s delete all fingerprints for the current user (note that they’re not reversible so you can’t actually look at the contents):
Next, we’ll use sudo to remove all fingerprints for all users (since we’re crossing from user land, we’ll need to provide a password):
sudo bioutil -p -s
Instead, we could have targeted just deleting the fingerprints that had been registered for user 1024, using -s and -d together, followed by the actual UID (which also requires sudo – as with all -s option combos):
sudo bioutil -s -d 1024
Now let’s disable Touch ID for the computer, using -w to write a config, and that -u from earlier, setting it to 0 for off:
sudo bioutil -w -s -u 0
And viola, you’re managing the thing. Throw these in an Extension Attribute or in Munki and you’re managing/checking/knowing/reporting/all the thingsings! Enjoy!
krypted December 16th, 2016
Automating OS installations is going to eventually be about as easy on macOS as it is in iOS (er, if you have MDM that is). But in the meantime, it’s getting a bit more challenging. The obvious way Apple would prefer this to happen these days is via the startosinstall command that first shipped with El Capitan and with brtool getting moved around all the time, and becoming less of a thing, there’s one quick and easy thing you can do:
sudo "/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS Sierra.app" --agreetolicense --nointeraction --volume /Volumes/Macintosh\ HD
In the above command, we’ve dropped “Install macOS Sierra.app” on a machine. While you’d guess that it would find the application path based on its own surname, we went ahead and supplied it as that seems to basically be a thing. Basically, –agreetolicense keeps us from having to run some expect scripts to accept a license agreement, –nointeraction suppresses as many of the screens as possible, and –volume allows us to install to any volume we’d like. This isn’t fully automated, but I have been able to layer in some more logic to quit apps before the script fires and then expect out other items from the script to automate a restart, watching for osinstallersetupd as a key.
This is all a bit bulkier than just using something like createOSXinstallPkg but it’s important to mention that there are a number of system components that are allowed for in SIP that use osinstallersetupd and so this blessed mechanism is likely the future until you can trigger an OS upgrade (and update I suppose) using an MDM command.
krypted October 23rd, 2016
macOS Server 5.2 (for Sierra) comes with the /usr/sbin/serverinfo command (introduced in Mountain Lion Server). The serverinfo command is useful when programmatically obtaining information about the very basic state of an Apple Server.
The first option indicates whether the Server app has been downloaded from the app store, which is the –software option:
When used, this option reports the following if the Server.app can be found:
This system has server software installed.
Or if the software cannot be found, the following is indicated:
This system does NOT have server software installed.
The –productname option determines the name of the software app:
If you change the name of the app from Server then the server info command won’t work any longer, so the output should always be the following:
The –shortversion command returns the version of the Server app being used:
The output will not indicate a build number, but instead the version of the app on the computer the command is run on:
To see the build number (which should iterate with each update to the Server app from the Mac App Store, use the –buildversion option:
The output shows the build of server, which doesn’t necessarily match the OS X build number:
Just because the Server app has been downloaded doesn’t mean the Server setup assistant has been run. To see if it has, use the –configured option:
The output indicates whether the system is running as a server or just has the app installed (e.g. if you’re using it to connect to another server:
This system has server software configured.
You can also output all of the information into a single, easy to script against property list using the –plist option:
The output is a list of each of the other options used:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
The Server Root can reside in a number of places. To see the path (useful when scripting commands that are relative to the ServerRoot:
By default, the output is as follows, which is basically like a dirname of the ServerRoot:
You can also see whether the system is running on actual hardware desgnated by Apple for servers using the –hardware option:
The output simply indicates if the hardware shipped with OS X Server on it from Apple:
This system is NOT running on server hardware.
The –perfmode option indicates whether or not the performance mode has been enabled, dedicating resources to binaries within the Server app:
If the performance mode has not been enabled then the output will be as such:
Server performance mode is NOT enabled.
To enable performance mode, you can also use serverinfo. This is the only task that the command does that can make any changes to the system and as such is the only time you need to elevate privileges:
sudo serverinfo —setperfmode 1
Note: This isn’t really working for me right now, but I filed a radar and guessing it will shortly.
Or set the boolean value back to 0 to disable.
sudo serverinfo —setperfmode 0
Note: This isn’t really working for me right now, but I filed a radar and guessing it will shortly.
krypted October 2nd, 2016
Posted In: Mac OS X Server
A little while back, I did a little writeup on how the OS X Caching Server caches updates at http://krypted.com/mac-security/how-the-os-x-caching-server-caches-updates/. The goal was to reverse engineer parts of how it worked for a couple of different reasons. The first was to get updates for devices to cache to my caching server prior to 15 people coming in before it’s cached and having caching it down on their own.
So here’s a little script I call precache. It’s a little script that can be used to cache available Apple updates into an OS X Server that is running the Caching Service. To use, run the script followed by the name of the model. For example, for an iPad 2,1, you would use the following syntax:
sudo python precache.py iPad2,1
To eliminate beta operating systems from your precache,use the –no-beta argument:
sudo python precache.py iPad2,1 --no-beta
I’ll probably add some other little things nee and there, this pretty much is what it is and isn’t likely to become much more. Unless someone has a good idea or forks it and adds it. Which would be cool. Enjoy.
krypted April 25th, 2016
There are a lot of scripts stored on github. And you can run them directly by curling them into bash. To do so, you’ll need a link to the raw script (using the github page with the URL of the script brings in all the cruft, so you’ll need to find the raw text). To grab that, click on the page with the script and then right-click on Raw, as seen here:
Then, throw out a bash command followed by < and then the URL you just copied into your clipboard in parenthesis:
bash <(curl -Ls https://github.com/krypted/resetsoftwareupdate/raw/master/resetsoftwareupdate.sh)
krypted April 20th, 2016
When I’m working on a little bash script, I’ll often make a backup, each time I save and test. Then I can revert back, if I need to. The syntax I’ll use is to cp and then curly-bracket the output into .bak files (that’s a 90s era file extension I use for such nonsense):
So if I’m writing a script called MYSCRIPT.sh:
The resultant backup of the script is MYSCRIPT.sh.bak.
krypted March 22nd, 2016
Someone hands you a USB drive. You put it in your computer and you can’t access anything on it. You are running an imaging lab and you want to backup or troubleshoot a device before you re-image it, but you can’t access certain files. Obviously, you can sudo. But, you can also simply disable permissions on that volume (which, like getting someone to make you a sandwich, requires sudo of course).
The command used to enable and disable permissions on a volume is vsdbutil, located at /usr/sbin/vsdbutil. And there’s a LaunchDaemon at /System/Library/LaunchDaemons/com.apple.vsdbutil.plist that interacts with diskarbitrationd so that when a volume is mounted, it is marked as having permissions activated or deactivated (which is basically “Ignore Permissions” at the Finder).
To use vsdbutil to enable “Ignore Permissions”, use the -d flag followed by the path to the volume:
sudo /usr/sbin/vsdbutil -d /Volumes/Myvolume
To then enable (or activate, thus the a) permissions again, use the -a flag:
sudo /usr/sbin/vsdbutil -a /Volumes/Myvolume
You can also run the -c to see the status for a given path:
sudo /usr/sbin/vsdbutil -c /Volumes/Myvolume
And last but certainly not least if you’re working on a lot of volumes, the -i option will enable permissions on all mounted HFS and HFS+ volumes:
sudo /usr/sbin/vsdbutil -i
Overall, it’s very easy to send these commands using a positional parameter (e.g. $1) to a script, performing a mount, some operation (backup, reimage, restore, repair some corrupted data, etc).
Note: You can’t Ignore Permissions of FAT or FAT32 volumes using the command line or a Finder Get Info screen.
krypted December 1st, 2015
Apple Configurator 2 is now out and there are some really cool new features available to people deploying Apple Configurator. Apple Configurator 2 now supports feature called Blueprints. A Blueprint is a set of configuration options (such as profiles, apps, etc) that are easily applied to devices by applying a given Blueprint. So basically a canned set of options that can be configured on a device. For example, you can have a Blueprint called Training that have training apps and settings for a training room network and then you can have another Blueprint for Kiosks, that have different apps for a kiosk, one app for a kiosk, an SSID for a kiosk wireless network, and throw that single app into Single User Mode. Pretty cool, since before you needed to have all this stuff in, select the appropriate options and then deploy them. Now, you can more quickly train student workers or deployment staff to get devices initially configured before deployment them in a school or company.
To install the new Apple Configurator, open up the App Store, search for Apple Configurator and then click on the Get button. It’s only 61MB so installs quickly.
Once installed, open Apple Configurator 2 from /Applications.
Another great new feature of Apple Configurator 2 is the command line interface for Apple Configurator: cfgutil. Go ahead and click on the Apple Configurator 2 menu and select Install Automation Tools from the menu.
Once installed, you’ll find cfgutil at /usr/local/bin/cfgutil. I’ve been working on some documentation for using the command line interface, so I’ll get it posted when I’m done. But for now, let’s go back to Apple Configurator 2 and click on Blueprints to make a new Blueprint.
From Blueprints, click on your new Blueprint.
From the Blueprint. you can add Apps, create Profiles and assign devices. Here, we’re going to click Profiles in the sidebar. Initially there won’t be any Profiles on the device. Click on New.
Click on File then click on New Profile.
The General screen just requires a new name. There are a few new options for profiles, as you can see by clicking on Restrictions and scrolling to the bottom.
There are a lot of new options for iOS devices. Many require device supervision. I’ll cover setting up devices and enabling supervision later. Using Advanced options, you can also clear passcode, obtain unlock tokens, start single app mode, and enable encrypted backups. Plenty of fun things to cover!
krypted October 1st, 2015
SSH allows administrators to connect to another computer using a secure shell, or command line environment. ARD (Apple Remote Desktop) allows screen sharing, remote scripts and other administrative goodness. You can also connect to a server using the Server app running on a client computer. To enable any or all of these, open the Server app (Server 5 for El Capitan and Yosemite), click on the name of the server, click the Settings tab and then click on the checkbox for what you’d like to enter.
All of these can be enabled and managed from the command line as well. The traditional way to enable Apple Remote Desktop is using the kickstart command. But there’s a simpler way in OS X El Capitan Server (Server 5). To do so, use the serveradmin command. To enable ARD using the serveradmin command, use the settings option, with info:enableARD to set the payload to yes:
sudo serveradmin settings info:enableARD = yes
Once run, open System Preferences and click on Sharing. The Remote Management box is then checked and the local administrative user has access to ARD into the host.
There are also a few other commands that can be used to control settings. To enable SSH for administrators:
sudo serveradmin settings info:enableSSH = yes
When you enable SSH from the serveradmin command you will not see any additional checkboxes in the Sharing System Preferences; however, you will see the box checked in the Server app. To enable SNMP:
sudo serveradmin settings info:enableSNMP = yes
Once SNMP is enabled, use the /usr/bin/snmpconf interactive command line environment to configure SNMP so you can manage traps and other objects necessary.
Note: You can’t have snmpd running while you configure SNMPv3. Once SNMPv3 is configured snmpd can be run.
To allow other computers to use the Server app to connect to the server, use the info:enableRemoteAdministration key from serveradmin:
sudo serveradmin settings info:enableRemoteAdministration = yes
To enable the dedication of resources to Server apps (aka Server Performance Mode):
sudo serveradmin settings info:enableServerPerformanceMode = yes
krypted September 22nd, 2015