Forum Discussion
Convert On-Prem AD Users from Office 365/Azure AD to In-Cloud accounts
I have tested this scenario half a year ago because I have a client who will need the same. Worked out well. Please try this in a lab environment first.
#Requirements: Managed domain, Global Administrator, Domain Admin, Active Directory Users and Computers, AD Connect, PowerShell-modules MSOnline & ADSync
#Connect with MSOL
$credential = Get-Credential
Connect-MsolService -Credential $credential
#Check DirSync status
Get-MSOLCompanyInformation | select DirectorySynchronizationStatus
#Backup all ImmutableIDs of federated users
Get-MsolUser | select userprincipalname,immutableid | sort userprincipalname | Export-Csv -Path $env:USERPROFILE\Desktop\ImmutableIDs.csv -NoTypeInformation -Force
#Migrate synced user to cloud only
Step 1: Disable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $false
Step 2: Nullify ImmutableID !!! Make sure you add quotation marks to $null
Set-MsolUser -UserPrincipalName user@domain.com -ImmutableId "$null"
Step 3: Move nullified users to non-synced OU
Step 4: Enable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $true
Step 5: Force AD Connect sync
Start-ADSyncSyncCycle -PolicyType Delta
#Revert migration of user
Step 1: Disable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $false
Step 2: Move user to original OU
Step 3: Put back the ImmutableID of the user
Set-MsolUser -UserPrincipalName user@domain.com -ImmutableId "ID"
Step 4: Enable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $true
Step 5: Force AD Connect sync
Start-ADSyncSyncCycle -PolicyType Delta
After converting an on-prem user to a cloud user, by nullifying the ImmutableId, has anyone been able to verify that the PowerShell command, whoami, returns AzureAD\username instead of ONPREM\username ?
This is the issue we're currently experiencing and we are concerned with any possible adverse affects it might cause to the AzureAD user object functionality and stability. We're currently not experiencing any visible issues at the moment, however. -Josh
Josh-M I tried looking into this as well, I did receive some information from Microsoft. I still don't know if this causes any issues, it doesn't seem to negatively impact anything in a sandbox environment. Also with one user in a production environment.
"This a known gap, that we're reviewing. Even though you have migrated the user from AD to Azure AD, the onprem SamAccountName is still intact on the user object, among other on-prem AD attributes. As a result, Azure AD picks those details and shows domain/user instead of AzureAD/user. This attribute cannot be modified or cleared through Graph APIs at this point, so there's no way to change the behavior. Please file a UserVoice suggestion on MS Graph for this so that our teams can get the feedback and prioritize it as needed"
Source:
https://github.com/MicrosoftDocs/azure-docs/issues/38048#issuecomment-528570435
- Whoami will always execute in the context of the account logged onto the desktop. If your computer is part of an AD domain and you'velogged on with a domain account, it will be DOMAIN\USER.
I never thought about it until you mentioned it now. whoami returns ONPREM\username for my converted user. I would assume that is because the user is still in an on-prem OU. While that OU is not synced with ADSync, the metadata for that user is still there.
This computer was built from new and only using the AzureAD username so I'm sticking with it being the metadata.
