(2016-05-07) Azure AD Connect – Identifying Objects In AD And In Azure AD (Part 1)
Posted by Jorge on 2016-05-07
As mentioned earlier in this blog post, and this blog post, both users, groups and other objects must be uniquely identified in both AD and Azure AD (AAD). During the installation of Azure AD Connect (AAD Connect) you must specify the attributes for both the source anchor and the user principal name. By default that’s respectively the “objectGUID” and the “userPrincipalName“, but you can choose other attributes as needed. In addition, you also specify the joining criteria to match up objects when having a single AD forest or multiple AD forests, in regular day-to-day scenarios, but also during disaster recovery scenarios.
If you have a single AD forest with either a single AD domain or multiple AD domains, or if you have multiple AD forests where each AD forest hosts unique AD accounts that are not hosted in any other AD forest, then the explanation below also applies.
Please understand that the explanation below specifically applies to those AD forests that have multiple AD domains. However, although not necessary right away, you will not loose anything when having an AD forest with a single AD domain. The solution below is to keep other options available for future plans that may not be needed on short term.
What I’m about to explain here has already been discussed in the following 2 blog posts. In this blog post I’m giving my opinion on how it should be done in a supported and very detailed way:
Within Azure AD all objects must be uniquely identified by 1 attribute and users by 2 attributes. For all objects the Immutable ID (sourceAnchor) is required and in addition for users, the User Principal Name is required due to authentication requirements.
Source Anchor: This attribute is immutable during the lifetime of an object. It is the primary key linking the on-premises AD object with the Azure AD object.
User Principal Name: This attribute is used by users and iNetOrgPersons, when logging on to Azure AD and any of its backend services.
In the scenario where you have a single domain AD forest or a multiple domain AD forest where users and iNetOrgPerson objects are uniquely identified in one single AD forest, you can happily choose the following options:
Figure 1: (Uniquely) Identifying (Your) Users – “Users Are Represented Only Once Across All Directories”
In this case, by default as the sourceAnchor the objectGUID attribute is chosen and as the User Principal Name the userPrincipalName attribute is chosen. Choosing the objectGUID attribute as the sourceAnchor is OK in the following scenarios:
- When having 1x single domain AD forest with accounts;
- When having 1x multiple domain AD forest with accounts and accounts are not moved between AD domains in any way
Based upon the on-premises AD account with its specific and unique objectGUID, an Azure AD account is provisioned using the base64 format of the objectGUID as the Immutable ID (sourceAnchor) for the Azure AD account. When deleting the on-premises AD account and recreating it in the same AD domain or another AD domain using the same names for the same person, also a new Azure AD account will be created through synchronization. Everything (devices, online mailbox, etc.) connected/linked to that previous Azure AD account is lost and not reconnected automatically to the new Azure AD account. The Immutable ID of an Azure AD object is set during the creation of the object and it cannot be changed during the lifetime of the object.
Why can this default configuration become a problem?
Any company with a multiple domain AD forest, that also moves objects between AD domains very likely in any of the following scenarios:
- People move between AD domains due to relocation of new job/role;
- A company decides at some point in time to consolidate the multiple domain AD forest into a single domain AD forest, or consolidate some smaller AD domains into some larger AD domain(s);
- Any other scenario that involves moving AD objects to other AD domains while still requiring the use of the same Azure AD objects;
- Any other scenario that involves recreating AD objects in the same AD domain while still requiring the use of the same Azure AD object
For example, assuming the company is using online exchange mailboxes, moving all AD accounts from the child AD domains to the forest root AD domain would mean that all Azure AD accounts, including the attached online exchange mailbox, are lost as the Azure AD account cannot be linked to the new AD account in the other AD domain.
There is a easy solution to this challenge that helps you take possible future plans into account. Using the value in the “objectGUID” attribute is not the problem. The problem is when you need to reuse the value of the “objectGUID” attribute. The “objectGUID” attribute is system owned/managed and cannot be managed in any way when users are recreated or moved between AD domains. Therefore the solution is to use an attribute that can be easily managed when a user is moved to another AD domain.
Now the question arises of “which attribute should be used then?”
My personal opinion about the AD schema, that you should be very careful in misusing existing not yet used attributes defined in the AD schema. If the technical characteristics of the data do not (fully) match the technical characteristics of the (already) available attribute in the AD schema, it is highly recommended not to change any of the technical characteristics of the attribute in the AD schema. If the purpose of the data does not match the purpose of the (already) available attribute in the AD schema, but all technical characteristics do match, it is still highly recommended not to use that attribute. Misusing an attribute in the AD schema (reconfiguring or different purpose), might lead to a data migration and system/application reconfiguration if another system/application (e.g. AD itself, Microsoft application or other third-party application) legitimately wants to use the chosen attribute. That will impact both the user population and IT. In both these scenarios it is better to design a custom AD schema extension, test and implement that accordingly.
One of the disadvantages of implementing an AD schema extension, is that people might be afraid of doing it, and that it might take more time to implement due to possible procedures and politics. Therefore instead of misusing an existing attribute, the proposed solution is to extend the AD schema with a custom attribute that fits the purpose of its use. For this scenario I have extended the AD schema with the attribute “iamTECImmutableID” that can be used for users and groups.
At a high level the design of the custom attribute is:
- Attribute Purpose: This attribute is stores the immutable identifier value for the object
- Active/Inactive (isDefunct): Active
- Object Class (objectClass): top + attributeSchema
- Assigned OID (attributeID): <your OID namespace + unique value>
- Schema ID GUID (schemaIDGUID): <your unique base64 value that is used across AD forests)
- Common Name (cn): iamTEC-Immutable-ID (REMARK: make sure to use your own prefix!)
- LDAP Display Name (lDAPDisplayName): iamTECImmutableID (REMARK: make sure to use your own prefix!)
- Description (description): Immutable Unique Identifier For The Object
- Admin Display Name (adminDisplayName): iamTEC-Immutable-ID (REMARK: make sure to use your own prefix!)
- Admin Description (adminDescription): Immutable Unique Identifier For The Object
- Attribute Syntax (attributeSyntax): 188.8.131.52 (UNICODE)
- OM Syntax (oMSyntax): 64 (UNICODE_STRING)
- Single/Multi-Valued (isSingleValued): TRUE (= Single Valued)
- Member Of PAS (isMemberOfPartialAttributeSet): FALSE (Does Not Replicate To GCs) (REMARK: Configure This With TRUE If There Is Any Application That Needs to Gather This Data From A GC)
- Regular Index Required (searchFlags): TRUE (hex:0x00000001, dec:1)
- Container Index Required (searchFlags): FALSE
- Tuple Index Required (searchFlags): FALSE
- Subtree Index Required (searchFlags): FALSE
- Copy Attribute Value(s) When Copying Object (searchFlags): FALSE (REMARK: The data is user specific)
- Part of ANR (searchFlags): FALSE (REMARK: The data is not used in address book lookups)
- Preserve On Deletion (searchFlags): TRUE (hex:0x00000008, dec:8) (REMARK: While the Recycle Bin optional feature IS NOT enabled, preserving this attribute value on the tombstone object (the deleted object) is good. By preserving this data, the impact on the user community is lowered as much as possible. HOWEVER, while the Recycle Bin optional feature IS enabled, all data on an AD object is already preserved by default on a deleted object, whether this flag is enabled or not. Enabling this flag then preserves the data when the deleted object transforms into a recycled object manually or automatically. However recycled objects cannot be undeleted, therefore there is no value in preserving this data on recycled objects.
- Confidential (searchFlags): FALSE
- Never Audit Attribute (searchFlags): FALSE
- Member Of FAS (searchFlags): FALSE (REMARK: Does Replicate To RODCs)
- Replicated Between DCs (systemFlags): TRUE (REMARK: The attribute is not DC specific and also not calculated)
- Constructed Attribute (systemFlags): FALSE (REMARK: The attribute is not calculated on the fly when requested. The attribute actually stores data)
- Attribute Linking (linkID): N.A. (REMARK: The attribute does not store a link to another object)
- Attribute in GAL (mAPIID): N.A. (REMARK: The attribute does not need to displayed in the global address list)
- Member Of Property Set (attributeSecurityGUID): N.A. (REMARK: The attribute is not used in any property set)
- Show In Advanced View Only (showInAdvancedViewOnly): TRUE
- Associate Object Class (<Property>): user (mayContain) + group (mayContain) (REMARK: Not needed to specifically add the attribute to the iNetOrgPerson object because the iNetOrgPerson object inherits everything from the user object (iNetOrgPerson is a subClassOf user))
REMARK: Remember that the AD schema was designed to be extended as needed. It is important to have a procedure in place to extend the AD schema so that no mistakes are made. Rule of thumb when extending the AD schema ==> do you homework! (and you should be fine!)
REMARK: If you do not want to extend the AD schema, you need to choose an attribute you can manage. Preferably, it should be an Unicode String attribute (e.g. one of the extensionAttribute attributes). It is also possible to use an Octet String attribute, like “mS-DS-ConsistencyGuid”. In either case I cannot and will not give you any guarantee that the existing attribute you choose will not be used in the future by some Microsoft or Third-Party vendor application.
REMARK: Now you might think “let’s use the e-mail address or the userPrincipalName as the immutable ID as that is required to be unique”. Well that is true, but unfortunately the sourceAnchor attribute in Azure AD does not support values with an “@” in the value!
Whether or not you use an existing attribute in the AD schema or extend you AD schema, the question remains on how to generate an unique value that can be used as the Immutable ID value for an Azure AD account. The unique value must be 100% guaranteed to be unique and it must be under control of the same department managing AD and Azure AD without additional management overhead. The answer to the solution is the Azure AD Sync Service that synchronizes the (scoped) on-premises AD accounts to Azure AD.
Continue with part 2 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:00 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.