<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D54z00008p1VG6CAMOkta Classic EngineIntegrationsAnswered2024-07-04T09:00:34.000Z2023-02-16T15:12:31.000Z2023-04-21T20:02:31.000Z

ds4kb (ds4kb) asked a question.

February 16, 2023 at 3:12 PM
Disconnect users from on-premises Active Directory and integrate Azure AD as IdP instead

Disconnect users from on-prem Active Directory and integrate Azure AD as IdP instead.

The current setup - Our users and security groups are imported from our on-premises Active Directory. And we also use Microsoft Office 365 with Azure AD Connect in a hybrid identity situation that syncs users from the same Active Directory(one way sync) to the Azure AD tenant that serves O365.

 

We would like to eliminate the on-premises Active Directory server and rely completely on Azure cloud services instead. So moving forward we would like to continue using Okta to access our apps, but we want Okta to rely on Azure AD as its source for user identities. We will also turn off directory synchronization and convert our Azure AD synchronized users to cloud-only.

 

Can someone familiar with this type of change provide help with strategy, steps to follow, articles, or theory?

 

1) would it create duplicate (usernames)?

2) can I create azure to okta while still having active directory.

3) can I disconnect active directory sync

  • 5 answers
  • 1.29K views

  • Mihai N. (Okta, Inc.)

    Hi @ds4kb (ds4kb)​ , Thank you for reaching out to the Okta Community!

     

    To quickly answer your question:  

    1. There should be no duplicate issues as long as you ensure 1:1 parity for the usernames. 
    2. Yes, you can create the connection beforehand as long as you take the necessary steps to prevent a conflict. For example: have IDP routing rules set to avoid users being direct to AZ login before the proper time, deactivating the IDP once you finished the basic config until you are ready to move over. 
    3. This would probably be one of the last steps as by that point Azure AD should already have all the data to be the IDP.  

     

    That being said, there are a lot of moving parts and you have to know your entire environment and consider potential downstream implications and downtime, including but not limited to the following examples: 

    • once you turn off the the delegated authentication from on-prem AD, this will trigger a password reset/expiration for all relevant users. (could be important if you use the Password Sync option for any downstream apps)
    • if AD is turned off but you have apps that are in some way dependent on attributes/mappings that come from AD (commonly used "SAMAccountName")

     

    I'll leave this question open for the Community to share their advice and experiences as well, but I would also recommend you discuss this change with your Okta Account Executive or Customer Success Manager. 

     

     

    If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you. 

     

    Hope my answer helps! 

    --------------------------------

    Community members help others by clicking Like or Select as Best on responses. Try it today.

    Expand Post
    Selected as Best

  • Mihai N. (Okta, Inc.)

    Hi @ds4kb (ds4kb)​ , Thank you for reaching out to the Okta Community!

     

    To quickly answer your question:  

    1. There should be no duplicate issues as long as you ensure 1:1 parity for the usernames. 
    2. Yes, you can create the connection beforehand as long as you take the necessary steps to prevent a conflict. For example: have IDP routing rules set to avoid users being direct to AZ login before the proper time, deactivating the IDP once you finished the basic config until you are ready to move over. 
    3. This would probably be one of the last steps as by that point Azure AD should already have all the data to be the IDP.  

     

    That being said, there are a lot of moving parts and you have to know your entire environment and consider potential downstream implications and downtime, including but not limited to the following examples: 

    • once you turn off the the delegated authentication from on-prem AD, this will trigger a password reset/expiration for all relevant users. (could be important if you use the Password Sync option for any downstream apps)
    • if AD is turned off but you have apps that are in some way dependent on attributes/mappings that come from AD (commonly used "SAMAccountName")

     

    I'll leave this question open for the Community to share their advice and experiences as well, but I would also recommend you discuss this change with your Okta Account Executive or Customer Success Manager. 

     

     

    If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you. 

     

    Hope my answer helps! 

    --------------------------------

    Community members help others by clicking Like or Select as Best on responses. Try it today.

    Expand Post
    Selected as Best

    • Mihai N. (Okta, Inc.)

      The article you mentioned is just one half of the equation, it only deals with the deployment of Azure AD and it does not cover what it takes to disable AD.  

       

      I'm separating the questions here for extra clarity. 

       

      Q: Would unchecking enable delegated authentication to Active Directory prevent the okta password reset/user lockout?

      A:  Unchecking the "enable delegated authentication" was what I was referring to earlier. Please see the below article for details: 

       

      https://support.okta.com/help/s/article/How-to-disable-Delegated-Authentication-for-Active-Directory?language=en_US

       

       

      Q: And any work around for the applications dependent on attributes/mappings (example tripactions we require phone numbers and employeeID).

      A: If for example, phoneNumber and employeeID are currently mapped to your app based on the the values from on-prem AD, then perhaps you can consider mapping them to custom attributes in the Okta User profile and from there to the app.  

       This way, once you do decide to disable on-prem AD, the app would be dependent on the Okta User Profile instead of on-prem AD. 

       Then when you add Azure AD as the Profile Source, you will need to make sure the attributes are there as well to be pushed and updated in Okta as needed. 

       

      Article on how to add custom attributes for reference:

      https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-custom-user-attributes.htm

      Expand Post

      • ds4kb (ds4kb)

        Mihai-

         

        Thanks for all the help so far and how about new user accounts? Do I need to do a import from csv or can we simply replace AD with Azure AD?

      • Mihai N. (Okta, Inc.)

        If you set up Azure AD as the IDP, you should be able to use the JIT (just-in-time) settings for new users:

        image

This question is closed.
Loading
Disconnect users from on-premises Active Directory and integrate Azure AD as IdP instead