Moving from mostly on campus and AD bound machines with mobile accounts to working remotely for an unspecified time brings a lot of challenges. one of them is ensuring your password correctly stays in sync when changed, and ensuring your FileVault access and login keychains remain with your login password is important too. We’d had issues with those already, and were testing NoMAD already on campus as a tool to avoid this. NoMAD does not require a bind to AD, but can still sync your password with your AD account and ensure the FileVault and login keychain passwords update correctly.
As part of my test I had a Self Service policy with a script to turn a mobile account into a local account, then install NoMAD and the required profile. This was initially so we could take advantage of the bootstrap token, and use in conjunction with a Self Service policy to enable encryption.
The main part of the process is autoMigratetoLocal.sh, based on Rich Trouton’s interactive script but intended for use in Self Service. It uses the #3 variable to pull the user logged in to Self Service and migrate that account if it is in fact a mobile account, and retains admin permissions as it is configured in our environment. The policy is configured to run 3 things; this script to migrate the account, install the NoMAD profile and then the NoMAD application and launchagent.
Alternately I could modify the script to run on the currently logged in account to the OS for Self Service. In our case I don’t believe this will be any more effective. It could be used as part of a policy to migrate systems to NoMAD in the background. Currently in Self Service we can scope to just the machines we are testing with so we have control over the test as we move to a wider scale.
adam argyle 