Azure AD Connect – Starting Out Considerations

I’ve been talking a lot about Identity lately, and the most common configuration is a hybrid setup that utilizes the best of both worlds! I’m talking about Windows Server Active Directory for your on-premises and Azure Active Directory for your Microsoft cloud…this is the most common because it allows for local servers and resources, easy identity management, and extended identities into the cloud where you can layer on SaaS applications and other awesome things like Microsoft 365.

Now, if you don’t already have a testing environment may I suggest you hop over to https://portal.azure.com and signup for a free trial account. This will allow you to run 30 days of free Azure awesomeness! Well, certainly enough to setup a small test environment with some Windows Server Active Directory; add some users, and then head into the Azure Active Directory blade and download Azure AD Connect, the pass-through authentication agent, and the Seamless single sign-on agent.

This is where we’re going to pick up and talk about some prerequisites using a sample use case to help us select some options and add-ons.

We’ll be looking at this Microsoft Doc to pull out some of the targeted requirements.

The Use Case:

In our example case we want to enable extended identities and let our users be able to reset their passwords using self service password reset. Further, we will be integrating some SaaS apps another day (Like Dynamics or sales management apps.), but we want to ensure that we are ready to add those apps into Azure and that we can easily assign users to them. Additionally, we will want our users to always use on-premises authentication passed back from Azure Active Directory so that we are in control, and we want users to be logged in automatically to Microsoft Office 365 services such as Exchange Online and Teams software, even if it’s in a webpage.

Requirements for our On-Premises Systems:

• Since we are creating new virtual machines in Azure to create our lab, our Windows Server Active Directory schema will be 2016 if we use Windows Server 2016 servers (Yes, we should use 2016 or 2019 depending on the standard you’re currently working under.)
• Since we need to allow Azure self service password resets, we’ll need to meet the password write-back requirements for higher than Windows Server 2008R2 server operating system software. We’ll easily meet this in the lab by using Server 2016 or higher.
• We should enable our Windows Server Active Directory recycle bin.

Other Considerations:

• Our domain name should be simple for lab purposes. Think example.local or example.company; but please do stay away from routable domains such as .com or .net when setting up a Windows Server Active Directory domain name. We’ll get into that another day, but let’s roll with it today.
  • As a note, we are ABLE to use routable domains in this way. In our example we are trying to keep things simple and we will not be adding the custom external domain into Azure this time.
• Since we’ll have an existing handful of users in our lab AD, you should run the ID Fix tool to ensure our accounts are ready to synchronize and extend into Azure Active Directory.
• Remember since we’re using free Azure AD, we are limited to 50,000 objects. If you’re also using PowerShell to add your Windows Server AD accounts, you may get excited and think you can beat that number; but alas, you will be limited in your sync via Azure AD Connect. Let’s just use a handful of accounts for our proof of concept testing here.
• As part of your setup for Azure AD Connect, you will need to enable password write-back to meet our business requirements.
• You will need to create a couple of security groups in your Windows Server AD and add some different users into each group. These will be used in the future to assign rights in Azure AD for SaaS applications such as Dynamics or other software based in cloud.
• You should understand what type of database (on the Azure AD Connect server or an external SQL database) that you would like to use for the installation. The default does meet most needs and is a local install of SQL Server 2012 Express LocalDB. There are additional considerations that you can read in the Microsoft Doc.
• We don’t address redundancy in this scope, but it is important in your production environment to use more than 1 server for Azure AD Connect, Pass-through Authentication Agents, and the Seamless Single Sign-On agents.

Installation Prerequisites for the Azure AD Connect Server:

• Azure AD Connect must be installed on a domain joined server.
• The server must be Windows Server 2012 or later
  • 2016 or 2019 is suggested
