Simplifying ADConnect Auth/Sync - On-Premises <-> Azure AD

In this post I will show you what is Azure AD Connect (AADC) and all the options to synchronize your on-premises environment to Azure Active Directory (AAD). This is very relevant because you need this configurations for Microsoft 365 (Office 365), so you can have all of your users, groups and/or devices synchronized in both directions. This is mandatory when we want to have objects with the same SID and same credentials in both environments. For instance, if one user reset or change his password in Azure AD, this new password is automatically synchronized to On-Premises Active Directory (Write-Back feature).

Azure AD Connect is required for all authentication/sync methods we will cover today:

• Password Hash Synchronization
• Pass-through Authentication (PTA)
• Active Directory Federation Services (2019)
• Additional Feature - Seamless Single Sign-On

Let's see the requirements and then all the authentication/sync methods functionalities in depth.

 So, what is Azure AD Connect?

• Application installed on a Windows machine (physical or virtual) within your environment;
• Integrates local Active Directory with Azure Active Directory;
• Sync engine based on Microsoft Identity Manager (shared codebase);
• Uses a local SQL server for sync database (can be a separate SQL server);
• Includes a monitoring component
• Azure AD Connect Health
• Very useful to troubleshoot errors, duplicated records and overall health
  
• Free for all Azure AD customers;
• Can manage ADFS installations.

 

Requirements

     

Azure AD

• You need an Azure AD tenant. You can get one with an Azure free trial;
• Add and verify the external domain you plan to use in Azure AD. For example, if you plan to use external.com for your users, make sure this domain has been verified and you're not using only the external.onmicrosoft.com default domain;
• An Azure AD tenant allows, by default, 50.000 objects. When you verify your domain the limit increases to 300.000 objects. If you need even more objects in Azure AD, open a support case to have the limit increased even further. If you need more than 500.000 objects, you need a license, such as Microsoft 365, Azure AD Premium or Enterprise Mobility + Security;
• You must have an Azure AD Global Administrator account for the Azure AD tenant you want to integrate with. This account must be a school or organization account and can't be a Microsoft account.
  

 

On-Premises Active Directory

• Use IdFix to identify errors such as duplicates and formatting problems in your directory before you synchronize to Azure AD and Microsoft 365;
• Download IDFix 
• https://support.office.com/article/Install-and-run-the-Office-365-IdFix-tool-f4bd2439-3e41-4169-99f6-3fabdfa326ac 
• The Active Directory schema version and forest functional level must be Windows Server 2003 or later. If you plan to use the feature password writeback, the domain controllers must be on Windows Server 2008 R2 or later;
• The domain controller used by Azure AD must be writable;
• Using on-premises forests or domains by using "dotted" (name contains a period ".") NetBIOS names isn't supported;
• Having a structured Active Directory is a must if you want to organize what to sync. So please, work on your AD before synchronize to Azure. Clean all the disabled users, create Organization Units for Computers and Users between departments, fill the department, office and all other attributes, because it will be very useful in office 365.
  

 

ADConnect Installation

• Azure AD Connect must be installed on a domain-joined Windows Server 2012 STD/ENT or later (not Business Server);
• Windows Core is not supported;
• Azure AD Connect requires a SQL Server database to store identity data. By default, a SQL Server 2012 Express LocalDB (a light version of SQL Server Express) is installed. SQL Server Express has a 10-GB size limit that enables you to manage approximately 100.000 objects;
• Download Azure ADConnect  
• https://www.microsoft.com/en-us/download/details.aspx?id=47594

 

Authentication and Synchronizations

The installation is very straightforward, so I'm going to jump to the scope of this post. The three options I'm talking about are in the User Sign-in area:

I made a table to demonstrate all the differences in options, advantages and disadvantages between all the authentication/sync methods:

How all the three mechanisms work?

Password Hash Synchronization

• Involves syncing hashed passwords to Azure AD;
• Relies on Azure AD Connect Passwords synced every 2 minutes;
• Authentication is completely cloud based;
• Locked out local accounts are not properly reflected in Azure Active Directory;
• Be careful with this option
  
