(2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 2)
Posted by Jorge on 2016-05-07
Part 1 can be found here
The following functional logic will be used within the Azure AD Sync Service when a new on-premises AD account is initially synchronized to Azure AD (scenario: AD account exists and Azure AD account does not yet exist):
- As the initial source for Immutable ID (sourceAnchor) use the base64 format of the value in the objectGUID attribute if the <Immutable ID attribute in AD> does not yet have a value;
- If the <Immutable ID attribute in AD> does not yet have a value, then sync back the value of the Immutable ID (sourceAnchor) to the <Immutable ID attribute in AD>;
- Use the value in the Immutable ID (sourceAnchor) to create the new Azure AD account.
REMARK: Initially the value in the objectGUID attribute (binary) corresponds with the value of the <Immutable ID attribute in AD> attribute (base64 format of the binary value)
The following logic will be used within the Azure AD Sync Service when the Azure AD Sync Server needs to be rebuild or when an AD account is moved to another AD domain (scenario: AD account exists and Azure AD account also exist):
- As the source for Immutable ID (sourceAnchor) use the already existing value in the <Immutable ID attribute in AD> attribute;
- The Azure AD account with the same Immutable ID (sourceAnchor) can now be linked to the on-premises AD account
REMARK: When an account is moved to another AD domain, the already existing value in the <Immutable ID attribute in AD> attribute must be transferred to the new AD account to allow the new AD account and the existing Azure AD account be linked to each other. The transfer of that value must be done either manually or scripted
Your question probably is at this stage: “sure, nice story, but how can I implement this logic within Azure AD Connect?”
First of all, we need to agree on some supported best practices:
- The default sync rules in AAD Connect must not be modified in any way, except for disabling them;
- Any required changes to the default sync rules in AAD Connect must be realized in clones of the default sync rules;
- Keep the require configuration as simple as possible;
REMARK: see Change attribute flows
The required configuration will be done for users, iNetOrgPersons and groups. I will try to guide you on how to get this up and running. During the explanation I will assume the following:
- A single AD forest. I does not really matter if it is a single domain AD forest or a multiple domain AD forest
- If you want to use a Unicode String attribute, I will use the “extensionAttribute15” attribute AS AN EXAMPLE (replace it with the unicode string attribute you will choose)
- If you want to use a Octet String attribute, I will use the “mS-DS-ConsistencyGuid” attribute AS AN EXAMPLE (replace it with the octet string attribute you will choose)
- If pictures show the attribute “iamTECImmutableID”, it is the attribute I used in my test environment after extending the AD schema
REMARK: I’m explaining the configuration for both unicode string attributes and octet string attributes due to the fact the configuration is slightly different for both attribute types
Continue with part 3 here
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
This entry was posted on 2016-05-07 at 23:01 and is filed under Azure AD Connect, Windows Azure Active Directory. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.