Skip to main content

We have begun using Twocanoes Xcreds, replacing NoMAD Login AD. In the process, we are also attempting to discontinue implementing a common local administrator account with a known password. This type of setup was demonstrated in a session at JNUC this year (although their example used Jamf Pro and Jamf Connect, not Jamf Pro and Xcreds... the principles should be the same though.)

However, despite repeated attempts, I cannot reliably get the bootstrap token to escrow automatically at first interactive login, as I'm led to understand is supposed to happen. I can manually log in as a user on the system, then open Terminal, su to the Jamf Pro-created admin account, and initiate a sudo profiles install -type bootstraptoken, and it escrows without incident.

I have to imagine it's SOME combination of settings that I don't have configured properly, but I don't know what.

I currently have:

  • In "User-Initiated Enrollment:"
    • "Username" is set to <admin user name>
    • "Password" is set to <admin password>
    • "Create Management Account" is unchecked
  • In "PreStage Enrollments:"
    • In "General"
      • Make MDM Profile Mandatory is checked
      • Allow MDM Profile Removal is unchecked
      • Prevent user from enabling Activation Lock is checked
    • In "Account Settings"
      • Create a local Administrator account before the Setup Assistant is checked
      • Username is set to <same admin user name as User-Initiated Enrollment settings>
      • Password is set to <same admin password as User-Initiated Enrollment settings>
      • Hide managed administrator account is checked
      • Make the local administrator account MDM-enabled is unchecked
      • Local user account type is set to Skip Account Creation

Is it something that I'm doing in the above that is causing my issues?

Hello,

I have the same issue and do have the same setting setup.

Did you resolved the issue in the meantime ?

 

We are experiencing the same behavior.  Wonder if you found the solution.  thx

So I'm pretty new to this whole JAMF thing from a management point. the majority of our fleet of 500+ Macs are Intel based and have never had issues with the secure token being escrowed. I currently have 7 M1 and newer M2's and am having this issue. I have the same settings, We are using JAMF Pro and Manually adding to AD with a script that my predecessor wrote. I can do anything with our Local Admin account but cannot do any OS updates/Upgrades. The difference with my issue is that My Local Admin account created by JAMF during enrollment does not have the secure token either so I can't eve manually escrow the token to any of these new devices. 

So I'm pretty new to this whole JAMF thing from a management point. the majority of our fleet of 500+ Macs are Intel based and have never had issues with the secure token being escrowed. I currently have 7 M1 and newer M2's and am having this issue. I have the same settings, We are using JAMF Pro and Manually adding to AD with a script that my predecessor wrote. I can do anything with our Local Admin account but cannot do any OS updates/Upgrades. The difference with my issue is that My Local Admin account created by JAMF during enrollment does not have the secure token either so I can't eve manually escrow the token to any of these new devices. 


Hey Mario - 
Correct, this is a real pain the neck for us as well.  Mainly because Apple grants the Secure Token right to the first user whole actually login to the device.  In our case, as part of provisioning our team has to login with our local Admin account first in order to be granted the Secure Token.  From that point, as long as FileVault is enabled by the end user upon their next sign-in they will be added to FIleVault enabled users who will then be able to accept OS updates with their standard user credentials.

But before there has no issue with bootstrap token escrowed to Jamf. I see that happenning recently and without that we cannot even update/upgrade macOS from Jamf.

We're having this issue as well.

Reply


Terms & ConditionsCookie settings