Azure AD Connect

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.

1. Topologies.

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:

Single forest - Single Azure AD Tenant

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 

Leave a Reply

Your email address will not be published. Required fields are marked *