Feb 01 2017
05:41 AM
- last edited on
May 24 2021
02:31 PM
by
TechCommunityAP
Feb 01 2017
05:41 AM
- last edited on
May 24 2021
02:31 PM
by
TechCommunityAP
Hi
We have currently setup a ADConnect Sync to Office 365, this is working well.
We would like to start converting Sync'ed accounts in Office 365/Azure AD to "In Cloud" accounts. Can you advise or does anyone know how we might approach this? Or can point to alternative resources?
We need to ensure the accounts in Office 365/Azure AD remain active and usable.
Much appreciated
Paul
Jan 15 2019 06:30 AM - edited Jan 15 2019 06:31 AM
We ended up switching our Azure AD Connect Source anchor from Objectguid to ms-DS-consistencyGUID (as recommended by Support). This works for us because it allows us to recover deleted accounts via hard linking to on-prem AD accounts. Before we would control this by manipulating the immutableID of the Azure AD user. Now we just manipulate it on the on-prem AD side. Here is blog post which illustrates this process: https://blogs.technet.microsoft.com/latam/2018/03/27/using-the-consistencyguid/
Jan 15 2019 04:41 PM
I thought everyone else said -ImmutableID does not work anymore?
Can anyone confirm this? Or have you tried this?
Jan 16 2019 12:04 AM
@Jessie Hernandez seems to be answering to a totally different thing than what was asked. Yes, you can link the existing Azure AD user to a different on-prem AD user using the ms-DS-consitencyGUID attribute. But you cannot use it to make users cloud-only (which was the original question).
The method suggested by @RedRobot works, because you can change the ImmutableId when the sync is not enabled. However, this is a very heavy method if needs to be done daily. But as said, it works.
Mar 06 2019 03:45 AM
Mar 06 2019 04:46 PM - edited Mar 06 2019 04:47 PM
I did log a ticket with MS last few weeks ago, they also said they will revert back the changes. I am wondering if they already did?
Anyone can confirm it is now working again? (I am too lazy to test..LOL).
Mar 06 2019 04:49 PM
It is working. I did so last night with 2 users. They were successfully converted to Azure AD users (cloud users) that used to be sync'd from on-prem by nulling the ImmutableID
Mar 06 2019 05:01 PM
Thats good news...!
Mar 25 2019 12:09 PM
Mar 26 2019 01:26 PM
@crice011 We are getting an error "You must provide a required property: Paramet name: FeeratedUser.SourceAnchor" So we have to set the domain to a managed domain domain.onmicrosoft.com then we can set the ImmutableID to Null, we can't change it back to the domain.com after.
Mar 26 2019 02:01 PM
@Jamie Luce I don't think you can set the immutableID to null unless it is a managed domain so that is likely why you can't change back to federated.
Maybe try this article and see if that fixes it
Mar 26 2019 11:02 PM
@Jamie Luce, I'm not quite sure why you need to convert federated users to in-cloud, as they are (typically) synchronized from on-prem AD and are depending on the federation server?
Anyways, there can also be cloud-only federated users, so you can change the UPN back to domain.com. You just need to give immutableId that matches the value your federation server is offering for the user when he/she logs in.
So, this is possible but not very practical and needs some setup to do in your federation server. If you'd like to give it a try, let me know and I'll give you detailed instructions.
Mar 27 2019 06:09 AM
@Nestori Syynimaa We have some resource rooms that need to be licensed and have a password, but the Resource Manager that we use cannot handle Multifactor Authentication. We had these rooms syncing from on prem before but now we just need them to be cloud to take them out of Multifactor (Ping Federate). We are creating all new Resources as cloud accounts directly but we didn't want to lose the info on the ones we were already using, so we deleted the AD account on prem, then restored it as a Cloud Account.
Then ran into the sync problems with it being removed since it still thought it was a deleted account. I'm interested in those instructions if you could PM them to me. Thanks
Mar 27 2019 11:25 PM
@Jamie Luce, I'm sorry but that scenario is not possible.
If I understood correctly, you want to make resource rooms cloud-only so that you can authenticate directly to Office 365 (Azure AD). The authentication (managed/federated) is defined per domain, so despite that users can be cloud-only, the authentication remains the same.
However, you can give these resource rooms (users) another domain (resource.domain.com etc.), which is not federated. Then give them an alias with original domain. With this scenario, you could sync them from on-prem AD and still use the original domain to reserve rooms.
For the AD-removal-deletion issue, I think you need to do the following:
May 09 2019 03:17 AM - edited Sep 04 2019 01:32 PM
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
Sep 04 2019 01:15 PM
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
Sep 04 2019 01:26 PM
@Josh-M Hi Josh, it's an interesting question and it comes up in my mind every now and then. I haven't had any trouble in my lab with users or Microsoft services. Though the lab did not run for long time and I cannot remember what whoami would return.
I have planned the conversion for my client in a few months. This is a 150 seat tenant with only saas apps and all data stored in sharepoint/onedrive. I don't foresee any issues in this scenario, but perhaps your infra is more complex.
Keep us posted, thanks.
Sep 04 2019 01:49 PM
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.
Sep 04 2019 02:21 PM
It’s a good question and I’ll double check in the morning on our tenant.
I do know though that after migrating users to on-cloud and removing the immutable ID, the authentication in tools like Outlook went from being domain\username to email address.
I’ll post back in the morning.
Sep 04 2019 09:53 PM
Sep 06 2019 09:07 AM
@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