ADE Mac Build with FileVault – Silently adding a Second Account

An ask I had was on ADE builds can we add a second account to the Mac for IT access and the answer is yes but the tricky part is of course Secure Token to allow that IT account to show on boot at the FileVault screen.

Why add a second account?
There are arguments for and against this, these are just a couple…

For – Allow IT to access the device if there is a problem
Let’s take a scenario of IT being handed a Mac that is powered off.
If there is only a single account on the Mac at boot they will not be able to access the Mac unless the user is present as password sharing is a total no no.

Of course you could use the FileVault Recovery Key if you have it escrowed into your MDM but a quirk of Big Sur is in order to enter the PRK you have to enter something into the password box wrong 3 times before the FV Key entry box shows*. However, on M1 you will be forced to reboot the Mac and reset the user’s password. Once done you can then boot using the new password. The issue is if the user has another device you could end up syncing that new password to your cloud directory service which would them cause issues on their other device, so not ideal and also what if for some reason the Key is not escrowed into Jamf, it does happen.

*In macOS 12 Monterey you can easily show the FV key entry box by pressing shift-option-return you no longer need to fail the password 3 times and on entering the Key the Mac will just boot to desktop – much better 😊

For – macOS Recovery
If a user leaves your organisation and you need to re-deploy the Mac at macOS Recovery to wipe and reinstall you will be asked to auth as the user. Again, if you don’t know the password you can use the FV key, but what if its missing, what if MDM is not showing it or the record has already been deleted from your MDM. Without the FV Key or user password you will have to contact Apple and prove you own the device to reset it.

Against – Security Risk
Adding any additional accounts can be considered a security risk as it’s another entry point.

We still need a second account
For this article let’s go with we need a second account and I’ll explain how I did it, I’m not saying it’s the way you should do it as its not elegant and I do hope there are better solutions.

The goal is a user driven IT zerotouch build with FileVault enabled:

Silently add a second account for IT access
Ensure that second account gets a secure token so it can unlock the disk at boot but without requiring logging into first**
Ensure the second account shows at macOS Recovery
Ensure the second account password is not static but randomized and held in Jamf

**An ADE build and enrol to Jamf will bootstrap the secure token so any additional accounts created will get a secure token but only after physically logging into the device. Once logged in the account will then show at FileVault screen on next boot. In our scenario this is a user driven IT zerotouch build so only the user has logged in but we still need to show the IT account on boot.

Adding the second account is fairly trivial. We can set a Jamf policy to create an account and give set a password and make it admin, but this means every Mac will have an IT account with the same password which is clearly very very bad and currently Jamf MDM does not have a built in way to randomize this so we are going to use a Local Administrator Password Solution (LAPS) to randomize the password so it’s different on every Mac and keep that password in Jamf….more on that later.

There is also a strange quirk of adding an account by Jamf policy and that is it won’t show in macOS recovery. You can read more about this on MacAdmins Slack channel but we have a fix…more on that later as well.

Our High Level Build/Deploy flow is:
Out of the box Mac is powered on

Goes to Remote Management Screen and enrols to our Jamf MDM
Jamf Connect Login to provision the account to the Mac using cloud IAM
User enters their details this creates their account and they login
DEPNotify kicks off and the apps are installed and Mac is configured
User is forced to restart at end of DEPNotify and FileVault is required to be enable

During DEPNotify we can trigger our Jamf policy to create our second account and we can also install our LAPS process.

LAPS
There are a number of LAPS solutions for the Mac, I user macOSLAPS by Joshua Miller. I would get this up and running first and understand how it works beforehand before adding it to this process as it requires a Jamf Extension Attribute and Profile scoped to the Mac so I’ll assume it’s all been tested and working as you require.

So we have our Mac enrolled to Jamf with our user account and our IT account added. macOSLAPS is setup but still not yet invoked as password reset has not been run so the IT account using the static password we set in the Jamf policy. Now we need the IT account enabled with a secure token and “fake” a login so it shows at boot and then randomize the password so its unique for the device and get that password into Jamf

We can accomplish this in one single activity via a Jamf policy and a couple of script but it will require user interaction as the user needs to authorise the secure token request and of course we won’t know their password so we are going to have to ask them for it.

Lucky for us Travelling Tech Guy has done some work for us. Using this script by TTG, which is at your own risk we can ask the user to enter their password and therefore get a secure token for out IT account.

