SOLVED

Changing Azure AD Federation provider

Iron Contributor

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)

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-migrate-adfs-pass-through-authen... 

 

Any tips or reference articles will be highly appreciated 

7 Replies

@Unnie Trying to get the situation here. So your Active Directory is not synced to AAD yet?

 

AD it is not synced directly to Azure AD, but synced first to Okta & Okta later syncs user to Azure AD. Okta is acting as an intermediatary service between Azure AD & AD, I want to remove it and set up Azure AD connect for user sync and Pass thru cloud authentication.

@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. 

best response confirmed by Unnie (Iron Contributor)
Solution

I feel there are two challenges to solve:

  1. Making sure your colleagues synchronize correctly end-to-end.
  2. Switching federation with Okta to Azure AD Connect PTA.

 

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.

@Sander Berkouwer Thanks Sander.

 

@Unnie is this someting you can work with? 

@Sander Berkouwer @JanBakkerOrphaned  Thanks a lot both of you , for the tips & help.

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.

1 best response

Accepted Solutions
best response confirmed by Unnie (Iron Contributor)
Solution

I feel there are two challenges to solve:

  1. Making sure your colleagues synchronize correctly end-to-end.
  2. Switching federation with Okta to Azure AD Connect PTA.

 

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.

View solution in original post