Azure AD connects organization of all sizes to Office 365 and other SaaS applications in a seamless and secure manner. A good deal of our customers synchronize their identities from an on-premises Active Directory. For these customers, signing in with their existing work credentials is the recommended and most common approach. In this case Azure AD provides multiple ways to sign-in to meet the broad needs of our customers. These are broadly classified as
- Password # Sync (P#S): With this option, password hashes (actually a derivative with ‘salt’) are synced to Azure AD allowing users to sign-in with the same password as they used with their on-premises Active Directory. Do note that the hashes stored in Active Directory cannot be used to login into your on-premises environment. This is the simplest option with the least infrastructure foot print. You can learn more about password hash synchronization here.
- Active Directory Federation Service (ADFS): Federating your sign-in with ADFS allows the sign-in to be delegated to an on-premises server that validates your credential and sends a security assertion back to Azure AD. In this model, Azure AD never sees any credential associated with their on-premises Active Directory. Additionally, ADFS provides desktop SSO for your corporate domain joined devices. You can learn more about ADFS here and integration with Azure AD Connect here. For those of you concerned with on-premises data center outages, we recommend that you keep a site available in Azure that you can swap your DNS to or also password # sync at the same time and use that if your on-premises data center goes down. ADFS is the #1 federation provider for Azure AD and accounts for nearly 45% of all Azure AD logins (as of May ’17).
- 3rd party Federation Service: This is similar to the model for ADFS where a customer uses 3rd party federation products or services to perform the sign-in. Examples of 3rd party federation services are Ping Federate and Shibboleth. If the 3rd party federation uses WS-* (recommended) to perform the sign-in the product and the version must be certified to be used. The certified list is available here. Protocol requirements for SAML protocol vendors connecting to Azure AD is listed here.
- Pass Through Authentication (PTA) [Preview]: PTA allows you to enter your credentials on the Azure AD sign-in page which is then tunneled securely to an on-premises connector to validate against your Active Directory. While the credential is entered on an Azure AD page, it is never stored or saved in any form. You can learn more about PTA here.
Additionally, Azure AD Seamless SSO [Preview] is a configuration step (no agent involved) via Azure AD Connect that can be combined with Password Sync or Pass Through Authentication. This allows you to seamlessly sign-in from your domain joined devices inside your network. You can learn more about this here.
As you can see there are quite a few choices. These choices offer our customers the flexibility to choose the right option based on simplicity, need and feature richness. This blog post focuses on providing sufficient details and clarity to help you make the right choice.
Ps: I will not be focusing on 3rd party Federation Service. If you are interested in that please check with your vendor.
A Few Simple rules…
Before we start analyzing all the bells and whistles of choosing the right option, here are a few simple rules to make a choice.
- If you don’t have ADFS or an existing 3rd party federation service..
- Use Password # Sync. It is the simplest option for customers and has the lowest infrastructure needs.
- If for some reason the policy in your organization does not allow Password # Sync and only needs desktop SSO for domain joined devices, strongly evaluate using PTA as an option. PTA does not require any deployment in the DMZ which simplifies the deployment infrastructure when compared with ADFS.
- Use ADFS if you need specific capabilities that the prior options do not offer. See table below for more info.
- If you already have ADFS for other applications, continue to use it. It is recommended not to split out your IDP’s where possible so that end users can have a consistent sign-in experience.
- If you have a 3rd party federation service and it only supports SAML-P, evaluate ADFS as there are # of use cases that do not work when the IDP only supports SAML-P. We’ve seen many customers go down this route as many use cases when connecting to Azure AD require WS-Trust. The most common ones are AAD SSO & Conditional Access from Win10 devices when logging in with U/P and EAS support. A common patterns employed by customers is to redirect all passive browser-based flows to the 3rd party IDP, but handle all active flows (WS-Trust) directly via ADFS. This provides a consistent sign-in experience.
- If you have a 3rd party federation service that supports WS-*, ensure that the product and version is part of the “Works with Azure AD” list. If this is not present, I would evaluate one of the existing MSFT options.
Simple isn’t it…Also, it is easy to change the sign-in options at a later time through Azure AD Connect (link).
However, a lot of you IT folks want to review the details while making this choice. So, let’s chat about some of the specifics across the options that Microsoft provides.
Comparing the Sign-in Options
For this exercise, I am always going to combine Azure AD Seamless SSO configuration with P#S and PTA. Also, if any capability requires Azure AD premium, I’ve tagged this as well.
|Option||P#S + DSSO agent||PTA + DSSO agent||ADFS|
|INFRASTRUCTURE & OPERATIONS|
|# of Servers||1
Rec: 2 (+’Staging’ server)
Rec: 2 for HA
Rec: 2 for HA
|Requires DMZ deployment for Extranet Access||NO||NO||YES
Min:1, Rec: 2 for HA
|Provides HA options with auto-failover
See note 1
|Requires SSL certificate||NO||NO||YES|
|SCOM support to monitor on-premises components||NO||NO||YES|
|Cloud Service to monitor on-premises components||Connect Health
|AD – Password Sign-in||YES||YES||YES|
|AD – Desktop SSO||YES||YES||YES|
|AD – Soft Certificates (MDM or GPO provisioned)
See note 2
|AD – Smart Card
See note 2
|AD – Fail Auth if user is disabled||Partial. Typically up to 30 mts for sync cycle to complete||Immediate||Immediate|
|AD – Fail Auth if user’s password has expired||NO||YES||YES|
|AD – Supports users in multiple trusted AD forests||YES||YES||YES|
|AD – Supports users in multiple untrusted AD forests
See note 3
|3rd party LDAP – Password sign-in
See note 4
|Authenticator App as primary Sign-in (password less)||NO||NO||YES (2016)
|Azure MFA (SMS, Phone, TOTP)||YES||YES||YES (2016)|
|Azure MFA Server (+Pin support)||NO||NO||YES|
|Win10 Hello For Business (Key trust)||YES||YES||YES (2016)|
|Win10 Hello For Business (Cert trust)
See note 5
|NO||NO||Coming Soon (2016)|
|3rd party MFA||NO||NO||YES
|Build Custom MFA||NO||NO||YES
|Exchange Active Sync (EAS)||YES||Coming Soon||YES|
|Native apps (legacy auth)||YES||Coming Soon||YES|
|Native apps (modern auth)||YES||YES||YES|
|Win 10 desktop sign-in with U/P on a AAD joined device||YES||Coming Soon||YES|
|Customize logo, image and sign-in description||YES (premium)
|Customize full layout with CSS customization||NO||NO||YES
|Customize dynamically with Java Script||NO||NO||YES
|Sign In with UPN||YES||YES||YES|
|Sign In with Domain\samaccountname
See note 6
|Seamless first time sign-in to O365 native apps on Domain Joined devices
See note 7
|Seamless 2nd time sign-in to O365 native apps on Domain Joined devices||YES||YES||YES|
|PASSWORD EXPIRY NOTIFICATION & CHANGE|
|Supports password expiry notification in Office Portal & Win10 desktop||NO||NO||YES|
|Custom password change URL link shown in Office Portal & Win10 desktop||NO||NO||YES|
|Integrated password change experience when user’s password has expired||NO||NO||YES|
|DEVICES & ACCESS CONTROL|
|Device Registration: Win10 DJ||YES||YES||YES|
|Device Registration: Win7/8.1 DJ||Coming Soon||YES||YES|
|Block legacy protocols||Coming Soon (Premium)||Coming Soon (Premium)||YES
|Allow legacy protocols only from intranet (e.g. Office 2010)||Coming Soon (Premium)||Coming Soon (Premium)||YES|
Additionally, if you are building claims aware LOB apps that require all communication & data to be inside your on-premises network, you would swing towards the ADFS side.
- HA with auto-failover: In the case of PTA, this is automatically done by the cloud service. In the case of ADFS, the load balancer can be configured to send requests only to ‘healthy’ nodes. With password # sync, you will have to manually elevate the staging Azure AD Connect server to become active if the current server goes down.
- Certificate sign-in: ADFS can integrate with your enterprise PKI to allow sign-in using certificates. These certificates can be soft-certificates deployed via trusted provisioning channels such as MDM or GPO or smartcard certificates (including PIV/CAC cards) or Hello for Business (cert-trust). See this blog for more information.
- Users in multiple untrusted AD forests: With ADFS in 2016, an untrusted forest can be configured as an LDAP directory that allows you to sign-in those users from a single ADFS setup. To learn more about LDAP directory setup with ADFS, see this link.
- 3rd party LDAP directory: Customers requiring to sign-in users from a 3rd party LDAP directory to access Azure AD apps (and Office 365) can now use a new feature in ADFS 2016 to sign these users in. To learn more about this feature and configure it, see this link.
- Win10 Hello For Business (Cert Trust): For customers looking to deploy Hello For Business as part of their Win10 deployment, this option is only relevant if you need the TPM protected credentials to be used with down-level domain controllers (<2016 DC’s) or with VPNs that only support certificates. Otherwise, the key trust model can be used. Also, in this option, ADFS 2016 also becomes the provisioning endpoint for the TPM protected certificates and makes the provisioning simpler with auto-renewal & instant PIN use (coming soon).
- Sign-in with domain\samaccountname: While ADFS supports this and can be used in multiple use cases, we recommend customers to move to signing in with a UPN suffix. Also, it is possible in ADFS in a single UPN suffix scenario to customize the Java Script in the sign-in pages to only require the samaccountname.
- Office first time login on DJ devices: Office apps are optimized on first sign-in to look up the local UPN and seamlessly sign-in the user using WS-Trust Kerberos endpoints from the Identity provider. If this is not available, Office throws up a dialog where the user must enter their UPN in the Azure AD home realm discovery page which then redirects to the IDP and can support desktop SSO. This capability is likely needed if you are planning on exposing Office apps through a Virtual Desktop Solution that is not using persistent sessions. In this case, each login is treated like a first time login.
Password Sync is the simplest option. If that doesn’t work for you go with evaluating what requirements you need and use the table above to decide the best choice between PTA & ADFS.
If there is any additional clarification that you require or you believe there are additional differentiators, please tweet me at @MrADFS and I will take a look and respond. I will also keep the table up to date every quarter as we add more capabilities in these options.