What you need to do is add this script to Jamf, create a policy and add the script to the policy and set Parameter values with your IT account name and password. I also customised the script text and added a company logo and a few extra AppleScript routines avoid blank password was entered and added a confirmation box. I’m not going to go into the detail of script as you can find out more on TTG site. All I will say is be cautious, it may not be for you.

When out policy is run it will prompt the user enter their password and then use the values set in the parameter of the script in Jamf (your IT account name and password) and give allow the account a Secure Token.

Earlier I said a Jamf quirk on account creation via a policy that it won’t appear at macOS recovery so we need to add an extra couple of lines to fix this.

Towards the bottom of the TTG script add the following line swapping out YOURITACCOUNT for the exact name of your IT account, ensure it’s the same case.

dseditgroup -o edit -a 'YOURITACCOUNT' -t user 'admin'

We will also need to run a update preboot, so add in

diskutil apfs updatepreBoot /

Below this is where I added some custom AppleScript to open a dialogue box to show a confirmation to inform the user what that all is good and the process has complete.

So now after this has run and complete, the IT account has a secure token, it has been added to show at macOS Recovery but in my testing it still won’t show at FileVault on boot as the account has not been logged into and of course it is using our static password. To fix all this we are going to create second script in Jamf and add to the same policy as our fist first script but run it after.

The script again will use Parameters set in the Jamf policy, these again will be the IT admin account and password.

To fake the login we use, note the variables

/usr/bin/dscl /Local/Default -authonly $addAdminUser $addAdminUserPassword

Now all that is done we can randomize the IT account password using macOSLAPS

/usr/local/laps/macOSLAPS -resetPassword

Finally we need to get that new random password back into Jamf so we need to do

jamf recon

My second script is below with the Jamf $4 and S5 values, note I’ve added in an ugly section that does an escrow to Jamf, you may not need this and it’s not pretty as it is an interactive terminal script made to run without interaction…yes ugly but works.

#!/bin/bash
# additional Admin credentials
addAdminUser=$4
addAdminUserPassword=$5
# The admin account needs to authenticate to validate its password to enable SecureToken on the account
# Using dscl and -authonly is the least intrusive way to do that.
/usr/bin/dscl /Local/Default -authonly $addAdminUser $addAdminUserPassword
# Kick off the bootstrap token escrow install. The UX is interactive.
# Use expect to supply username and password when prompted.
/usr/bin/expect << BOOTSTRAP
log_file /Users/Shared/expect.log
spawn profiles install -type bootstraptoken
sleep 1
expect “Enter the admin user name:”
sleep 1
send “$addAdminUser\n”
sleep 1
expect “Enter the password for user”
sleep 1
send “$addAdminUserPassword\n”
sleep 1
expect “profiles”
sleep 1
interact
BOOTSTRAP
sleep 1
# Randomize the account password using macOSLAPS
/usr/local/laps/macOSLAPS -resetPassword
# Update Jamf so macOSLAPS password is addded to Jamf
jamf recon

You could combine this and make it a single script but just for ease of use I left as two and this second script really takes a few seconds to run….quicker if you remove all those sleeps.

Wrap Up
So that’s it, we have our policy and script, so lets’ recap what it does:

Asks the user for their password
Allows a Secure Token for our IT admin account
Set the account to show at macOS recovery
Set the account it to show on next boot at FileVault
Randomizes the password and adds it to Jamf

You can either run this from Self Service but as part our build and deploy process if you remember at the end of DEPNotify we do a restart so therefore I set the script to trigger at Login and run once….I mean you can only run it once as the hardcoded values for the IT account will get changed via the macOSLAPS process!

Check
Once run check in Jamf that your macOSLAPS EA is showing the new password. You could SSH to it or if you have access to the Mac reboot it and you will see you IT account show at boot. You can then use the macOSLAPS password to unlock the disk and continue to boot and if boot into macOS Recovery use the password to run the wipe and reinstall.

How do I login as the IT account now it’s a random password?
Joshua Miller has also created a tool to get the password but its only if you are adding it into AD but we are not using AD anymore are we… are we? If so why?

You could allow certain IT staff with certain permissions to login into Jamf and get it but based on Joshua’s work I also created some bespoke tools using the Jamf API to retrieve the macOSLAPs password. It’s a simple two-part process and the tools could be distributed via Self Service but make sure that they are only accessible by those you trust, I’ve scoped tham to named individuals and they must login to Self Service to access….more on that next time.

