Share via

[English] Change ImmutableID* in Azure Active Directoy (AAD/O365) for a Synced (and Federated) User

  • Article

If for some reason, on a synced and federated environment, where the ImmutableID/SourceAnchor is the objectGUID, and needs to be changed for a user(s), e.g. object migrated/moved to a new forest, there are some potential steps that might help to achieve that:
1 - Create a new OU (e.g. OU=tempOU,DC=contoso,DC=com) in Active Directory and move temporarily the user(s) that you need to change the immutableID.

2 - Go to Sync Console, select containers for Active Directory management agent, and filter out the OU.

3 - Run a full sync in order to soft delete the user(s) in the OU and temporarily disable sync.

4 - Run the following in (Azure Active Directory/O365) PowerShell:
Connect-MsolService (Insert AAD/O365 Admin credentials)
Import-Module ActiveDirectory
Get-ADUser -Filter * -SearchBase "OU=tempOU,DC=contoso,DC=com" | select UserPrincipalName | Export-Csv "C:\AADtemp.csv"
$upnsuffix = "@contoso.onmicrosoft.com"

#THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT
#WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED
#TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
Import-Csv "C:\AADtemp.csv" | ForEach-Object {
$upn = $_."UserPrincipalName"
$user = $upn.IndexOf("@")
$upnpreffix = $upn.Substring(0,$user)
$upntemp = "$upnpreffix" + "$upnsuffix"
Restore-MsolUser -UserPrincipalName $upn
Set-MsolUserPrincipalName -UserPrincipalName $upn -NewUserPrincipalName $upntemp
Set-Msoluser -UserPrincipalName $upntemp -ImmutableID "$Null"
$id=(Get-ADUser -Filter {UserPrincipalName -like $upn } -Properties ObjectGUID | select ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($_.ObjectGUID)).tobytearray())})
Set-MSOLUser –UserPrincipalName $upntemp –ImmutableID $id
Set-MsolUserPrincipalName -UserPrincipalName $upntemp -NewUserPrincipalName $upn
}

The above PowerShell cmdlets should first run and be tested on a very small set of test user accounts before executing in any production environment.

5 - Move the users in Active Directory back to their original OU's, enable sync and run full sync so hard match of the objects can occur.

Important Note: Because Azure AD is continuously growing and evolving, the steps presented above, might not work for some or all environments. Due to that fact, you should always opt to follow official supported methods:

a) If you're using a single forest but you want to keep a potential expansion to multiple forests or you're already using multiple forests with an intention to migrate users between them, then do not use ObjectGUID as a SourceAnchor/ImmutableID due to its dependence on AD Forest. Instead select an attribute which doesn’t have to rely on the AD forest. This option is offered in the Azure AD Connect.

b) If you're using a single forest and want to just use a different value for SourceAnchor/ImmutableID for a single or few objects, then deactivate Dirsync on the tenant, wait for all the changes to commit, and then run the Set-MSOLUser cmdlet with -ImmuableID switch to update the new value of SourceAnchor/ImmutabeID. Note that Dirsync may take up to 72 hours to be deactivated.

c) Create a new custom attribute on the new AD Forest where the objects are going to be migrated, and store/populate the current SourceAnchor/ImmutableID in that new attribute. Then, modify the attribute flow in Azure AD Connect to source the SourceAnchor/ImmutableID from that new attribute instead of ObjectGUID. Finally, you can move objects between forests while always maintaining the SourceAnchor/ImmutableID.

Comments

  • Anonymous
    August 12, 2015
    thanks