Jun 15 2020
03:56 AM
- last edited on
Jan 14 2022
04:30 PM
by
TechCommunityAP
Jun 15 2020
03:56 AM
- last edited on
Jan 14 2022
04:30 PM
by
TechCommunityAP
Hi,
We have a M365 tenant which is federated with Okta for Authentication.
All user provisioning & authentication for M365 is handled by Okta. Okta in turn is federated to our On-Prem Active Directory and we have agents similar to Azure AD connect for user sync & pass thru authentication.
Current user sync cycle:
On-Prem AD -sync-> Okta -sync-> Azure AD
We have all users provisioned in M365 using this configuration and only MS Teams & SharePoint online is being used as of now. Exchange is not provisioned.
We are now moving towards completely getting rid of Okta from the M365 integration and are planning for configuring Azure AD connect to provision users and use pass thru auth for authentication.
Since, we have some services already provisioned and users are actively using them, what are important things we need to consider/plan for a smooth migration from Okta to a direct on-prem AD federation. An article which is "almost" similar to my scenario is about migration from ADFS to pass thru authentication as mentioned in below article. I am hoping at a high level things will be similar in my scenario as well and I can also use the staged roll out feature (Please correct me if am wrong here)
Any tips or reference articles will be highly appreciated
Jun 22 2020 11:53 AM
@Unnie Trying to get the situation here. So your Active Directory is not synced to AAD yet?
Jun 22 2020 01:14 PM
Jun 23 2020 12:35 AM
@Unnie That is something I have not dealt with so far, but I assumne you can set up your own Azure AD connect server as staging server to take over the running server from Okta. You have to take care of the source ancor, and be sure your accounts will soft match with the UPN suffix.
@Sander Berkouwer ,might have some tips for you on this topic.
Jun 23 2020 01:07 AM
SolutionI feel there are two challenges to solve:
The current setup keeps user objects in Active Directory in sync with user objects in Azure AD. To make sure the same objects on both ends are matched end-to-end, I'd recommend hard matching by setting the source anchor attributes on both ends. There's more information on end-to-end matching here. To avoid multiple synchronization engines writing to Azure AD and possible introducing last-write errors, I'd also recommend to use Staging Mode in Azure AD Connect when Okta still actively synchronizes.
From Azure AD's point of view, it doesn't matter which federation solution you use. Whether it's Okta, HelloID or PingFederate, you can use the staged roll-out feature with all of them.
Jun 23 2020 01:21 AM
Jun 23 2020 01:46 AM - edited Jun 23 2020 07:41 AM
@Sander Berkouwer @JanBakkerOrphaned Thanks a lot both of you , for the tips & help.
Jun 25 2020 10:38 AM - edited Jun 25 2020 10:39 AM
Regarding the hard matching, when we set up Okta to Azure AD user provisioning, AD ObjectGuid attribute value is mapped to the ImmutableID in Azure AD. So, I am assuming this makes it easy for us to do the hard matching in Azure AD connect.
Jun 23 2020 01:07 AM
SolutionI feel there are two challenges to solve:
The current setup keeps user objects in Active Directory in sync with user objects in Azure AD. To make sure the same objects on both ends are matched end-to-end, I'd recommend hard matching by setting the source anchor attributes on both ends. There's more information on end-to-end matching here. To avoid multiple synchronization engines writing to Azure AD and possible introducing last-write errors, I'd also recommend to use Staging Mode in Azure AD Connect when Okta still actively synchronizes.
From Azure AD's point of view, it doesn't matter which federation solution you use. Whether it's Okta, HelloID or PingFederate, you can use the staged roll-out feature with all of them.