Conclusion
As I said, it’s not elegant, it could be simpler and it may not be for you and I do sure there must be a better way….I think it’s called Monterey.

macOS Big Sur 11.4 and Proxy via Profile – Finally Fixed

macOS 11.4 was released this week and one issue we have been dealing with and raised with Apple in December 2020 is finally fixed.

The Big Sur 11.4 release notes for Enterprise are as below the one we are interested in for this article is number 5.

Using MDM to install software updates works more reliably on Mac computers with Apple silicon.
Resolves an issue where first login with a mobile account does not create a login keychain.
Setup Assistant no longer skips Location Services when account creation is skipped by MDM.
App installations from MDM are no longer canceled during setup when the country is changed.
Resolves an issue where DNS lookups may fail when using an authenticated proxy or a proxy configured with a PAC file.
Resolves an issue where the Kerberos SSO extension may fail to renew credentials.
Resolves an issue where iCloud Keychain sync could not be restricted by MDM.
Resolves an issue where StorNext volumes from fsforeignservers file would not mount automatically.

This item refers to when a Profile is used to set a Proxy using a authenticate PAC URL. This worked fine in Catalina but in Big Sur when the Profile was used this then caused a failure to contact our internal domain name due to the DNS lookup issue it caused. This was easily demonstrated by pinging the domain and then adding and removing the Profile. With the Profile ping failed, without the Profile ping was successful. The same domain is also used for our SSO extension so we could not use a Profile until now to set the proxy.

The workaround was a bash script which was set to run via a Jamf policy at check-in or Network Change. The script ran through every network connection available and entered the PAC URL for the Automatic Proxy Configuration URL box.

As this item was still user editable (we don’t lock Network prefs to users) it could be removed by the user so hence why it was run on Check-in or Network Change and therfore added back in in case the user had taken it out. The reason they take out is the Proxy service we use can be dreadfully slow but it’s there to protect the device so is a Security requirement.

The issue here is the policy can run 100’s of times a day on a single device and each time it runs its recoded to the Jamf database, so it’s not efficient.

Now this is fixed we have gone back to a simple Profile configured in Jamf with a Proxy payload. This is silently deployed to Macs as they upgrade to 11.4 and the current Policy is excluded, this is all done using scoping in jamf to smart groups plus we have a clean-up script that removes the entry from the Network prefs as Profile settings are not shown in GUI. The change is totally seamless and users don’t even realise it’s happening.

It’s great to have this working again but its issues like this and the time to resolve especially when its a regression from a previous OS that slow down the roll out of each macOS release in Enterprise environments. With this fix plus the SSO fixes Big Sur now feels Enterprise ready but 7 months after release and two weeks before WWDC when we will no doubt hear about macOS 12.

macOS Kerberos SSO authentication in Google Chrome

SSO on macOS for Safari is out of the box, no config required. As long as the Mac is getting a valid Kerberos ticket which can be checked in the terminal or via the Ticket Viewer app you are good to go.

Google Chrome however takes a little bit of config which can be set via a Profile for SSO to work.

The settings required are:
AuthNegotiateDelegateAllowlist
AuthServerAllowlist

Notice both these end Allowlist and not Whitelist. From Chrome 86 Allowlist was introduced and Whitelist was deprecated.

Deprecated
https://chromeenterprise.google/policies/#AuthNegotiateDelegateWhitelist
https://chromeenterprise.google/policies/#AuthServerWhitelist

Current
https://chromeenterprise.google/policies/#AuthNegotiateDelegateAllowlist
https://chromeenterprise.google/policies/#AuthServerAllowlist

You can check if these are in place by typing chrome://policy into the URL bar, this will show the policies set

If not set these SSO will fail in Chrome.

To set in Jamf you could create a mobileconfig or plist locally, then create a new Profile with a Application & Custom Settings payload and use the Upload section but a better option is to use the in-built External Applications section of the Application & Custom Settings payload and select the Jamf Repository and choose a JSON schema.

Once saved this will show all the Google Chrome options as a GUI where you can select the items you wish to configure and enter the settings required.

For SSO pick the two items described and enter your domain or domains.

These can be wildcarded and multiple domains separated with a comma

*mydomain1.net, *.mydomain2.com

