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:
Require authentication…
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!
Brgds,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Manager Technical Support | Jamf
Hi Frederick, I’m getting mixed results here, as it seems with the „classic” Require Authentication prompt it all works as you’ve described, while with Enrollment Customization it goes back to showing „Create a Computer Account” screen. At least with „LDAP Authentication” type — haven’t tried the SSO one yet.
Could you please verify, if you’re able to replicate, as it seems you’ve focused on the „classic” auth for this article and it is not completely clear whether you’ve actually tested it works with EC or just made a quite logical — but potentially incorrect in this particular case — assumption?
Kudos to you Harald and Johnny for the find!
Seems you are right! Did quick test but must have gotten inconsistent result due to some setup. Will update the post!
The problem is how Jamf implemented it. We opened a ticket for this with AppleCare and Jamf years ago and it turned out that Jamf Pro sends a “SkipPrimarySetupAccountCreation” command together with the “LockPrimaryAccountInfo”. This is really bad and absolutely not what users expect. Unfortunately Jamf was unable to explain why they decided to design it like this and it seems that they are not willing to change this, even if it’s bad.
BTW: If you check a Mac’s log after enrollment, you’ll see something like this:
2020-08-19 11:09:35.800374-0700 0x1c64 Default 0x56fc 376 0 Setup Assistant: (ConfigurationProfilesUI) [com.apple.ManagedClient:CPUI_FW] CloudConfiguration: Will provide SetupAssistant with advance: YES; setup info: {
LockPrimaryAccountInfo = 1;
SkipPrimarySetupAccountCreation = 1;
Users = (
{
“DEP_AccountType” = AutoPrimary;
admin = 1;
fullName = “Thielemann, Marc”;
hidden = 0;
password = “”;
shortName = XXXXXXX;
}
);
}
2020-08-19 11:09:35.800479-0700 0xc90 Default 0x56fc 376 0 Setup Assistant: (ConfigurationProfilesUI) [com.apple.ManagedClient:CPUI_FW] CloudConfiguration: Enrollment progress: Applying settings
2020-08-19 11:09:35.800566-0700 0xc90 Default 0x56fc 376 30 Setup Assistant: [com.apple.mac.install:MacBuddyX] CloudConfigurationManager: MDM enrollment provided: proceed: 1 setup info: (
Users,
LockPrimaryAccountInfo,
SkipPrimarySetupAccountCreation
)
Sure, but product design and how other people see it should be designed are two different things. And it only applies to the legacy require auth option, not to the Enrollment Customisation.
Not able to explain or not willing to change does not feel right however. Feature request or feedback is typically taken serious.
For those who are interested, it’s PI-008733.
Hey Marc, I don’t think this is the place to discuss product issues etc. Happy to continue this discussion via the proper channels. If this is still impacting you, I’d suggest we reopen this discussion officially. See you on the other side if needed.