Federated authentication in ASM

[Krbonus]

Anyone using this feature in ASM?

I would greatly appreciate any good/bad experiences that you can share.

Thanks!

[russeller]

Yeah, I was curious on what would happen to the iPads that have already been configured for Shared mode. If the EDU Profile would update it, or it would require wiping and re-enrolling the iPads.

[Krbonus]

I'm curious to know too!

[jonohayes]

Nothing happens to the devices, they won’t need resetting.

It’s all done in the “cloud” when a user authenticates.

White Shared iPad when a user logins in for the fist time to a shared iPad with their Azure AD credentials, they will be made to set a passcode.

[iBSC]

we are going to turn it on at some point. Currently, we have our students with a different email so when we switch the authentication on, students will log in with their standard school email.
Example:
username@old.com
username@new.com

My questions are

1) What happens to the existing accounts? Will they be deleted, removed? Can they still access them?
Our students have data on their old accounts they need.

2)How do we move data from their old account to their new account?
We want to save the data/settings such as notes, camera roll, backup, etc.

Any advice on the above? Thanks!

[m_donovan]

Here is an Apple support doc on it.

https://help.apple.com/schoolmanager/#/apdb19317543

[jAscanio]

I'm excited for this as well
Here is a checklist for education...
https://www.apple.com/education/docs/get-ready-for-federated-authentication.pdf

[jrobinson2]

I just went through this and want to share my experience and the big mistake you want to avoid.

We have 2 domains. Our main domain and then .students.domain.org. I claimed both.

After federating and going through the steps, a window came up saying that all of your users will be notified they must pick a new Apple ID in 60 days. I did not proceed and turn it on, as I did not want to panic all of our teachers and students.

I was thinking we were claiming already created Apple IDs, but that's not the case. You cannot move data from one to the other. You are basically clearing out any current account with your domain. After the 60 days, it assigns the user a temporary Apple ID, so the data is at least never lost. Note: the 60 day clock starts when you send notices. Since I did not send notices, no current user will be forced to change.

By federating, you also lock out anyone else creating an Apple ID using any domain you claimed. I did not realize this until it was too late.
So now, all users must be given managed Apple IDs. For students, that's not a big issue. However, for new teachers/staff, they cannot use our domain to create an Apple ID. If we gave them a managed Apple ID, they would not be able to use the App Store or iBooks, which is very important if they want to explore an app or book. I would not have a huge issue if purchasing was active, but the moving accounts is still inconvenient.

I contacted Apple and was sent up to Senior Tech level. They have confirmed federating is not reversible, which seems ridiculous to me. Even though I didn't fully turn on the feature, federating it basically blocks your domain from personal Apple ID creation.

If I were to do it over again, I would not. Maybe for students, but students have data from one year to the other, so new accounts is not really a new option either. For now, new students will get a managed Apple ID (using 6 password policy and not Azure) and I guess we will just have to give staff/teachers the option of getting a managed ID or using a personal ID. I am not sure if I will ever send out that "60-day" notice.

Edit: I should have read further into the steps to see that the IDs would be released and then realized that would mean our domain would be locked. I'm not sure if that happened after I checked federation, or if I checked Apple IDs against our domain. If moving data was possible, then this would be a great tool. If managed IDs could be setup to be not as restrictive, then that would be awesome. But as it is, it's not very usable or helpful.

Oct 2020 Update:
Apple HAS made federating your domain reversible! I believe this was implemented late summer/early fall. It just showed up one day and there was great joy. You can also completely delete an Apple ID instead of waiting 30 days. You must deactivate, then delete, but it's a very clean deletion. I deleted one account and then could create the same ID through appleid.apple.com immediately.

[Krbonus]

Thank you for your very detailed in-sight @jrobinson2.

If you don't mind me asking, I know part of the process is to do a domain eligibility check and if it comes back with a conflict those people would have to update their email address and drop their work domain email. I know after 60 days, if they chose to ignore the notice to change the email, they'll be assigned with a temporary email address.

My question is I guess for everyone that had gone through the process, would we have to wait for the 61st day to continue with the federated authentication process if everyone that got the email address conflict already updated their email address?

[cbrewer]

