Skip to main content

I’ve federated our domain.  We never had any conflicts.  I have to assist a client with capturing their domain - but we already know they’ll have conflicts.

I know the end user will get an email and have to create a personal account, but what happens on the device?

 

A person creates a new iCloud account - does the login on the device auto-switch to the new account?

I’d take an educated guess Apple does their stuff to make sure purchased content moves to that account.

Do they have to sign out to get to the managed ORG ID?

Question is - does the device automagically become the managed ID - or do they have to sign out / into the captured ORG ID?

If it’s the latter, does their purchased content get purged from the device? Or is it more of a BYOD situation where they’re logged into both?

15 times the charm?

So you federate and a few scenarios exist:

  1. User leverages the link from the email
  2. User leverages the built in notification on devices (migrate/convert)
  3. User migrates beforehand

So for the first one, the user will be prompted within 8 hours of the change on all signed in devices to validate their new apple account email.  This involves device verification as well as “2 factor” style authentication from my testing.

Second one, users have the option to migrate OR convert (depending on if there are subscriptions active or anything that’s a monthly cost associated with the account).  If they migrate to a new email, then all of their stuff will remain the same minus their email address associated.  If they have the option to convert (no subscriptions, etc.) then they’ll have their managed Account on that device at that point.  They’ll have to synchronize their password to whatever your IdP is set to.  **Also apps purchased under that account are LOCKED to that ID.  They do not become institutional.

If the user migrates beforehand, then they get to avoid all of the apple notifications and it’s merely an email change :) 

**Note: if you want users to leverage managed accounts on ADE devices, then that’s a no go (sans the conversion mentioned for step 2).  Managed accounts can only be logged into on devices that aren’t supervised beforehand.  

To answer your last question - it really depends on how your devices are configured.  If they are ADE enrolled, then you won’t be able to log in with a managed account regardless.  If they aren’t supervised and you’re planning on doing Account Driven Device Enrollment or even Account Driven User Enrollment, then both accounts can (and should) reside of the device at the same time.

So the ORG migrates to federated IDs - the iPhones that went through automated enrollment will -not- be to log in with a federated ID at all, or only if they migrate their data to a personal email?

If the device is supervised (walked through ADE for enrollment), then federated Accounts will not be able to log in - correct.  THE ONLY EXCEPTION is for accounts that were converted AND are currently logged into said device.

They can migrate to a different non-federated domain org email account and log in with that.  Most org’s approach is to setup a subdomain for those.

THE ONLY EXCEPTION is for accounts that were converted AND are currently logged into said device.
 

 

So they get the email, go online and convert their account to my - personal - email.  They’re still logged in with the ORG email on the device.   Are you saying if they sign out and try to sign back in with the org email, they won’t be able to?  Just double-checking, I can’t find any reference to that as an issue.  Thank you for everything so far.

No, if they migrate their org email via the email from apple, it’ll prompt for account verification on the device to the new email address.

If they leverage the CONVERT option, then it keeps the org email and converts it to a managed account and the email address doesn’t change - but it backs them into a corner.

I am saying that if it’s a managed device (ADE enrolled), then they won’t be able to sign into the device with their managed org account.

Terms & ConditionsCookie settingsAccessibility statement