Interoperability Microsoft AAD Connect and Identity Manager Azure AD Connector

I'm not yet sure what is the best setup for integration Azure AD as target system.

We need hybrid users (with SSO), so AAD Connect is required anyway.
It is required as well for other purpose like device management.

Now I see the following two options:

1. Provision Accounts only to on-prem AD

In this scenario, we provision AD Accounts and the accounts will be synchronized to Azure AD with the Microsoft AAD connect.
The Sync Project to Azure AD reads that users and connect that Users to the Person. The AAD User Object has to be unmanged, since we do not want to do any changes directly on an Azure AD User. That has to go alway over on-prem ID and AAD Connect.
Groups and it's memberships could be managed directly in the IdentityManager and provisioned directly over the sync project to Azure AD.

So we use standard Microsoft functionality and we are fully supported by Microsoft for that hybrid identities.

2. Provision Accounts directly to Azure AD and user the ImmutableID

In this scenario we provision the AAD User directly from Identity Manager to Azure AD. We make sure that we set the ImmutableID for that AAD User (and of course set the same one to the msDS-ConsistencyGUID on the on-prem AD Account).
The AAD Connect will still work and do all the stuff needed to have a hybrid identity with full SSO support.

Of course groups and it's memberships are handled the same way as in scenario one.

This scenario would make the lifecycle management in identity manager easier and it is the standard behavior from identity manager point of view.
But, is it really working with SSO, ...? Is that scenario also supported by Microsoft?

At the moment I'm tending to go with scenario 1, since it seems to be safe way. It is fully Microsoft supported and it keeps up to date with the fast changing Azure Cloud environment.

Does anyone have experience with one of this scenarios?

Do you have any hints, what I should take into account, when making the decision to go with one or the other scenario?

Patrick

PS:

There was already a discussion about the ImmutableID in the past https://www.oneidentity.com/community/identity-manager/f/forum/21463/azure-ad-immutableid

Parents
  • Hi Patrick,

    I would go with option 2 as you can keep the ILM processes as you want (especially if you want to add more liceneses like for a mailbox or for MS teams etc. and do not have the break of waiting for AADConnect to work. If you create an AAD account with the correct settings of immutableID, ms-DS-ConsistencyGUID and UPN correctly, AADConnect seamlessly will take over the user account at its next run.

    As mentioned in the thread you a re referring to: We are using the MS Graph API for our connector which is the MS supported way of making changes to AAD objects.

  • Hi Matthias

     I've done now some PoC on Scenario 2 and I've got also feedback from other One Identity Customers.

     What was successful?

    • Creating an ADSAccount and a AADUser with the same ID for immutableID, ms-DS-ConsistencyGUID
    • Both Accounts were provisioned to the corresponding target system
    • The AAD connect matched both Accounts and synchronized the missing attributes like onprem-SID

     

    But I still have the following concerns about the scenario 2:

    • As soon as AAD Connect took over  a User on AAD it is looked (on AAD and also in IdentityManager)
      • In the Manager it is not possible to do any modification on the AADUser (makes sense, since AAD would not allow to change it outside the AAD Connect)
      • If we had that AAD User "Fullmanaged" we would get FROZENS, since we can't change the attributes. Attribute changes has to go over ADSAccount and AAD Connect to the AADUser.
      • So we are losing the benefits over Scenario 1
      • See also https://theether.net/kb/100225

     

    At the moment I still assume, that we can manage most of the groups in a cloud only manner. So we maintain groups and memberships directly from Identity Manager in the cloud.

    But we have to pay attention to the Hybrid Exchange Environment. As far as I know there is a need for Hybrid Groups synchronized over AAD Connect as well.

     

    I'll do now some further investigations for Office365 and Exchange Online. I have to find out if we have the same limitations . As in the link above described we will face also problems if we want to maintain a hybrid exchange.

Reply
  • Hi Matthias

     I've done now some PoC on Scenario 2 and I've got also feedback from other One Identity Customers.

     What was successful?

    • Creating an ADSAccount and a AADUser with the same ID for immutableID, ms-DS-ConsistencyGUID
    • Both Accounts were provisioned to the corresponding target system
    • The AAD connect matched both Accounts and synchronized the missing attributes like onprem-SID

     

    But I still have the following concerns about the scenario 2:

    • As soon as AAD Connect took over  a User on AAD it is looked (on AAD and also in IdentityManager)
      • In the Manager it is not possible to do any modification on the AADUser (makes sense, since AAD would not allow to change it outside the AAD Connect)
      • If we had that AAD User "Fullmanaged" we would get FROZENS, since we can't change the attributes. Attribute changes has to go over ADSAccount and AAD Connect to the AADUser.
      • So we are losing the benefits over Scenario 1
      • See also https://theether.net/kb/100225

     

    At the moment I still assume, that we can manage most of the groups in a cloud only manner. So we maintain groups and memberships directly from Identity Manager in the cloud.

    But we have to pay attention to the Hybrid Exchange Environment. As far as I know there is a need for Hybrid Groups synchronized over AAD Connect as well.

     

    I'll do now some further investigations for Office365 and Exchange Online. I have to find out if we have the same limitations . As in the link above described we will face also problems if we want to maintain a hybrid exchange.

Children
  • It is well known that an AAD user account "owned" by AADConnect can not be be changed anymore (at least not attributes". This is a limitation set by Microsoft.

    You still can assign licenses and group memberships.

    Creation of an Excange Online account is always done by adding a license after creating the account.

    And yes, the deletion of an Exchange Online Mailbox and trying to delete an AAD user is somewhat painful  painful. But again: this is due ti Microsoft's limitations

    So I do not see a real problem to adjust the oob process chains (we created for the use case of not having AAD connect)  to work wirh AAD connect.