ghjbk (ghjbk) asked a question.
Users exist in AD/Okta and in O365
We are finally ready to connect our AD/Okta with O365. All of our users exist in both locations. I'm trying to understand a couple of things
1) Once Okta is set up for SSO with O365, how are the existing users in O365 treated? Does Okta try to provision them in O365 once it sees them having access to the app in Okta? Will users have to use their AD creds to log in now?
2) For provisioning we use either E1 or E3 licenses, does that mean we have to set up 2 different O365 apps in Okta?
3) For deprovisioning, if the user already existed in O365, we federate the domain via Okta then deprovision the user in AD, will it deprovision the user (ie delete and remove the license) in O365?
Thanks
let me see if I answer:
(1) Okta will provision them IF you turn on provisioning in the app and yes, once WS-FED is turned on, they will access the O365 using the same creds they use to access Okta
(2) You don't need two different apps, but you will need two different groups to handle the licensing assignment. This is how we do it but i'm sure there may be other ways
(3) Deprovisioning b/t Okta and O365 is an interesting relationship, with a few nuances that take some getting used to. In re to the deprovisioning behavior, depends on how you set up the deprovisioning tasks in the app. We handle our manually due to our process and requirements.
I hope this helps.
Jeff
It does help! Thank you.
The thing that we are trying to test is if we set up Okta to federate the domain, when that happens, users who exist in both Okta and in O365, are there anything that we need to be aware of?
Also does Okta give you a chance to define what the immutabile ID attribute is in the profile editor? We would need those to line up for existing users, no?
Will you enable provisioning when you federate? When we did ours (2017) I don't recall there being any issues. If your users are AD mastered and don't have on-prem exchange OR don't have the Ad schema extended, you'll want to populate the proxyaddresses attribute in AD and map it to Okta and Office 365 (I can clarify if needed).
In re to immutable ID, we didn't worry about mapping that - we just made sure the UPN matched the primary SMTP. If it doesn't, there are ways to override but we didn't worry about the immutableid.