It's all about Identity, Authentication, and Authorization. But one of the most significant aspect of AAD Connect is the seamless access of both, On-Prem and Azure-Cloud resources and services. Using only one UserName/PassWord for all resources, regardless where they are located, helps to improve the end user experience and acceptance.
There are too many documentations for installing and configuring out there, so I don't want to go through those steps one more time. Instead, I would like to point out some considerations and design aspects prior to the installation.
The first thing you need to determine is your On-Prem AD-Topology and to select an appropriate Sync-Topology. Followings are the common supported scenarios:
Multi forest - Single Azure AD Tenant
- e.g. multiple forest, due to a company acquisition - All forests must be reachable by a single AAD Connect Sync-Server - All user objects must be represented only once in AAD - Each user has only one mailbox
Mutli forest (separate topology) - Single Azure AD Tenant
- No GALSync between the forests. - Each forest treated as a separate entities or they are operating independently.
Mutli forest (match users/full mash) - Single Azure AD Tenant
- Two-Way trust between forests. - Users and resources can be located in any forest. - User's identity across all forests via mail attribute.
Mutli forest - Multi Azure AD Tenant
- When an isolation between Azure AD tenant instances by design is required. - Users in one AAD instance don't see users in other instances.
Single Forest - Multi Azure AD Tenant
- Isolating domains or OUs for pointing to a separate ADD instance. - AAD SyncServers need to be configured for filtering. - Users must have separate UPN suffixes.
2. Sign-In Options.
Choosing an accurate authentication method is the next significant design point. It helps end users to sign in to both Azure Cloud, like Office 365, SaaS applications etc. , and On-Prem with the same credential. Depending on organization's infrastructure and requirements, following methods are available:
- Password Hash Synchronization with Seamless SSO - Pass-Through Authentication with Seamless SSO - Federated SSO with AD FS - Federation with PingFederate
2.1 Password Hash Sync
- Same password for On-Prem and Cloud resources - Recommended for all SaaS applications such as Office365 - Only Password hashes are synced and not the Password itself - Password write-back option allows end user to reset their password in AAD - Seamless SSO option works only on Domain-joined devices that are on the company's network.
2.2 Pass-Through authentication
- Users are authenticated against On-Prem Domain Controller - Password-hashes are not stored in AAD - Passwords getting validated in On-Prem AD - No port opening to the internet - Seamless SSO option works only on Domain-joined devices that are on the company's network.
2.3 Using new or existing farm with AD FS
- Users can sign into AAD by using their On-Prem credentials - Access to cloud based services without sign in for domain joined devices on corporate network - you can use existing 3. party Federation provider such as Okta