Break Glass Admin
A workflow to create/manage a rotating backdoor admin account.
Where there are several other implementations of LAPS for Macs out in the Jamf Nation and Mac Admins communities, this version was created to serve as a single solution for all our clients that can be configured through policy parameters.
Towards the top of the script are the following parameters:
4. The username and (optionally) full name of the admin account
5. Which method of creating a password to use (see below)
6. Name of extension attribute where password is store (e.g. "Breakglass Admin")
7. Storage method: Provide BASE64 encoded "user:password" for storage via API. Otherwise locally stored.
8. Overrides (optional)
4. Admin Username and Full Name
The short username of the admin user to create/update.
Optionally, a full name can be provided. Otherwise, the short name will be used for both.
breakglass Breakglass Admin
5. Available Password Methods
The following options/schemes for generating passwords are available:
nato - Combines three (by default) NATO phonetic letters (e.g. WhiskeyTangoFoxtrot)
wopr - Like the launch codes in the 80s movie, "Wargames" (e.g. "CPE 1704 TKS")
xkcd - Uses the system from the XKCD webcomic (https://xkcd.com/936/) by pulling four (by default) words between 4-8 characters long from /usr/share/dict/words (e.g. CorrectHorseBatteryStaple)
names - Uses the same scheme as above but only with the propernames database (e.g. AliceBobEveMallory)
pseudoRandom - Based on University of Nebraska' LAPS system (https://github.com/NU-ITS/LAPSforMac)
custom - Customizable format with the following defaults:
1 Upper case character (min)
1 Lower case character (min)
1 Digit (min)
1 Special character (min)
Optionally you can add a string to specify overrides in the following format: N=20;U=3;L=1;D=2;S=0
6 - Extension Attribute
The name of the Extension Attribute in which to store the password.
7 - Storage Method
Storing the password in Jamf Pro (default)
Provide the base64 encoded username and password of a Jamf Pro (API) user account with READ and UPDATE permissions for the Computers object as well as for the following objects based on the Inventory Display option for the Extension Attribute:
User and Location - Users
Extension Attributes - Computer Extension Attributes
To get the encoded string, enter the following command into Terminal:
Where USERNAME and PASSWORD should be replaced the appropriate info.
Note: This will NOT display any result. Instead it will be in your clipboard for pasting elsewhere. Because 'echo -n' prevents a final line-feed, it can be confusing which parts you need to copy.
Storing the password on the local client
If this parameter is blank, the password will be stored locally in a plist file in /Library/Preferences/ with root-only access.
Note: The password stored in this file will be in cleartext. Some may argue that this is insecure. But to get it, the user would need admin privileges and use something like sudo -s to elevate to root in order to get it. If they can do that, they don't need your backdoor admin access and you have an HR/Policy issue bigger than your technology issue.
11 - Overrides
After the main variables/parameters block, there is a section that includes the following:
Rather than turn each of these options into their own policy parameter, these options are defined in a block here. They can either be directly edited (hardcoded) in the script or overridden by passing in a variable assignment string into parameter 11.
For example; if 'nato' was the selected password method and the following was entered into parameter 11 of the policy:
The resulting changes would take place:
The password would consist of five NATO words instead of three
The admin account would be created as visible in System Preferences and with a UID > 500
If the existing password can't be found or if the password change fails, the FORCE option will attempt to delete the account and re-create it
The password will be stored in the local file even if the remote option is used
Note: As mentioned in the comment block, running 'eval' on an unsanitized string would be a terrible idea with a normal script. For a Jamf script, some may still consider it problematic. In which case, simply comment out or delete the line.
There are two additional support scripts in this repository:
Extension Attribute.sh - If you are choosing to store the password on the client side, but want it copied into Jamf, create a script-based extenstion attribute with this code to have each computer send that password during recon.
Set Default Password.sh - This workflow was originally designed to create and then manage the password for an account. For organizations wishing to use an existing admin account with a fixed password, this script will set the local or remote extension attribute to the existing value before the main script runs.