Enabling Accessibility for ADPassMon in Mavericks

I’m a fan of ADPassMon.

It’s especially useful for FileVault 2 encrypted Macs, where the user will never see the
“Your password will expire in X days” notification at the loginwindow, since they are directly taken to their Desktop from the pre-boot authentication.

Now, Mavericks (10.9.”0″) appears to have a bug where it will not show the password expiry notification even if you’re not using FileVault 2. Another reason to use ADPassMon.

ADPassMon has a built in shortcut to change the user’s password

Screen Shot 2013-11-14 at 16.31.19For this to work, you need to grant it access to “control your computer” in the Accessibility options in System Preferences.

Now these options have changed a bit in Mavericks.
In Mountain Lion it used to look like this:

Accessiblity 10.8It was sufficient for ADPassMon the check the “Enable access for assistive devices” checkbox, which could be done simply by running

sudo touch /private/var/db/.AccessibilityAPIEnabled

In Mavericks however, the option to allow ADPassMon to do it’s thing has moved to
System Preferences -> Security & Privacy -> Privacy:

Accessibility 10.9These settings are stored in
/Library/Application Support/com.apple.TCC/TCC.db
which is another SQLite3 database.

Chances are, you want to enable this programmatically.
Otherwise your users get presented with this message:

Screen Shot 2013-11-14 at 4.29.48 PMSelecting “Open System Preferences” will take them here:

Screen Shot 2013-11-14 at 4.29.55 PMSee the closed lock?
Now you might give your users access to the Security & Privacy settings by messing with the

security authorizationdb

command, but is that really a good idea?

 

The alternative is to modify the /Library/Application Support/com.apple.TCC/TCC.db database before installing ADPassMon.

When packaging up ADPassMon, add a preinstall script with these two commands:

sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "delete from access where client='org.pmbuko.ADPassMon';"

sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT INTO access VALUES('kTCCServiceAccessibility','org.pmbuko.ADPassMon',0,1,1,NULL);"

If you’re using Composer to build your package, it might look like this:

Screen Shot 2013-11-14 at 16.42.10

Thanks to spikehed for finding this trick here, and of course Peter Bukowinski for creating ADPassMon!

Deploying Mavericks via Casper Self Service

Disclaimer: All credit for this method goes to
Greg Neagle for creating the amazing createOSXinstallPkg
and Rich Trouton for his First Boot Package Install.pkg.

Check the linked pages (if you don’t know them yet) to get an understanding of how we’re putting the pieces together.

Of course it would be possible to deploy the Mavericks installer as it is from the App Store.
However, as we learned, upgrading to Mavericks removed Java from your Mac, and the user would be greeted with the iCloud sign-in dialogue once the upgrade is completed.

Maybe you don’t want that. And maybe you want to add a “postupgrade” script to the installer to make Mavericks fit your environment. Maybe you want to tweak the authorization database since /etc/authorization is deprecated in Mavericks…

Lots of reasons not to go with the standard installer.
I’ll try to explain how to do this.

Requirements:

 

Building a payload-free package with Composer

We need our postupgrade configuration script to be wrapped in a pkg.
Launch Composer and create a new empty package.
Click the triangle next to your package in the sidebar, then right-click on “Scripts”, select “Add Shell Script” -> “Postinstall” or “Postflight”.

Composer1Then paste your script contents into the script editor and save it.

Composer2Select “Build as PKG” to finish the build process.

 

Preparing First Boot Package Install.pkg

Right-click the package you downloaded, select “Show Package Contents” and navigate to
/Contents/Resources/fb_installers
You will find six numbered folders in there.
Each pkg we want to install on first boot goes into one folder.

Payload-free package to run the configuration script:

FBPI1Java for OS X installer:

FBPI2

Of course you don’t need to have exactly six pkgs, however you can add additional folders as needed. Remember the 350MB size limit!

 

Building the Mavericks installer pkg

Here’s where createOSXinstallPkg comes into play.
We’re going to bake our prepared First Boot Package Install.pkg into the Mavericks installer.
To do that, fire up Terminal and run

sudo /path/to/createOSXinstallPkg --source /path/to/Install\ OS\ X\ Mavericks.app --pkg /path/to/First\ Boot\ Package\ Install.pkg --output /path/to/Output.pkg

createOSXinstallPkg1Grab a coffee while it does its thing.

 

Deploying the Mavericks installer via Self Service

Once your package is ready, upload it to Casper Admin.
We’re almost done!

Now we’ll create a policy to cache the installer on our clients.

Create a new policy:

Policy1Add the Mavericks installer package we just uploaded:Policy2 Choose “Cache” from the Options

Policy3Scope it to a group or single computersPolicy4Choose a triggerPolicy5And set it to “Once per computer”Policy6Give it a name and a categoryPolicy7Now we need to know which clients are done caching the installer.
Therefor we need a create smart group:

SmartGroupIn order to make the Mavericks installer available in Self Service, we create another policy.

Upgrade1Scope it to the smart group we created:Upgrade2Make it available in Self Service, upload an icon and add a description:Upgrade3Install the cached installer:Upgrade4Add “shutdown -r now” in the “Run Command” field to trigger a rebootUpgrade5Our policy should now show up on the clients on which we cached the installer!

SelfService1 SelfService2When the user selects “Install”, the Mavericks will run for 5-10 minutes and reboot the computer afterwards.
It will then boot into the actual OS X installation environment and upgrade the OS which takes about 45 minutes, depending on the machine you run it on.
When the upgrade is done, the computer reboots again.
Now the First Boot Package Install.pkg kicks in and runs our script & installs Java,
plus whatever else you set it up to install.
During this, the end user will see the grey Apple bootscreen with the spinning circle.

Once all packages are installed, the Mac will reboot one last time and is then ready for the user to log in.

So far this method has worked very well for me, however
I’m sure there are smarter/better ways to achieve the same result and if you know one,
please let me know!
Same goes for any errors/mistakes you find in my posts.

Thanks to Mr Greg Neagle and Mr Rich Trouton for their amazing work,
and for sharing it with the Mac admin community.