• Disabled local accounts will not be disabled in Azure Active Directory until the next sync cycle (can be manually triggered but not a very good option);
• MD4 hashes are notoriously easy to crack, and MD5 is not much harder;
• Extra SHA-2 encryption makes the hash much harder to decrypt;
• Extra hashing technically makes this more secure than local AD credentials;
• Allows for leaked credential reports from MS if Azure Active Directory P1 licensing is in place;
• Remember, Microsoft does not get your passwords. They only receive a triple hashed password.

This is how the password hash synchronization between on-premises and Azure Active Directory works:

Pass-through Authentication (PTA)

• Relies on Azure AD Connect and PTA (AuthN) Agents:
• This agents can be installed in servers with 2012 R2 or later on-premises
  
• Agents can be installed on multiple servers for high availability
• First agent is on the Azure AD Connect server
• Additional agents can be deployed via script or manually
• Networking: only requires outbound communication on 80, 443, and 8080 (only for reporting status to Azure Active Directory) and no inbound ports to open;
• Basically if your firewall has ports TCP/80 and TCP/443 open to outside you don't need to do anything
  
• Locked and Disabled local accounts are respected;
• Supports alternate login IDs;
• Fully supports Azure AD conditional access
• Since sign in request are still process through Azure Active Directory (as opposed to redirected);
• Requires Modern Authentication
• Supports AAD Smart Lockout (prevents brute force attacks);
• Does not support leaked credential reports.
  

This is how the pass-through authentication between on-premises and Azure Active Directory works:

Active Directory Federation Services (2019)

• Requires Azure AD Connect for identity sync
• AD Connect can also help manage the ADFS farm
• Requires a minimum of 2 servers (1 Federation and 1 Proxy) but the recommended is a minimum of 4 servers (2 Federation and 2 Proxy for redundancy and load-balancing);
  
• Allows for sign in with more alternative methods (samAccountName, Certificate, Smart-Card, Windows Hello for Business, 3rd party MFA, etc…);
• Supports Extranet lockout & extranet smart lockout policies;
• Supports banned IP lists;
• Deep login screen customization and branding;
• Supports Windows Integrated Authentication;
• Limited support for Azure AD Conditional Access;
• Large investment of on-premises (or cloud Azure) infrastructure, including DMZ deployment
• You can have all of these servers in Azure
• https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/how-to-connect-fed-azure-adfs
  
• Requires valid third party certificate;
• Supports Alternate Login ID;
• Does not support Azure AD Identity protection unless password hash is enabled as a backup.

This is how the Federation Services works (simple diagram):

Additional Feature - Seamless Single Sign-On

• Provides single sign on capabilities to domain joined machines;
• Compatible with Password Hash Sync or Pass-Through Authentication;
• Requirements:
• OS: Windows 7+ or Mac OS X, domain joined (to local AD)
• Browsers: IE 10+, Chrome, Safari and Firefox
• Does not support Edge at this time (on roadmap)
  
• One URL needs to be added to Intranet Zone (via group policy);
• Ability to register non-Windows 10 devices with Azure AD;
• If Seamless SSO fails, sign-in experience falls back to regular behavior;
• Sign-out supported: Allows users to sign in with other credentials if desired;
• Requires Modern Authentication;
• Only works when devices are on the local network;
  
• Creates a computer account in the local AD named AZUREADSSOACC
• Kerberos decryption key of this account, if compromised, could be used to generate Kerberos tickets for any user in the forest
• As a security measure you can regenerate the key with a single powershell command with monthly schedule (the credentials are from on-premises):

$creds = Get-Credential
Update-AzureADSSOForest -OnPremCredentials $creds

These are the methods that exist (November 2020) to synchronize existing on-premises attributes to Azure and the types of authentications. I leave it up to you to choose depending on the environment you have and what type of security and functionalities you want. The takeaway is that you should carefully consider your authentication method based on your organization’s priorities and It’s not too late to change your method.

In general cases and if there is no criterion or in case of indecision, I would always recommend pass-through authentication. If you have any doubts, please let me know.

Thanks for reading!