04-06-2017 11:36 AM
04-06-2017 11:36 AM
With the documentation I've found so far I'm a bit unclear whether or not it is best practice to install Azure AD Connect on a domain controller. In this particular scenario we are looking at a single forest, single domain less than 100 users and no plans at this time to use federation.
From this page (Azure AD Connect Prerequisites) it does say:
"Azure AD Connect must be installed on Windows Server 2008 or later. This server may be a domain controller or a member server when using express settings. If you use custom settings, then the server can also be stand-alone and does not have to be joined to a domain."
While I intend to use Express Settings I do intend to uncheck the initial synchronization and then change the OU's to be synched in configuration options. This is a step discussed in the link above.
I'll confess I'm probably being overly-cautious but I'd rather be safe. I've done all this in a test environment and it works fine but would appreciate any deeper insight.
04-06-2017 01:58 PM
The Express setting is by default and the custom you have the options on the below link https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-star...
Regarding the SQL, location, and others.
Yes, you can unckeck the initial sync and than change the OU's.
04-07-2017 06:46 AM
Thanks for the response Nuno. That was helpful. However, do you also have some thoughts regarding the question about installing Azure AD Connect on a Domain Controller?
Again, I'm not seeing anything (yet) that says this is a bad idea in an "Express" scenario like mine. Just that typically Microsoft is very good about being clear on this sort of thing.
Thanks again and let me know if you have some thoughts on the AADC on DC.
04-07-2017 06:52 AMSolution
In my opinion, the recommended installation is always in a separate server regarding to isolate points of failure.
In past time e.g.. Dirsync it was not supported but Microsoft has expanded the support on installation on servers with other roles using Express Instalation.
If you install AD Connect on a DC or other machine with other products, it would be harder to understand a problem if occurs in your environment either the problem is on the DC role or AD Connect.
06-07-2017 11:38 AM
I would like to add that although it is a supported configuration, it's not always best practice. Typically, when you install a domain controller, you want to make sure there are no other services that interfere or compete with the compute, memory, networking, or disk resources. Also, should there be an AAD Connect software error, a reboot may be required. Although the network should include multiple DC's for replication and HA purposes, few admins favor adding more resources to a busy and important server. The enviornments I have seen have been typically independent AAD Connect servers. I hope this helps. - Josh
06-08-2017 09:00 AM - edited 06-08-2017 09:01 AM
I will add my opinion here that i hope will answer your question specifically addressing installing Azure AD connect on a domain controller.
Ill start off with the statement "Just because it is supported, doesn't mean that it should be done". There are many reasons I think Microsoft enabled support for domain controllers, but I would not recommend it. If you can afford another server, then do it. A good rule of thumb, a domain controller is a domain controller and should be nothing else. Also just throwing this out there as well, it is just a good rule of thumb to not dual pupose servers if you can avoid it. This will help prevent outage planning and troubleshooting issues. If you have Azure AD Connect installed on say an Exchange Server, troubleshooting and rebooting would not be possible outside of an outage window or proper planning. Extreme case but something I have ran into with clients.
Back to my original point.
The one reason that I would never encourage someone to install it on a DC is because of the SQL and local admin privileges for AzADC. This instantly means that any AZADC accounts that need admin to the local server are added to the Builtin\Administrators group in AD and now have admin permissions to the domain. Because of this reason alone, I would not need anymore reasons and never recommend installing on a DC.
I hope that helps clarify or add some flavor to your question.
07-24-2017 02:01 AM
In my experience it is not recommended to install Azure AD conect on a DC, Azure AD comes with an SQL express database. Which wil adopt a lot of memory of the current machine. Another issue is that you might need to reboot the Sync server for updates etc, and i think would not like to do that to often to a domain controller. Another thing is the Metaverse sync you can get a lot of bad synced items within the metaverse. This also happens due to short of memory.
And like Nuno said troubleshooting AzureAD Connect will become more difficult for instance if you have duplicate identities or Hash errors.
08-28-2017 05:32 PM
The default install of Azure Connect doesn't install an instance of SQL that is accessible over the network. So, while I understand the security concerns about adding extra roles to a server that is a Domain Controller, I don't see this particular application as a security concern on a DC.
We have installed it on 4 domain controllers for 4 different small businesses that only have one server. While we have noticied some issues with older versions of Connect running on domain controllers, we have not noticed any issues with installing the latest version. Since Microsoft says in the documentation that it may be installed on a Domain Controller, it doesn't introduce any new vectors for attack over the network, and there is no "Best Practices" whitepaper that says it isn't the best way to do it, I will respectfully disagree with the other comments on this point and say that you should feel comfortable putting it on a domain controller if you like.
If you have servers to burn, go ahead and put it on a dedicated server. If not, put it on a domain controller. It is a supported installation.
08-30-2017 08:04 AM - edited 08-30-2017 08:07 AM
Well we have deployed AAD Connect on seprate servers as i dont want to disturb my DC to be overloaded. Also we have redudancy for AAD Connect servers as well to mitigate Risk.
In your case it seems we have only 100 users it seem to be ok to install AAD Connect on DC. Also article you reffered itself says the same "This server may be a domain controller or a member server when using express settings"
So in my opinion I guess there is no harm and later if you want to move AAD Connect to Different server you can do that by getting a server , keeping in staging mode synced and then remove first one and make new active.
But the Best approach is to keep it sweet and simple by keeping it separate.
12-01-2017 12:31 PM
Yes, deploying AD sync on a DC is very common practice. I would recommend installing it also on the secondary dc but not enabling it. Thus, if the Primary goes offline, you can reconnect to Azure AD. :)
03-17-2018 11:36 AM
I personally think you should not install Azure AD connect on a AD Domain Controller. Is it supported, yes, will it work, yes, but in the long term you might find yourself in a difficult situation. As we know Azure AD Connect comes with a build-id SQL Express DB, so placing that instance on the same platform as your NTDS (AD) database wouldn't be the greatest idea. You also have to consider the main factors of system's consumption; general computing (CPU), memory (RAM), network consumption and finally storage (iops). Keep it simple and install it on a small and single VM. That way you can create scheduled snapshots for quick reversions in case things go wrong. Leave Domain Controllers on their own platforms in case you need to perform AD related troubleshooting and in worst case scenarios System State Restore operations.
I hope this helps with your question.
03-21-2018 08:02 PM
One thing that people need to keep in mind if they're not co-locating Azure AD Connect on a DC is this; the server onto which it is installed needs to go into Tier 0 alongside your DCs, because it contains password hashes in memory.
AAD Connect Servers need to be protected just as closely as a DC, so why not just install it on a DC?
Would the answer change if the user count was under 50? Under 25? How about Microsoft allow a no cost vm if it's only used for one thing - Azure AD connect deployment?