@jrobinson2 Ultimately, you want to own, manage and federate all of your user's Apple ID's - including staff. The real issue here (and subsequent feature request) is that Apple needs to allow staff managed Apple ID's to be able to use the store.

[adhuston]

We are currently looking into this as well. From our experience with Google accounts we've found that store purchases can be a bit challenging. We actively disable the ability to purchase things from the Google Play and Book Stores because it can be difficult to deal with those purchases, or funds associated with the account, if the account is severed. It gets into a bit of a legal tussle to establish who owns the content.

[jrobinson2]

@cbrewer Yes, that would fix most of the issues. The big issue I see is having people create another Apple ID with a valid e-mail address with no chance to migrate their current information over.

@Krbonus I am not sure. I do not think you have to wait 60 days, but this is what documentation says:

"After you’ve completed a successful administrator account sign-in and the user name conflict check is complete, you can turn on and test federated authentication."

https://help.apple.com/schoolmanager/#/apdb02f73f18

So does that mean after the 60 days or before? Still vague.

[jhamil50]

You can enable federation prior to the 60 days being up. I think you can even enable federation before sending notifications, which is when that 60 day countdown begins. The user name conflict check should just give you the total number of personal Apple IDs using the domain you're claiming.

Once federation is enabled, any managed Apple IDs you have in ASM currently that don't conflict with a personal Apple ID and are in the domain you're enabling will have their format updated automatically. For example, if you have managed Apple IDs created as user@appleid.school.edu and you're enabling federation for the domain school.edu, those managed Apple IDs will be updated to user@school.edu as long as there isn't a user@school.edu personal Apple ID and they can begin signing in through Azure AD.

[RLR]

I know this post is quite old now but was wondering if you might know the answer as I'm looking into setting up Google Federation as it's just been released in the ASM interface (devices still need new OS version that haven't been released yet). If I turn on Federated ID with Google and the apple ID address gets updated to their email address, will it suddenly ask for them to enter their passwords on the devices they're using? Or will they not notice any difference?

[Robert_Giordano]

Good morning, we used azure to federate and when we did jamf "grabs" the
domain and any one using it for apple id's will get a message telling them
they have 90 days to change it. And once federated all users logged in with
it will be required to log out and log in with those credentials (the
google federated creds).

[nstevo]

Hi,
So, we've federated our accounts, but I'm a little confused.
The students can sign in to the ipads with their Azure accounts; however, they are then forced to create a shared iPad passcode and use this always for the iPad. This seems a little crazy to me... I'm not sure what the benefit is of having them linked to their Office logins if they then have to create a separate passcode anyway. Is this just how it is, or have I done something wrong?

Thanks for any thoughts...

[Robert_Giordano]

You did it right, the first time the student logs in to an iPad with MS azure (federated), it will ask to create a passcode. This is then used so that on any shared iPad the student uses the passcode they created, in apple school manager you can go to their account and under the more tab you can sign them out or change the passcode. It is also so that the teachers with iPads and apple classroom linked (edu profiles) are able to change/clear the passcode form their app. The EDU linked profiles are a big reason we use federated logins. Hope this helps

[nstevo]

Thanks bobbyg,
I was hoping that they would always/only use their Azure credentials and not need the extra iPad passcode, to remove the need for them having an extra password to forget. Not all of our teachers have iPads with 'classroom', so perhaps that's the way forward to save my sanity! :)

[Krbonus]

Hello @nstevo

We decided not to go with this for now.

My understanding with azure AD integration is that they'll use the same login credentials but I didn't know that they'll still need to create a "Passcode".

[nstevo]

@Krbonus I might be wrong, but it appears that this is the way. I was so excited about this and now it's so disappointing! Seems pointless to me.

[j_carroll]

The point is to mass create managed Apple ID's by using your Active Directory accounts.

The way we do it, is they use their school issued gmail account as their Apple ID, and their AD password as their Apple ID password. All of our software is synced with AD, so all of their school accounts for various things use the same username and password.

[SteveC]

Is the passcode only for shared iPad, or all iPads with student managed appleID? We have a mix of devices and even without federation iPads in shared mode require a passcode to log the students in. Requiring this passcode to be setup on 1:1 devices not in shared mode wouldn't make much sense.