Forum Discussion

Charles Ferreira's avatar
Charles Ferreira
Copper Contributor
Nov 28, 2018

ImmutableID to Extensionattribute

Hi smart people!

We are considering using Azure AD ImmutableID as our global ImmutableID for other projects. Is it possible to use ADConnect to write the Azure ImmutableID back to an extensionattribute in local AD? I understand there are scripts to generate Immutable from GUID. Not those.

To add to that, cloud only accounts have nothing in the ImmutableID field. Is it OK to then somehow generate the attribute from Azure ObjectID? Or we may get a conflict eventually?

 

Thanks in advance

  • Hello Charles, 

     

    There are two different queries in your request. 

    First - How to writeback Immutable ID to an Extension Attribute. 

    Second - ObjectID of cloud Accounts. 

     

    In Order to complete the first task,

    Create and Outbound rule for AD connector that must map source anchor to extension attribute, below mentioned is an example,

    Add-ADSyncAttributeFlowMapping  `

    -SynchronizationRule $syncRule[0] `

    -Source @('sourceAnchor') `

    -Destination 'msDS-cloudExtensionAttribute10' `

    -FlowType 'Direct' `

    -ValueMergeType 'Update' `

    -OutVariable syncRule

     

    Once the rule is created run a sync and you will find the extension attribute populated with source anchor.

     

    For the second query, ObjectID is an attribute that belongs to Object Class and is a mandate attribute that will be populated for all the objects. (Synced or Cloud)

    To check about the Object class you can run the below mentioned command on AzureAD powershell.

     

    Get-AzureADUser | Get-Member

     

    Let me know if you have any query.

     

    Regards,

    Rishabh

     

     

  • Hello Charles, 

     

    There are two different queries in your request. 

    First - How to writeback Immutable ID to an Extension Attribute. 

    Second - ObjectID of cloud Accounts. 

     

    In Order to complete the first task,

    Create and Outbound rule for AD connector that must map source anchor to extension attribute, below mentioned is an example,

    Add-ADSyncAttributeFlowMapping  `

    -SynchronizationRule $syncRule[0] `

    -Source @('sourceAnchor') `

    -Destination 'msDS-cloudExtensionAttribute10' `

    -FlowType 'Direct' `

    -ValueMergeType 'Update' `

    -OutVariable syncRule

     

    Once the rule is created run a sync and you will find the extension attribute populated with source anchor.

     

    For the second query, ObjectID is an attribute that belongs to Object Class and is a mandate attribute that will be populated for all the objects. (Synced or Cloud)

    To check about the Object class you can run the below mentioned command on AzureAD powershell.

     

    Get-AzureADUser | Get-Member

     

    Let me know if you have any query.

     

    Regards,

    Rishabh

     

     

    • Charles Ferreira's avatar
      Charles Ferreira
      Copper Contributor

      OK so that drives more questions but thank you it was what I asked for. For cloud only accounts with no ImmutableID should I, or could I, use the Azure ObjectID in the Extension Attribute instead? Can ADConnect run the base64 conversion of Azure ObjectID?

      • Rishabh Srivastava's avatar
        Rishabh Srivastava
        Iron Contributor

        Cloud Accounts are not imported to AAD connector space, its only the synced accounts that are queried. 

        You can write a script for cloud accounts to copy the value from ObjectID attribute, convert in to base 64 and then add the value to the respective extension attribute.

         

        Thanks...!

         

  • ThinkSync's avatar
    ThinkSync
    Brass Contributor

    Hello,

     

    Great question and some interesting responses. Please let me share some friendly advice from my own experiences working with customers.

     

    Yes, AAD C is a cutdown version of the MIM/FIM sync engine, BUT, please try and avoid adding custom rules. Custom rules adds complexity which can come back and haunt you when the time comes to upgrade.

     

    In this scenario using mS-DS-ConsistencyGuid as the source anchor for both your on-prem applications and Azure AD might be the best option.

     

    The big advantage of using mS-DS-ConsistencyGuid rather than GUID, is it’s writable. So, if you do need to cater for users moving between forests, it’s a simple process of copying the value between objects.

     

    With regards to cloud accounts, it’s a little tricky as you need the object written back to create an on-prem “shadow” account.

     

    Another option might be updating the application authentication end-points to support Azure AD or using Azure application proxies.

     

    Further reading:

    sourceAncor and mS-DS-ConsistencyGuid

    https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts

     

    Hope this helps,

    Matt C

    • MurrayWallForte's avatar
      MurrayWallForte
      Iron Contributor

      I am not disagreeing with you comment that custom rules cause problems down the road, but please explain if you can how this can wreak the havoc  you refer to.  Just need to understand the risks of that vs the reward of the sync back

       

      Murray 

    • Rishabh Srivastava's avatar
      Rishabh Srivastava
      Iron Contributor

      Hello,

      Thanks for sharing your experience.
      I am sharing my thought process.

      Sync rules are not complicated if we keep a fair documentation.
      In fact custom sync rules are available to provide you the privilege so you can use any of the attributes.

      In our discussion, we are not making any change , infact we are just copying the value from one attribute to another.

      Regarding “ms-DS-ConsistencyGuid” ;
      If we talk about the default behavior of enabling “ms-DS-ConsistencyGuid” as source anchor, the ObjectID is written back to this attribute.

      Feature of using “ms-DS-ConsistencyGuid” was introduced to enhance the administrative scope of managing source anchor.

      Regards,
      Rishabh

    • Charles Ferreira's avatar
      Charles Ferreira
      Copper Contributor

      Thanks for the replies. This is a great dialogue. As I understand it, since we started this (years ago before me) without mS-DS-ConsistencyGuid it's too late to change it. It would certainly fit the bill

      ThinkSync  Your assessment is correct, we are working toward a better lifecycle and looking to link the user between apps and not have to visit this again for a long time! ObjectID sounds like a plan

      • Charles Ferreira's avatar
        Charles Ferreira
        Copper Contributor

        OK so if I should start a new thread let me know but this is starting to take shape here, thanks very much!

        Prompting another question in the same line. Are Azure ObjectID's truly globally unique? Meaning across any Azure AD? Or is there some chance that there is, like life on another planet, a possibility for duplication?

  • ThinkSync's avatar
    ThinkSync
    Brass Contributor

    Hi Guys,

     

    No issues using this solution, but it does add complexity which I agree needs to be documented and taken into consideration moving forward. As I say to my customers, if we can avoid creating bespoke config, less to worry about and maintain, but it’s not always possible 😊

     

    @Rishabh – the key thing about the ms-DS-ConsistencyGuid attribute is, it’s writable. Massive win when you need to move objects between forests.

     

    Reading Charles question again, it looks like he’s is trying to configure a user lifecycle application/script and needs a way to link workflows to Azure AD identities (sync’d or managed). If this is the case, maybe a simple script which returning users ObjectIDs will do the job?

     

    Anyhoo – lots of interesting points.

     

    @Charles – ObjectID is unique so you won’t run into any issues with reuse or duplication. Good luck!

  •  I have not tried a write back from AAD to AD but I think this article sets the direction in a possible way to do - it doesn't talk directly about it but it sure talks about AD to AAD https://www.undocumented-features.com/2018/10/02/sync-custom-attributes-to-office-365-for-group-based-licensing/ in using the Synchronization Rules Editor - review this great article by  Aaron Guilmette and see if this opens up some opportunity to possibly do what you want done.

     

    Murray

Share