Once in place, simply scope in the normal way and test out.

JSON Schemas in jamf

From around jamf 10.19 a new feature was added that is slowly gain more traction and that’s the ability to use JSON (JavaScript Object Notation) schemas in the Applications and Custom Settings payload. Over time jamf have updated and improved its functionality and ease of use. This article assumes you are on at least jamf 10.26.

So what does all that mean?
It means an app vendor, developer or anyone can create a schema that in turn can be used to create the Profile configuration directly in jamf rather than having to write XML or use other tools like ProfileCreator. This simplifies Profile creation and is a huge time saver.

So let’s give it a go….

Create a new Profile.
Name it and select a category just like creating any other Profile:

Once done scroll down and select the Applications and Custom Settings payload.

It will open up and show a few options:
Jamf Applications
External Applications
Upload

If you use other jamf applications such as jamf connect suite (Login, Sync Verify) you can set up the Profiles from here directly in jamf. For this article though we are going to use the External Applications option.

Select External Applications then click the +Add button on the right. The page will show as below with a Source dropdown:

Click the dropdown and you will see Repository and Custom Schema options. If you select Repository you will see an Application Domain dropdown and within this schemas for Chrome, MAU, Office, Outlook.

For this article lets choose the Custom Schema from the Source dropdown:

You will see a Preference Domain box and the Custom Schema box.

If we want to set up a Profile for NoMAD we would first enter the plist file name. The plist contains the configuration and will be created on the devices we scope the Profile to.

In the Preference Domain box enter com.trusourcelabs.NoMAD.json

Note the name is case sensitive so enter exactly as shown.

In the Custom Schema box we can now enter the JSON schema, lucky for us one has been created and you can find it here:
https://github.com/Jamf-Custom-Profile-Schemas/mscottblake-schemas/blob/master/com.trusourcelabs.NoMAD.json

Carefully copy and paste the XML from github into the Custom Schema field. I usually select the Raw view on github, then select all and copy.

It should now look like this:

Now scroll down past the Custom Schema field and you will see the JSON XML transformed into items configurable items right inside jamf.

Here you can see the Key’s you would set in XML as configurable items:

You may fine all the configuration items are shown but you can customise the list from the +Add/Remove Keys. Simply check or uncheck the items you require and click OK:

Go ahead and create your Profile by selecting the options you want and adding in the configuration required. The schema creator has helpfully added links to the NoMAD pages for each item so you can quickly see what the config item refers to. Remember to click Save regularly.

When you are ready to test the Profile scope to you test Mac and save again to push it to that device.

And that’s it. No more creating XML by hand, uploading, testing, editing and repeat. It can all be done in jamf.
This is just one example of a schema there are many other JSON schemas on github and Jamf Nation, here are a few I’ve found:

Talkingmoose’s substantial list:
https://github.com/talkingmoose/jamf-manifests

AgileBits 1Password
Apple Safari
Google Chrome and Keystone – although this is already built it as described above
Jamf Products
Microsoft Defender, Edge, OneDrive, Outlook
SAP
https://github.com/Jamf-Custom-Profile-Schemas/JSON-Schema-for-Jamf-Pro-Applications-and-Settings-MDM-Payload

Safari
NoMAD
Zoom
macOS Notifications
https://github.com/bpstuder/jamf_custom_schema

BBedit
Transmit
https://github.com/chrisgrande/jamf-profile-schemas

Managed Installs
https://github.com/joshua-d-miller/JAMF-JSON-Schema

MS Edge
https://blogs.windows.com/msedgedev/2020/02/20/edge-profiles-jamf-applications-custom-settings/

Cant find the schema you want?
I’ve not tried this but there is an app to help create the JSON schema, give it a go and if it works out publish it for other on github.
Schema Builder
https://github.com/BIG-RAT/Managed-App-Schema-Builder

Unbind from AD – The Silent Way

In my last post I detailed how NoMAD Login 1.4 can be used to silently convert a Mobile account to a Local account using the demobilize function. If the Mac is bound to AD the bind will still in place so after the demobilize is completed you may want to remove the bind as well.

Again, this can be done silently and is very simple using an MDM like jamf.

Create a new policy and name something like AD Unbind
Set the Trigger to be Check-in
Set the Execution Frequency to be Once per Computer
Add a Files & Processes payload

In the Execute command section add the following:

dsconfigad -force -remove -u test -p test

This will remove the bind, the -u (username) and -p (password) can be anything you want.
Scope the policy to your devices and save.

On next check-in the Bind will be gone. To test grab a Mac that is bound to AD, open the terminal and force a check-in with
sudo jamf policy

You will see the policy run and then if check System Preferences > Users and Groups and click the Login Options and you will where the Bind domain use to show with a green dot will now just show as below.

That’s it.

Mobile to Local – The Silent Way

Apple is encouraging Enterprise Mac Admins to shift away from binding to Active Directory and Mobile accounts. If you have Mac’s with Mobile accounts they can be converted to Local and there are some great scripts to do this. The one from Rich Trouton is very good and there is also a Swift app by Leslie Helou. However, these require user interaction if you want a silent way to switch there is a very simple alternative option.

NoMAD Login 1.4+ allows silent Mobile to Local conversion using the demobilize function and it’s very simple to deploy via jamf MDM.

Head over to the NoMAD Login page on gitlab and have a quick read about NoMAD Login:
https://gitlab.com/orchardandgrove-oss/NoMADLogin-AD/-/wikis/home

Download NoMAD Login here:
https://files.nomad.menu/NoMAD-Login-AD.pkg

Once you have download the pkg add it to jamf in the usual way create a new Policy and add NoMAD-Login-AD.pkg to the Packages payload:

Add to the Policy a Files & Processes payload:

In the Execute Command section add the following:

authchanger -reset -demobilize;defaults write /Library/Preferences/menu.nomad.login.ad.plist DemobilizeUsers -bool true;sudo jamf recon

This command will instruct NoMAD Login to demobilize which is NoMAD Login speak for converting from Mobile to Local and for good measure run a jamf recon.

The policy can be scoped to your devices as you require and run with the options you require for example at Check-in. The policy only needs to run once. You could make it a Self Service item and instruct your users to run from Self Service when they require.

Once run the user will require to log our or reboot and at next login the account will switch from Mobile to Local. You could request this in your policy or force a reboot but as we want this to be silent simply wait for the user to perform the action. The first time they do login after the policy has run this the login may be a little slower.

You may also want to collect account information about which type of account is on the Mac. This can be done via a simple Extension Attribute script.

Create an EA script using the below:

#!/bin/sh NETACCLIST=`dscl . list /Users OriginalNodeName | awk '{print $1}' 2>/dev/null` if [ "$NETACCLIST" == "" ]; then echo "<result>Local</result>" else echo "<result>Mobile</result>" fi exit 0

When a Mac next does a full jamf inventory update the account type will be collected and show:

If you have a mixed environment of Mobile and Local accounts set up the EA and let it run for a few days or weeks collecting device account type. Then create a Smart Group to show devices that have Mobile accounts and scope your Mobile to Local Policy to the smart group.

If the Mac is Bound to AD the demobilize will leave the bind in place. This can be removed when required by another simple policy which I’ve detailed in this post

Happy demobilizing.

macOS Catalina – The Enterprise issue

Once again it’s that time of year when Apple release their next macOS, and once again Mac Admins scramble to block user’s updating.

With Jamf restriced policies in place and communications sent to all Mac users and posts on internal intranets you would of thought users would get the message to hold off updating…..but still they try.

The main issue though is now Catalina is available it will only be weeks until Mac’s ship with it installed as default. Apple confirmed to me either these Mac’s will have updated firmware to prevent downgrading to Mojave or downgrading could void the Apple Care for Enterprise warranty. So like every year Mac Admins have to warn users if they buy a Mac and it ships with Catalina don’t expect to use it and certainly don’t expect to be supported (yet).

It’s a odd situation, shiny new macOS being promoted, possible end of year hardware budget needing to be spent as it may be a case of “use it or loose it” but due to Apple’s history on first release and even second and third release not being Enterprise ready (#iamroot) Admins get stuck, users think they are slow and being awkwark as of course “I updated at home and its fine” but all we are really doing is trying to stop the pain and issues early upgrading will cause.

If Apple really want Mac’s in the Enterprise on ordering Enterprise Mac Teams should be able to state (with some restriction) the OS required, even if its latest version of previous, so Mojave 10.14.6 (18G103) at least for the first 3-4 months after the new OS is avialable.

Come on Apple make this happen, make Apple in Enterprise great not frustrating.