Once the decision to go on Azure is done, an important question is how to manage the Identity between on-premises and the Cloud, so Azure Active Directory.
There are different Identity Models available to deal with it.
Let’s take a little bit of time to present these models.
Identity Models
Cloud Identity
- Cloud Identity mode means that only Azure AD directory is available, there is no Active Directory Domain Services present.
- All accounts are stored and created on Azure AD
- Manual account creation
- Azure Portal (Azure, Intune, Office 365, etc…)
- PowerShell
- API
- CSV file import, for multiple account creation
Synchronized Identity
- Directory & Password synchronization mode means that a synchronization process was made to:
- Copy an account created On-Premise to Azure AD
- Synchronize password
- Easy Provisioning
- No manual action (Azure AD Connect)
Federated Identity
- Federated Identity mode means that a synchronization process was made and a Federation trust was made between Azure AD and On-Premise Active Directory Domain Services:
- Copy an account created On-Premise to Azure AD
- Synchronize password
- Easy Provisioning
- No manual action (Azure AD Connect)
- Federation between On-Premise AD DS and Azure AD
Once an Identity Model is chosen, it is necessary to choose which tools and solutions to implement.
Decision Tree
Microsoft has made a Decision Tree to help customer to select the right solution within customer context.
Now let’s go depth in each solution.
Azure AD Connect
Azure AD Connect Timeline
Azure AD Connect is an old and robust tool developed by Microsoft to synchronize identity between on-premises directory and cloud directory.
Azure AD Connect components
Azure AD Connect is made up of three primary components: the synchronization services, the optional Active Directory Federation Services component, and the monitoring component named Azure AD Connect Health.
Azure AD Connect Sync Process
Connector
The code modules that are used to communicate with a connected directory are called connectors (formerly known as management agents (MAs))
Attribute flow
Attribute flow is the process of copying or transforming data from one system to another and all attribute flows (inbound or outbound).
Attribute flow occurs between the connector space and the metaverse bi-directionally when synchronization (full or delta) operations are scheduled to run.
Connector space
Each connected data source is represented as a filtered subset of the objects and attributes in the connector space.
Metaverse
The metaverse is the consolidated view of all joined identities from neighboring connector spaces.
AD FS
Resume:
- SSO via on-premises AD credentials
- Seamlessly authenticate to AD FS when the client is attached to the corporate network
- Passwords remain on-premises
- On-premises authentication policies
- On-premises authentication methods (multi-factor)
- Conditional access via AD FS policies
- Require public certificates
- Authentification using certificates
- Certificates
- Smart cards
- Windows Hello
- Complex and expansive architecture
- Protection again on-premise account lockout
Password # Sync
Key Security Capabilities:
- Isolation of sign-in requests between tenants
- Standard ports (80 and 443) are used for outbound communication from the Authentication Agents to Azure AD
- Port 443 is used for all authenticated outbound communication
- Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the certificates used by this feature have been revoked
- High security encryption of password hashes
Resume:
- On-premises password complexity applies to synchronised users
- If an administrator changes the cloud password using PowerShell, the Azure AD password policy applies
- An expired/disabled on-premises account can still be active in the cloud
- The cloud password for a PHS user is set to never expire
- Synchronisation of a new password will have no impact on a user signed into Azure AD
- Password synchronisation can be used in addition to federation and used as a fall-back
Pass-Through Authentication
Big Picture
Key Security Capabilities:
- Isolation of sign-in requests between tenants
- On-premises passwords are never stored in the cloud in any form
- On-premises Authentication Agents that listen for, and respond to, password validation requests only make outbound connections from within your network. NO DMZ need
- Standard ports (80 and 443) are used for outbound communication from the Authentication Agents to Azure AD
- Port 443 is used for all authenticated outbound communication
- Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the certificates used by this feature have been revoked
- Passwords that users provide during sign-in are encrypted in the cloud before the on-premises Authentication Agents accept them for validation against Active Directory
- The HTTPS channel between Azure AD and the on-premises Authentication Agent is secured by using mutual authentication
- Integrates with Azure AD cloud-protection capabilities, such as conditional access policies (including Azure Multi-Factor Authentication), identity protection, and Smart Lockout
Pass-Through Authentication – Authentication Agent
- Getting an Authentication Agent working involves three main phases:
1.Authentication Agent installation
2.Authentication Agent registration
3.Authentication Agent initialization
- Authentication Agent uses 2 different services/applications:
- The Authentication Agent application itself:
- application runs with NetworkService privileges
- The Updater application that’s used to auto-update the Authentication Agent
- application runs with LocalSystem privileges
Authentication Agent registration
Authentication Agent initialization
Sign-In request
Security of Authentication Agents
Resume:
- No on-premises passwords/hashes in the cloud
- All on-premises password policies operational
- Password changes are immediately in effect
- Account expired/disabled operational
- Works with Conditional Access Policy
- No DMZ requirements
- Does not support on-premises MFA
- Works with Alternate ID
- Does not provide SSO for on-premises credentials
- Requires Seamless SSO in addition
- Requires high-availability for the company’s Internet connection
- Remote workers will not be able to authenticate to Azure AD If the link is down
Seamless SSO
Big Picture
Sign-in on a web browser
Sign-in on native client
Resume:
- Works with Password Hash Sync (P#S) or Pass-through Authentication (PTA)
- Users only need to type their name to authenticate to Azure AD
- It is possible for applications to pass a login_hint for seamless SSO
- Supports Windows 7 and above
- Windows 10 Edge not currently supported
- Machine must be domain joined and have access to a DC
- On corporate network or via remote access technology
- Authenticates to Azure AD with a Kerberos token
- Available with all versions of Azure AD
- Supports Alternate ID
- Support for multiple browsers and Oss
Comparison Matrix
Infrastructure & Operations
Authentication
MFA
Applications
Sign-In Experience
Password expiry notification and change
Devices & Access Control
To conclude, my recommendations
- If you are new customers:
- Use cloud authentication (P#S or PTA)
- Leverage conditional access and Azure AD MFA
- If AD FS is deployed to support on-premises applications, consider managing authentication for those apps via Azure AD
- Enable Seamless SSO if you’re using P#S or PTA
- Simple to deploy
- Immediately enhances the sign-in experience for your users
- Implement domain_hint
- If you are already in Federated Identity mode with AD FS
- Simplify Identity architecture and gain in server number
- Consider migration to PTA if with your AD FS you don’t use:
- On-premise MFA server (MS or third parties)
- Certificate Authentication
- Windows Hello