SSO for Mac enrollment - None for iPads

[vantive]

Long Story will try to keep it brief. 

1,900 iPads enrolled into Jamf  were set up as single use Devices for training. Restricted to Safari and a couple of apps. No Apple ID, no need to connect to Azure Entra.

Project gets put on hold, everyone forgets about iPads. Two years later project no longer on hold. Pull them out and all sorts of fun including expired MDM profile and Certs.  We have figured out most of the issues in reenrolling or DFUing the iPads.

Except this one: After iPads went into storage we started enrolling Macs. Have pre-stage enrollment setup with Jamf Connect and Entra and SSO. Everything going great.. until.. iPad Project no longer on hold. When we go to DFU and re-enroll the iPad we are prompted for SSO. We do not want this. The hope is I can create an enrollment for the iPads that does not require SSO authentication. 

Ideas?

[vantive · Accepted solution]

Well figured it out... 

It was Customized Enrollment -- when I think about it it make sense. Device goes through prestage and hits the customized enrollment messages... it has to go to Jamfcloud.com to get them... and we have SSO turned on, so client is presented with an SSO login. Turn that off and enrollment and configuration went off without a hitch.

So our nice TOS that student have to click to accept is off table for now. Anyone know a workflow that we can easily present a TOS to a new device after enrollment?

[steve_summers]

@vantive , go into Jamf Pro and look under Mobile Devices > Prestage and look in each prestage for the option, "Automatically Assign New Devices".  You could have a prestage enrollment set as a default and it hits everyone of them which is causing what you're seeing.  Good luck. 

[vantive]

Well they did turn on "Automatically Assign New Devices" for the prestage used for these devices. Turning it off and testing. 

[vantive]

Well that failed. Saw a quick flash of SSO authentication and remote management screen popped up with The Configuration for your iPad could not be downloaded from OURDOMAIN.

The Operation couldn't be completed (BYCloudCOnfigRetreiveProfileFromWebErrorDomain error -5)

researching... 

[steve_summers]

@vantive if you got into the prestage settings, click on Scope.  In there search for the device serial number and then uncheck the box if you do not what that prestage to be applied.  That may be the last obstacle...

[vantive]

@steve_summers We do want that prestage applied. So leaving that checked in scope. Have turned off Require Credentials and Automatically Assign New Devices - back to being prompted for Azure login.

[jtrant]

Do you have any Enrollment Customizations in your PreStage?

[AJPinto]

Try disabling requiring credentials for prestage as @steve_summers suggested. I really came here to say, we dont call Azure, Entra around here but wanted to add something of value also. Im sure MS will go back to calling it Azure before long like they did with Intune, if they dont Im sure the Azure branding will stick around for another 10-15 years.

[vantive]

I actually call it Azure still when speaking outside the office and in my head, but have a keyboard text replacement of Azure > Entra because some people on the team always correct me :) I probably actually typed Azure.

[AJPinto]

Ha, yep lets keep bugging those people. Its AAD until the day it dies. :D

[vantive · Accepted solution]

Well figured it out... 

It was Customized Enrollment -- when I think about it it make sense. Device goes through prestage and hits the customized enrollment messages... it has to go to Jamfcloud.com to get them... and we have SSO turned on, so client is presented with an SSO login. Turn that off and enrollment and configuration went off without a hitch.

So our nice TOS that student have to click to accept is off table for now. Anyone know a workflow that we can easily present a TOS to a new device after enrollment?

[vantive · Accepted solution]

Addendum: Turned out that there were multiple items in the custom enrollment (5) and the last one was an actual "Single Sign On" - that was ignored because when it was added - we did not have SSO enabled yet. SSO was enabled after they were put in storage. By removing that 5th item from the Customized Enrollment - things went much smoother.