• You cannot use Small Business Server or Windows Server Essentials before 2019. In other words 2019 editions of these 2 Windows Server flavours ARE supported.
• The server must have the full GUI installed, it cannot be a core install.
• We won’t be deploying AD FS (Active Directory Federation Services) as part of this so I’m going to exclude some important pieces about AD FS here, but visit the Microsoft Doc here to read about these if you do or will use AD FS in your own environment.
• If your Azure or Microsoft 365 global administrators use MFA then you will need to add a URL as a trusted site. You can add a trusted site via Internet Explorer. You’re prompted to add this site to the trusted sites list when you get your MFA challenge request and the site has not been added before. Site: https://secure.aadcdn.microsoftonline-p.com/

Security Considerations:

Microsoft recommends that the server be hardened to decrease the security attack surface for this critical piece of your infrastructure. The following recommendations are straight from our guiding light in Microsoft Docs for this important section:

• Treat Azure AD Connect the same as a domain controller and other Tier 0 resources. For more information, see Active Directory administrative tier model.
• Restrict administrative access to the Azure AD Connect server to only domain administrators or other tightly controlled security groups.
• Create a dedicated account for all personnel with privileged access. Administrators shouldn’t be browsing the web, checking their email, and doing day-to-day productivity tasks with highly privileged accounts.
• Follow the guidance provided in Securing privileged access.
• Deny use of NTLM authentication with the AADConnect server. Here are some ways to do this: Restricting NTLM on the AADConnect Server and Restricting NTLM on a domain
• Ensure every machine has a unique local administrator password. For more information, see Local Administrator Password Solution (LAPS) can configure unique random passwords on each workstation and server store them in Active Directory protected by an ACL. Only eligible authorized users can read or request the reset of these local administrator account passwords. You can obtain the LAPS for use on workstations and servers from the Microsoft Download Center. Additional guidance for operating an environment with LAPS and privileged access workstations (PAWs) can be found in Operational standards based on clean source principle.
• Implement dedicated privileged access workstations for all personnel with privileged access to your organization’s information systems.
• Follow these additional guidelines to reduce the attack surface of your Active Directory environment.

It is very important to secure your Azure AD Connect server properly and harden it using the Best Practices listed above. This will help to reduce your attack surface and allow your overworked security team to get some much needed sleep tonight! All joking aside, it is very important and unsecured servers are definitely a target and will likely be raised in your next security audit.

Account Considerations:

• You must have a Global Administrator account for the Azure AD tenant you want to integrate with.
• If you use Express Settings ( I know you won’t do that because you want a specific configuration!) you will need to have Enterprise Admin in your Windows Server Active Directory.
• If you use a custom configuration in Azure AD Connect, you can use a Windows Server Active Directory account with Domain Administrator rights.

Connectivity Considerations:

• The Azure AD Connect server will need to be able to resolve DNS for local and Internet connections.
• The server must be able to resolve and reach on-premises and Azure AD endpoints.
• Port Reference: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-ports
• Ports typically required are:

If you will be adding Pass-through Authentication and Seamless Single Sign-On, you will need to ensure the following ports are open:

These ports are the same as the base requirements for Azure AD Connect going from On-Premises to Azure cloud endpoints.

The Azure AD Connect health agent requires one additional port:

Summary

Now that you’ve got a handle on most of the requirements and we’ve highlighted many of the critical planning steps, you can map out your install and run that installer on a server to synchronize your Windows Server Active Directory into Azure Active Directory.

You can next install the PTA agent and the SSSO agent to provide a more positive user experience and reduce the logons required for your users.

In our example we took the requirements from the business and aligned the requirements and considerations for our configuration before installing. We also used the Microsoft Docs to guide us through the requirements and configurations needed to be successful in extending our on-premises identities to the Microsoft cloud.

In your Azure trial or Azure test environment you should now have at least 2 servers: one for your domain controller and one acting as your Azure AD Connect server. The AAD Connect server has 3 things installed on it: AAD Connect, Pass-through Authentication agent, and Seamless Single Sign-On agent. You can also log into any licensed resources using the identities you’ve extended out of your local domain into the Microsoft cloud! Well done!