Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 5)

Posted by Jorge on 2016-05-07


Part 4 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.

The next object we need to take into account is the InetOrgPerson object for inbound synchronization

Clone and disable the synchronization rule called “In from AD – InetOrgPerson Join”.

While on the “Description” node:

  • Assign the name “In from AD – InetOrgPerson Join (Custom – <AD Forest FQDN>)” to the clone
  • Assign the description “Cloned Sync Rule From ‘In from AD – InetOrgPerson Join’” to the clone
  • Assign the precedence of 70
  • 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

Apply the exact configuration as explained above for the cloned rule called “In from AD – User Join (Custom – <AD Forest FQDN>)” (part 4 figure 2 or 3, 4).

Next clone and disable the synchronization rule called “In from AD – InetOrgPerson AccountEnabled”.

While on the “Description” node:

  • Assign the name “In from AD – InetOrgPerson AccountEnabled (Custom – <AD Forest FQDN>)” to the clone
  • Assign the description “Cloned Sync Rule From ‘In from AD – InetOrgPerson AccountEnabled’” to the clone
  • Assign the precedence of 72
  • 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

Apply the exact configuration as explained above for the cloned rule called “In from AD – User AccountEnabled (Custom – <AD Forest FQDN>)”.

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 iNetOrgPerson object.

Create/add a new synchronization rule.

While on the “Description” node:

  • Assign the name “Out to AD – iNetOrgPerson Common (Custom – <AD Forest FQDN>)”
  • Assign the description “New Sync Rule”
  • Assign as connected system the AD forest
  • Assign as connected system object type: “iNetOrgPerson”
  • Assign as metaverse object type: “person”
  • Assign as link type: “Join”
  • Assign the precedence of 260
  • Assign the tag “<companyname>.OuttoADiNetOrgPersonCommonCustom.001”
  • Keep UNchecked “Enable Password Sync”
  • Keep UNchecked “Disabled”

For the rest of it, apply the exact configuration as explained above for the new rule called “Out to AD – User Common (Custom – <AD Forest FQDN>)” (part 4 figure 7 or 8, 9, 10 or 11).

This synchronization rule becomes active on a person object in the MV after the listed attribute (part 4 figure 7 or 8) has been populated with a value

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 iNetOrgPerson 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>;iNetOrgPerson" /I:S

Continue with part 6 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/ ########
———————————————————————————————

Advertisements

4 Responses to “(2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 5)”

  1. […] « (2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 5) […]

  2. […] « (2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 5) […]

  3. […] (2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 3) (2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 5) […]

  4. […] (2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 5) […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: