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-01-17) Azure AD Connect – Identifying Users In AD And In Azure AD (Part 1)

Posted by Jorge on 2016-01-17


Like in AD, users in Azure AD (ADD) must be uniquely identified. When synchronizing users from AD to AAD, AD is the authoritative source and must therefore provide all the data to uniquely identify the user in AAD. Within Azure AD all users must be uniquely identified by 2 attributes, being an Immutable ID (sourceAnchor) and a User Principal Name.

Source Anchor: This attribute is immutable during the lifetime of a user object. It is the primary key linking the on-premises AD account with the Azure AD account.

User Principal Name: This attribute is used by users, for both regular accounts and admin accounts, when logging on to Azure AD and Office 365.

The preferred synchronization tool of choice is the sync engine available in Azure AD Connect. During the installation of Azure AD Connect in the section “(Uniquely) Identifying (Your) Users” one must specify for:

  • “Select how users should be identified in your on-premises directory” (a.k.a. “Join Criteria”) –> which attribute or attributes should be used in the sync rule “In from AD – User Join” (for user objects) and sync rule “In from AD – InetOrgPerson Join” (for InetOrgPerson objects)
  • “Select how users should be identified with Azure” –> which attributes should be used as the identifiers (for source anchor and user principal name) in AAD for the user account

Multiple choices exist, and with this blog post I will explain all the options and provide the corresponding configurations so that you can see what you get when making a specific choice, but before installing Azure AD Connect.

image

Figure 1: (Uniquely) Identifying (Your) Users – Option 1 – “Users Are Represented Only Once Across All Directories”

With the selected options under “Select how users should be identified with Azure”, the attribute listed as the source anchor will be used as the source for the sourceAnchor attribute in Azure AD. By default it specifies the objectGUID, and in this case it lists iamTECImmutableID which is a custom attribute that I added to the schema of my AD. More info about this in a later blog post.

In the default sync rules “In from AD – User AccountEnabled”, “In from AD – User Common”, “In from AD – InetOrgPerson AccountEnabled” and “In from AD – InetOrgPerson Common” the following attribute flow exists:

Expression(IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,IIF(IsString([<attribute listed as source anchor>]),CStr([iamTECImmutableID]),ConvertToBase64([iamTECImmutableID]))),IIF(IsString([iamTECImmutableID]),CStr([iamTECImmutableID]),ConvertToBase64([iamTECImmutableID])))) ===> attribute(sourceAnchor)

The expression can be better seen as:

IIF(
     IsPresent([msExchRecipientTypeDetails]),
     IIF(
          [msExchRecipientTypeDetails]=2,
          NULL,
          IIF(
               IsString([<attribute listed as source anchor>]),
               CStr([<attribute listed as source anchor>]),
               ConvertToBase64([<attribute listed as source anchor>])
          )
     ),
     IIF(
          IsString([<attribute listed as source anchor>]),
          CStr([<attribute listed as source anchor>]),
          ConvertToBase64([<attribute listed as source anchor>])
     )
)

In the same 4 default sync rules the following attribute flow exist:

Expression(IIF(IsPresent([userPrincipalName]),[userPrincipalName], IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))) ===> attribute(userPrincipalName)

The expression can be better seen as:

IIF(
     IsPresent([<attribute listed as user principal name>]),
     [<attribute listed as user principal name>],
     IIF(
          IsPresent([sAMAccountName]),
          ([sAMAccountName]&"@"&%Domain.FQDN%),
          Error("AccountName is not present")
     )
)

With the selected options under “Select how users should be identified in your on-premises directory”, the join rules in the default sync rules “In from AD – User Join” and “In from AD – InetOrgPerson Join” list the following when the option “Users are represented only once across all directories” is selected. In this case the objectGUID is used to join/match/link objects.

image

Figure 2: Default Join Rules For User And InetOrgPerson Objects When “Users are represented only once across all directories” Is Selected

With the the option “Users identities exist across multiple directories. Match using:” you can choose yourself which attribute is used to used to join/match/link objects.

When you choose the mail attribute….

image

Figure 3: (Uniquely) Identifying (Your) Users – Option 2 – “Users identities exist across multiple directories. Match using: ‘mail’”

…the join rules in the default sync rules “In from AD – User Join” and “In from AD – InetOrgPerson Join” list the following when the mail attribute is used to join/match/link objects.

image

Figure 4: Default Join Rules For User And InetOrgPerson Objects When “Users identities exist across multiple directories. Match using: ‘mail’” Is Selected

When you choose the ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID attributes….

image

Figure 5: (Uniquely) Identifying (Your) Users – Option 3 – “Users identities exist across multiple directories. Match using: ‘ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID’”

…the join rules in the default sync rules “In from AD – User Join” and “In from AD – InetOrgPerson Join” list the following when the ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID attributes are used to join/match/link objects.

image

Figure 6: Default Join Rules For User And InetOrgPerson Objects When “Users identities exist across multiple directories. Match using: ‘ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID’” Is Selected

When you choose the ObjectSID/msExchangeMasterAccountSID/msRTCSIP-OriginatorSID attributes….

image

Figure 7: (Uniquely) Identifying (Your) Users – Option 4 – “Users identities exist across multiple directories. Match using: ‘SAMAccountName/MailNickName’”

…the join rules in the default sync rules “In from AD – User Join” and “In from AD – InetOrgPerson Join” list the following when the SAMAccountName/MailNickName attributes are used to join/match/link objects.

image

Figure 8: Default Join Rules For User And InetOrgPerson Objects When “Users identities exist across multiple directories. Match using: ‘SAMAccountName/MailNickName’” Is Selected

And last but not least, you have the option to specify another attribute. You can use any attribute that is available in the AD schema, but make sure when you choose another attribute, that attribute really is able to contribute in joining/matching/linking objects. In addition, if you choose an attribute that is not already known in the metaverse (MV), you will end up with errors during the installation as described in this blog post (2016-01-10) Joining Criteria In Azure AD Connect Throws An Error When Leveraging A Custom Attribute. In this case I chose an attribute that I added to the AD schema myself and in that case…

image

Figure 9: (Uniquely) Identifying (Your) Users – Option 5 – “Users identities exist across multiple directories. Match using: ‘<Custom Attribute>’”

image

Figure 10: Default Join Rules For User And InetOrgPerson Objects When “Users identities exist across multiple directories. Match using: ‘<Custom Attribute>’” Is Selected

You have seen now how this is configured for users. How about all the other objects? Well that’s for the next part in these series!

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

One Response to “(2016-01-17) Azure AD Connect – Identifying Users In AD And In Azure AD (Part 1)”

  1. […] mentioned earlier in this blog post, and this blog post, both users, groups and other objects must be uniquely identified in both AD […]

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: