Part 3 can be found here
–
UPDATE 2016-12-15: With Windows Server 2016 a new attribute called “ms-DS-Source-Anchor” is introduced which could be used as the source for the immutable ID in Azure. Like the attribute I use myself, this attribute is a string attribute. Therefore, where you find the attribute “iamTECImmutableID” in the text, or “extensionAttribute15” could be replaced with “ms-DS-Source-Anchor”. Taken from the protocol documentation. As mentioned earlier, be very careful in using default attributes in the AD schema if its use is not clear.
The msDS-SourceAnchor attribute defines a unique, immutable identifier for the object in the authoritative directory.
cn: ms-DS-Source-Anchor
ldapDisplayName: msDS-SourceAnchor
attributeId: 1.2.840.113556.1.4.2352
attributeSyntax: 2.5.5.12
oMSyntax: 64
isSingleValued: TRUE
schemaIdGuid: b002f407-1340-41eb-bca0-bd7d938e25a9
systemOnly: FALSE
searchFlags: fPDNTATTINDEX | fPRESERVEONDELETE
systemFlags: FLAG_SCHEMA_BASE_OBJECT
rangeLower: 1
showInAdvancedViewOnly: TRUE
Version-Specific Behavior: Implemented on Windows Server 2016.
–
UPDATE 2017-05-16: With AAD Connect version 1.1.524.0 and higher, it enables the use of ConsistencyGuid attribute as the Source Anchor attribute for on-premises AD objects Further, Azure AD Connect populates the ConsistencyGuid attribute with the objectGuid attribute value if it is empty. This feature is applicable to new deployment only. To find out more about this feature, refer to article section Azure AD Connect: Design concepts – Using msDS-ConsistencyGuid as sourceAnchor.
–
After the installation wizard finishes, it is time to reconfigure synchronization rules. It is not supported to edit the default/built-in synchronization rules in any way, except disabling/enabling them. If you need to change a default/built-in synchronization rule, you will to clone it first, disable it, and then edit/configure the clone as required.
But, first of all… How to clone a sync rule?
After opening the Synchronization Rule Editor, you can click on a default/built-in synchronization rule and then click [EDIT].
You will see the following dialog box telling you to clone the default/built-in synchronization rule, disable it, and then edit/configure the clone as required.
Figure 1: AAD Connect Requesting To Clone A Built-In Synchronization Rule First To Become Editable
–
We are going to do this on a per object type.
–
We will start with the “person” object for inbound synchronization
Clone and disable the synchronization rule called “In from AD – User Join”.
While on the “Description” node:
- Assign the name “In from AD – User Join (Custom – <AD Forest FQDN>)” to the clone
- Assign the description “Cloned Sync Rule From ”In from AD – User Join”” to the clone
- Assign the precedence of 60
- With regards to configuring a tag, it apparently is not possible to do that right after cloning a synchronization rule. Finish the configuration of the rule, save it, export it to a PowerShell script, edit the script and add a tag and save the script, and rerun the script to update the cloned synchronization rule
Click on the “Join Rules” node:
If you are using a Unicode String Attribute, configure the join rules as followed (only taking the yellow marked parts into account)
Figure 2: Join Rules For The Cloned Synchronization Rule “In from AD – User Join (Custom – <AD Forest FQDN>)” When Using A Unicode String Attribute
–
If you are using a Octet String Attribute, configure the join rules as followed (only taking the yellow marked parts into account)
Figure 3: Join Rules For The Cloned Synchronization Rule “In from AD – User Join (Custom – <AD Forest FQDN>)” When Using An Octet String Attribute
–
The first yellow marked group (figure 2 and 3) is the first joining criteria which will apply during joining of an AD user object to the MV person object, or during provisioning of the MV person object if the AD attribute containing the source anchor was populated previously.
The second yellow marked group (figure 2 and 3) is the second joining criteria which will apply during provisioning of the MV person object while no value exist in the AD attribute with the purpose of the source anchor.
Click on the “Transformations” node:
Configure the yellow marked part to make sure the attribute listed is populated in the MV after provisioning
Figure 4: Transformation Rules For The Cloned Synchronization Rule “In from AD – User Join (Custom – <AD Forest FQDN>)””
–
The yellow marked transformation is to replace the default transformation that specifies as target attribute “sourceAnchorBinary”. You can just change the transformation my specifying the target attribute “sourceObjectGUIDBinary”. I prefer to use this attribute as it tells me this target attribute will contain the objectGUID in binary format of the source object that contributed the value. In addition, the target attribute will be used in the join rule of both the inbound synchronization rule from AD called “In from AD – User Join (Custom – <AD Forest FQDN>)” and the outbound synchronization rule to AD called “Out to AD – User Common (Custom – <AD Forest FQDN>)”.
–
This synchronization rule is now fully configured and therefore you can save it.
–
Clone and disable the synchronization rule called “In from AD – User AccountEnabled”.
While on the “Description” node:
- Assign the name “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)” to the clone
- Assign the description “Cloned Sync Rule From ‘In from AD – User AccountEnabled’” to the clone
- Assign the precedence of 62
- With regards to configuring a tag, it apparently is not possible to do that right after cloning a synchronization rule. Finish the configuration of the rule, save it, export it to a PowerShell script, edit the script and add a tag and save the script, and rerun the script to update the cloned synchronization rule
Click on the “Transformations” node:
Configure the yellow marked part to make sure the attribute listed is populated in the MV
If you are using a Unicode String Attribute, configure the transformation rules as followed (only taking the yellow marked parts into account)
Figure 5: Transformation Rules For The Cloned Synchronization Rule “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)””. When Using A Unicode String Attribute
–
For BOTH the target attribute “sourceAnchor” and the target attribute “extensionAtttribute15”, the source is:
IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([extensionAttribute15]),[extensionAttribute15],ConvertToBase64([objectGUID]))),IIF(IsPresent([extensionAttribute15]),[extensionAttribute15],ConvertToBase64([objectGUID])))
The expression can be better seen as:
IIF(
IsPresent([msExchRecipientTypeDetails]),
IIF(
[msExchRecipientTypeDetails]=2,
NULL,
IIF(
IsPresent([extensionAttribute15]),
[extensionAttribute15],
ConvertToBase64([objectGUID])
)
),
IIF(
IsPresent([extensionAttribute15]),
[extensionAttribute15],
ConvertToBase64([objectGUID])
)
)
–
If you are using a Octet String Attribute, configure the transformation rules as followed (only taking the yellow marked parts into account)
Figure 6: Transformation Rules For The Cloned Synchronization Rule “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)”. When Using An Octet String Attribute
–
For the target attribute “sourceAnchor”, the source is:
IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid]),ConvertToBase64([objectGUID]))),IIF(IsPresent([mS-DS-ConsistencyGuid]),ConvertToBase64([mS-DS-ConsistencyGuid]),ConvertToBase64([objectGUID])))
The expression can be better seen as:
IIF(
IsPresent([msExchRecipientTypeDetails]),
IIF(
[msExchRecipientTypeDetails]=2,
NULL,
IIF(
IsPresent([mS-DS-ConsistencyGuid]),
ConvertToBase64([mS-DS-ConsistencyGuid]),
ConvertToBase64([objectGUID])
)
),
IIF(
IsPresent([mS-DS-ConsistencyGuid]),
ConvertToBase64([mS-DS-ConsistencyGuid]),
ConvertToBase64([objectGUID])
)
)
–
For the target attribute “mS-DS-ConsistencyGuid”, the source is:
IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID])),IIF(IsPresent([mS-DS-ConsistencyGuid]),[mS-DS-ConsistencyGuid],[objectGUID]))
The expression can be better seen as:
IIF(
IsPresent([msExchRecipientTypeDetails]),
IIF(
[msExchRecipientTypeDetails]=2,
NULL,
IIF(
IsPresent([mS-DS-ConsistencyGuid]),
[mS-DS-ConsistencyGuid],
[objectGUID]
)
),
IIF(
IsPresent([mS-DS-ConsistencyGuid]),
[mS-DS-ConsistencyGuid],
[objectGUID]
)
)
The first yellow marked transformation (figure 5 and 6) will flow the value from either “extensionAttribute15” or “mS-DS-ConsistencyGuid” (whichever you are using) to the “sourceAnchor” if a value already exists. If not, the objectGUID in base64 format will be used as the value.
The second yellow marked transformation (figure 5 and 6) will flow the value from either “extensionAttribute15” or “mS-DS-ConsistencyGuid” (whichever you are using) to respectively the “extensionAttribute15” or “mS-DS-ConsistencyGuid” (whichever you are using) if a value already exists. If not, the objectGUID in base64 format will be used as the value.
–
This synchronization rule is now fully configured and therefore you can save it.
–
Now we need to create a brand new synchronization rule for the “person” object so that the immutable ID value is written back to AD (outbound synchronization) in a manageable attribute of the user object.
REMARK: to AAD Connect to be able to write back the value, the account used in the AD connector must have Allow:Read/Write permissions on the user objects for which it is writing back a value into the chosen manageable attribute that will provide the immutable ID value. To configure the correct permissions you can use the following command:
DSACLS "\\<FQDN RWDC>\<distinguishedName of OU>" /G "<account used in the AD connector>:RPWP;<chosen immutable ID attribute>;user" /I:S
Create/add a new synchronization rule.
While on the “Description” node:
- Assign the name “Out to AD – User Common (Custom – <AD Forest FQDN>)”
- Assign the description “New Sync Rule”
- Assign as connected system the AD forest
- Assign as connected system object type: “user”
- Assign as metaverse object type: “person”
- Assign as link type: “Join”
- Assign the precedence of 250
- Assign the tag “<companyname>.OuttoADUserCommonCustom.001”
- Keep UNchecked “Enable Password Sync”
- Keep UNchecked “Disabled”
Click on the “Scoping Filter” node
If you are using a Unicode String Attribute, configure the scoping filter rules as follows
Figure 7: Scoping Filter Rules For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)” . When Using An Unicode String Attribute
–
If you are using a Octet String Attribute, configure the scoping filter rules as follows
Figure 8: Scoping Filter Rules For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”. When Using An Octet String Attribute
–
This synchronization rule becomes active on a person object in the MV after the listed attribute (figure 7 or 8) has been populated with a value
–
Click on the “Join Rules” node and configure the join rules as follows
Figure 9: Join Rules For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”
–
Click on the “Transformations” node
If you are using a Unicode String Attribute, configure the transformation rules as follows
Figure 10: Transformations For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”. When Using An Unicode String Attribute
–
If you are using a Octet String Attribute, configure the transformation rules as follows
Figure 11: Transformations For The New Synchronization Rule “Out to AD – User Common (Custom – <AD Forest FQDN>)”. When Using An Octet String Attribute
–
This synchronization rule is now fully configured and therefore you can save it.
–
Continue with part 5 here
–
Cheers,
Jorge
———————————————————————————————
* 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/ ########
———————————————————————————————