UPDATE: only applies to the legacy “require authentication”, not when adding auth via Enrollment Customization and also only tested on macOS 10.15.3
Well well well, one simple checkbox and all goes south 🙂 Actually expected behaviour but still something to remember!
Yes, I’m talking about the ‘Lock primary account information’ option in the Jamf Pro pre-stages -> Account Settings payload, as I was recently troubleshooting some weird Bootstrap token behaviour.
We had an issue with user accounts which could not login anymore after being demoted from Admin to Standard. This turned out to be a Login Window setting, but while on 10.15.3 and using Jamf Pro 10.18, we also noticed that the Bootstrap was not automatically enabled/escrowed. This while the pre-stage was configured to allow the creation of an Admin Account during the Setup Assistant.
As we wanted to isolate any Bootstrap / Secure Token issues first, we focused on finding the root cause for the missing bootstrap. I was working with Harald and Johnny on this one, and credits go to Johnny who pointed me at “hey would this have any impact on the Bootstrap… ?” –> and yes we all learned something! 🙂
We were looking at the “Pre-fill primary account information” settings in the pre-stage. Initially I didn’t think this would do much harm to the Bootstrap… because we’re still creating an admin account for the end user during the pre-stage, right? All we need according to the Bootstrap documentation, no?
Well, not really as straight forward as it seems. Yes, you would think that ‘we’re still creating an admin account during the Setup Assistant’…. but this only seems valid if you do NOT enable ‘Lock primary account information’ !
It was only when I tried this setup again that I noticed that I was going through the Setup Assistant without seeing the screen where the user account gets created… and it all made sense! Let’s have a look:
First of all, in order to pre-fill account information, we need to ‘Require Authentication’ (Update: the described behavior only applies to this legacy ‘require authentication, which is to be deprecated. Does not apply to the ‘Custom Enrollment authentication’):
Without this authentication, the following setting will not work, but if you require authentication, or add an LDAP/SSO authentication via Custom Enrollment, you can decide to ‘Pre-fill primary account information’ so that the user does not have to fill in his name and account information manually again.
Let’s first not enable the ‘Lock Primary Account Information’ for now, and see what happens:
And immediately after that, the ‘Create a Computer Account’ screen appears:
So here we are indeed creating the admin account during the setup assistant… and just pre-filling the user account info. Yes, the user can stil change it, but as the account is being created during the Setup Assitant, all is good with the Bootstrap Token.
This behaviour changes however if you also enable ‘Lock primary account information’ !
Locking the account info SKIPS the ‘Create a Computer Account’ screen entirely, goes to the ‘Setting up your mac’ screen, and presents you with the normal macOS login window… with the user created in the background.
Not 100% sure but to me this feels like expected behaviour because you’re actually not fully creating the account ‘in the setup assistant’. Only when logging in into that account, you go through some parts of the Setup Assistant again, ending up with the ‘Setting up your mac’ screen again… and the following result:
After going through the initial Setup Assistant, provisioning the Mac with the user account locking down the primary account information…
… we end up with ‘Setting up your Mac’…
… and the Login Screen with a place holder for the account:
But it’s only during the first login that the account creation gets finalised:
Some Setup Assistant screens again… and ending with Setting up your Mac…
Hence the account creation is NOT fully taking place during the Setup Assistant, and we end up with this:
Interesting side effect of the ‘Lock primary account information’ ! One small checkbox to tick, but one giant consequence for deployment, as you end up with fixing the Bootstrap via…. yes… a script or manual intervention on the machine ¯\_(ツ)_/¯ .
That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!