Forum Discussion
Migrating On Prem AD to Azure AD and doing away completely with On Prem AD
One of my customers is presently using Azure AD and they are syncing with their On Prem AD using Azure AD Connect. The authentication being used is PHS. Now, they would like to get rid of their On Prem AD completely and would like to know what are the implications in doing so and how users would be affected during the cutover. Since there is no straightforward migration option of On Prem AD to Azure AD completely, what options do i have here ? Will it help to setup an IaaS VM in Azure and promote it as a domain controller and sync it with On Prem Domain Controller? Or we can make use of Azure AD DS service. Any help on this would be appreciated
19 Replies
palchak Old thread comment but we keep an DC on site at each facility. Our manufacturing ops have to run when shifts are scheduled. If there’s a break in the circuit, and it can happen no matter how redundant, the local users and systems can still authenticate w/ DNS available for production equipment. Obviously no access to online resources. We don’t put our ERP or EDI systems in the “cloud”for the same reason. Relying exclusively on cloud authentication is risking contingent business interruption. Something I also find to be a small mark against VoIP.
Hi palchak, did you manage to make it work using only Azure AD DS?
We are about to upgrade our on premise Windows Server Essential 2012r2 to Standard 2019 (we reach max users limit) and are looking for options , since all of our users are working remotely and using Office365.
GPOs are not an concern and would be nice to get rid of our On Prem AD.
- Any update on this?
If you do not have lot of group policy dependecy then upgrade to AD premium p2 for joining device to AAD or ntune management.
If you would like to use AADS as managed domain controller then you may have to build another registered domain like .org or .net built trust with .local domain and add domain suffix for azure AD domain the syncs to cloud identity. In other words you are still managing two namespaces until you completely move identity to cloud with intune instead of GPO.
AADS does not support schema extension or sync, it will be created with two OUs initially and you will have to built rest manually and apply policy probably from CSV import or xml import/export or add manually and install azure ad connect server on cloud to sync.
I am planning same considering I do not have lot of group policy for stand alone mac users. I only have to figure out joining VMs directly to Azure AD and not go through building cross forest trust just to survive on old GPO.
First I am looking to convert all server VMs to as much as PAAS solution and work on identity management to AAD after I build complete cloud presence that way I am not reliant on prem hardware when switches of firewall goes down. user can still connect with wifi
- Any progress in the solution?
palchakTo work out what your options are you will need to know what your current dependancies on the on-premis AD is. e.g. what devices are joined, what applications rely on AD for authentication, any changes to the schema. If there are components dependant/integrated in to AD then you will need to look at an IaaS instance in Azure as opposed to just using Azure AD. When considering an IaaS instance then a couple of things to watch out for, latency and also depending on the size of your directory - initial replication could take a while.
009GH What about using Azure AD DS, the managed domain service in Azure, to use that, do you still need to keep the Azure Connect Sync intact , because using Azure AD DS you can create customised OUs and even Group Policies, so can AD DS be considered a replacement for On Prem AD DS.
Using the cloud Azure AD DS is a better option as it is a managed service and you don't have to spin up DCs in Azure and patch them and monitor them etc. Any comments please.
Why are you looking into setting up an Azure IaaS DC?
I know the migration will be much smoother from an on-prem DC, but I would really recommend going with AAD. Creating users in AAD and joining computers to AAD.
The question still remains what is the best way to migrate from On-Prem to ADD. I inherited an account with some uses in ADD and some in On-Prem AD. They all have email accounts O365, so they have an ADD account but manages On-Prem. I'm trying to get them all managed in ADD but haven't figured out how. For now it looks like backup the email and Onedrive data. Delete the account in both places. Then recreated the account in ADD and restore email and data.
Is there a better way?
- This describes the process pretty well: https://www.sikich.com/insight/office-365-convert-an-active-directory-synced-account-to-cloud-only/
Thijs Lecomte But my customer already has synced users in Azure AD from On Prem and they have i guess PTA enabled and using AD Connect.So all the authentication is taking place at On Prem. So now if i shut down the On Prem DC suddenly , how will the Azure synced users authentication take place, the users are not born in the cloud but synced to Azure AD
- You will have to recreate the user profiles of the users when you do an Azure AD Join.
For users, you have to convert them to cloud only accounts (http://www.blogabout.cloud/2019/08/871/)
- Hi Palchak,
I vote for IaaS, promoting DC vm in Azure AD and S2S vpn. MSFT has started supporting features that were available in Azure AD domain services (check article below). I think you can also save money with IaaS option.
Good luck and let us know if you have any other questions!
https://cloudbymoe.com/f/enable-ad-authentication-for-azure-smb-file-sharesMoe_Kinani So after spinning up an IaaS VM and promoting it to a DC and ensuring it is replicated properly from On Prem DC, can i just go ahead and decommission the On Prem DC ? Will the DC that is in Azure now, can take care of all the authentication of the synchronised users from On Prem? What about the On Prem machines, can they use the new Azure AD DC to authenticate also, will that work?
- It will work but it would take more time to authenticate because depending on S2S connection to go all the way to Azure DC. You need to make sure FSMO roles have moved to Azure DC and DNS is propely configured for those PCs pointing to Azure DC etc.
I always recommend to have DC on Prem so authentication will be faster and not depend on S2S vpn.
Hope this helps!
Moe
