Office 365 – Why You Need to Understand ImmutableID

As part of planning for your identity with Office 365, it’s important to understand the concept of the “ImmutableID”. By definition, “immutable” means “unable to be changed” which should be sufficient warning that this is something you need to take time to plan properly.
In spite of your planning, your organization could become involved in an unexpected merger, acquisition or divestiture that requires you to make changes to your Active Directory environment; this can have downstream impact to the ImmutableID and thus Office 365.
If you use Directory Synchronization with Office 365 and are looking at a future Active Directory migration project, it’s critical that you understand ImmutableID.
Below are some important concepts to understand around ImmutableID and potential ways to address it as part of Active Directory changes.

Background

If you install DirSync or AADSync with the defaults, the Active Directory “objectGUID” is used as your ImmutableID. After your initial sync, objects in the cloud will have the base-64 version of the objectGUID stamped as the ImmutableID.
In the DirSync / AADSync metaverse, the value is actually stored as “sourceAnchor”. Basically what you have is the attribute flow below:

There are a number of scripts in the TechNet Script Gallery that can help with the base-64 conversion of the objectGUID. I often use GUID2ImmutableID.ps1 as it does the conversion in both directions.

When Your ImmutableID Is Not “Immutable”

The default objectGUID works okay until you start looking at changes to your Active Directory forests. If you have future plans to perform some type of AD forest migration, you’ll want to look at alternatives.
When a user object is moved between domains in an Active Directory forest, the objectSID is changed but the objectGUID remains the same. However, in an AD forest migration, the objectGUID will change and there is no concept of “SID History” with objectGUID. Be aware that even in a domain migration within the same forest, some third-party migration tools actually provision a new user object as part of their sync process and thus would generate a new objectGUID.

How to Change Your ImmutableID

Wait… Didn’t I just say that ImmutableID could not be changed? Well that’s still true, you can’t change the ImmutableID on an object that is being synchronized.
There are, however, ways to change the ImmutableID on an object if you either disable Directory Synchronization in the tenant or move the object out of the scope of DirSync / AADSync. Keep in mind that these can be very disruptive operations and not something I would plan to do unless all other alternatives have been exhausted.
Disabling Directory Synchronization in your tenant can take 72 hours and is not something I would ever consider if you need to change only a few objects. Even in a situation where you’re doing an AD forest migration, it’s not likely that your users are converting over in one single batch.
There are even some ways to change a user’s ImmutableID via “Set-MsolUserPrincipalName” by changing their UPN to a cloud UPN and back however this is would be something you might try while troubleshooting a single user and should not be part of your overall identity strategy.

A More Planned Approach

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

In AADSync, we can select a different attribute than objectGUID as the sourceAnchor during the installation. It’s important to remember the same “unable to be changed” rule applies when you’re selecting this attribute. So while it might seem that something like “employeeID” is a suitable attribute that is unique and never changes, I find that this one starts to falter in organizations that use contractors or have contractors that occasionally get hired as employees. Also, remember that you may have non-user accounts to sync such as shared mailboxes or conference rooms and these won’t have a value for “employeeID”.

Among the attributes that can be used as the sourceAnchor are the Exchange custom extension attributes. The actual attribute here is not as critical as much as the value we populate it with and how we use it. Since objectGUID is guaranteed to be unique, we can still use that to initially populate our selected sourceAnchor attribute. When an object is moved to a new forest as part of our AD forest migration, we can carry over the old objectGUID as a sort of “SID History”.
Here is our attribute flow again (before an AD forest migration) but this time we’re using “extensionAttribute1” as our sourceAnchor:

And here it is after we migrate the user to a new AD forest:

In the above configuration, the on-premises objectGUID changes but the sourceAnchor in the metaverse and the ImmutableID in the cloud are never changed; they still contain the base-64 version of the original objectGUID.
Even in a situation where you’ve previously deployed DirSync with a sourceAnchor of objectGUID, you could move to the above model by installing AADSync, configuring for a different sourceAnchor attribute, populating that attribute and running a sync.

Impact to AD FS

Important to note here is that the default objectGUID is used by the claims issuance rules when you create the relying party trust for Office 365. If you use the above process to change your sourceAnchor from objectGUID to some other attribute, you need to update this claim rule.
To edit the rule:

• Launch the “AD FS Management” console
• Expand “Trust Relationships”
• Select “Relying Party Trusts”
• Right-click “Microsoft Office 365 Identity Platform”
• Select “Edit Claims Rules…”
• Select claim rule #1 and select “Edit Rule”
• Change the value “objectGUID” as seen below to the appropriate sourceAnchor attribute

Additional Reading

Paul Williams has a series of articles covering similar aspects in relation to the FIM MA and Office 365, check out these for some additional reading:

• Multi-forest SSO to O365: implementing multiple immutable IDs
• Windows Azure Active Directory Connector part 3: immutable ID

You may also want to check out these Microsoft notes regarding multi-forest environments and the old FIM MA: Multi-forest Directory Sync with Single Sign-On Roadmap

Summary

• The ImmutableID cannot be changed without significant impact.
• Planning your ImmutableID is critical if an Active Directory forest migration is in your future.
• If you previously deployed using DirSync and objectGUID as the ImmutableID, switching to AADSync can allow you to change the sourceAnchor attribute.
• Changing the sourceAnchor attribute from objectGUID to another attribute requires a change to the AD FS claims rules.

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.