Jorge's Quest For Knowledge!

All You Need To Know 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 4)

Posted by Jorge on 2016-05-07


Part 3 can be found here

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.

image

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)

image

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)

image

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

image

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)

image

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)

image

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

image

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

image

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

image

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

image

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

image

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/ ########
———————————————————————————————

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

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

  2. […] for the cloned rule called “In from AD – User Join (Custom – <AD Forest FQDN>)” (part 4 figure 2 or 3, […]

  3. […] for the cloned rule called “In from AD – User Join (Custom – <AD Forest FQDN>)” (part 4 figure 2 or 3, […]

  4. Alan said

    Thanks again for the great articles. Just wondering what complications would arise if during installation you chose to still match on mail address (rather than the field holding the custom immutableID) but chose to use the custom immutableID for the source Anchor? So match on mail and use myCustomID as the sourceAnchor? My provisioning rule (i.e. figure 2 in this article) then contains another Join rule group mail = mail above the 2 existing join rule groups shown in your figure 2. Will this cause complications?

    Thanks again

    • Jorge said

      Hi,

      As mentioned in https://jorgequestforknowledge.wordpress.com/2016/05/07/azure-ad-connect-identifying-objects-in-ad-and-in-azure-ad-part-4/ you should use an attribute that will not change and is immutable. In that blog post, in the example I used “extensionAttribute15” as the immutable ID attribute in AD. You can use any attribute as long as it is unique and immutable.
      The mail attribute is, or should be, always unique. However, I have also seen places where it is not unique. Why? For example, a person might have 2 accounts, one regular user account and one admin account. The regular user account is mailbox enabled and the admin account is not. However, for administration purposes (or other purposes) the mail address of the regular account is also copied into the mail attribute in the admin account. That would end up in having 2 AD accounts joining the same MV object.

      Looking at your suggestion, I would not use the mail attribute and still stick to the AD attribute with the immutable ID value. Remember that the Immutable ID is an immutable value for the AD account, not for the person using the account!

      Best Regards,
      Jorge

      • Alan said

        Thanks for the thorough response. I am now having to revisit this and have a further question. If I have two domains with an active account in one domain and a disabled mail-enabled user in another, how would these two accounts match to a singe metaverse object if I don’t match on mail?

        Thanks again

        Alan

        • Jorge said

          Hi,
          Of the active account is provisioned for authentication and authorization and the mailbox enabled account is provisioned as a resource in another domain (same forest or other forest?, assuming other forest) I do not understand why the active account does not have the mail address stamped in its mail attribute so that can be uniquely matched.
          If you cannot use the mail attribute you will need to look for another attribute that will deliver a single/unique match

          Best regards,
          Jorge

  5. Gordy said

    Hi Jorge..thanks for the article. We have an issue after implementation in that Distrubution Groups in AD are not syncing to AAD ..have you seen this before ?

    • Jorge said

      It is really very difficult to say what is wrong with the information you provide.
      Something is either wrong with the data or with the rules

      Have you tried a Generate Preview to see what happens?

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: