Choose the right sign-in option to connect to Azure AD & Office 365

Howdy folks!

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

1. 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.
2. 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).
3. 3^rd party Federation Service: This is similar to the model for ADFS where a customer uses 3^rd party federation products or services to perform the sign-in. Examples of 3^rd party federation services are Ping Federate and Shibboleth. If the 3^rd 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.
4. Pass Through Authentication (PTA): 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 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 3^rd 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.

1. If you don’t have ADFS or an existing 3^rd 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. Of note, we recently (@Ignite 2017) announced that F5 can now fully replace the ADFS proxy capabilities for the DMZ. So, if you have an F5 device already, the difference between ADFS and PTA diminish significantly.
   • Use ADFS if you need specific capabilities that the prior options do not offer. See table below for more info.
2. 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. We recommend moving your applications over to Azure AD for additional security controls such as Identity protection based on risk, device based conditional access across web apps and native clients and provisioning support for specific SaaS apps. You can still enable P#S for your users that provide additional benefits such as leaked credential detection and as a fall back mechanism if your datacenter/ADFS goes down. You can then consider other options such as P#S or PTA based on your needs.
3. If you have a 3^rd 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.
4. If you have a 3^rd 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. If it's present do check with your vendor against the cases that I listed below.
5. If you have Azure AD premium licenses for all your active users in the cloud, you should seriously consider using PHS or PTA as you will have all the security capabilities available via Azure AD (e.g. Conditional Access). If not, I'd recommend you consider the options below, especially the ones called out as premium below to make an informed evaluation.

Simple isn’t it…Also, it is easy to change the sign-in options at a later time through Azure AD Connect (link). So, don't sweat it too much if you are making a choice initially and then change your mind later.

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.

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.

Notes

1. 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.
2. 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.
3. 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.
4. 3^rd party LDAP directory: Customers requiring to sign-in users from a 3^rd 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.
5. 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). It is also possible to use MDM to provision the certificates. For Hybrid Azure AD Joined devices (domain joined devices that are also registered with Azure AD), the ADFS option is recommended due to the more seamless and deterministic experience that is integrated with Windows logon.
6. Custom MFA:  Azure AD recently announced support for 3rd party MFA providers integrated with Conditional Access. This is currently in preview and supports RSA, Trusona & Duo. To learn more see this link.
7. 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.
8. 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.

What about 3rd party Identity Providers?

I've had a lot of folks ask me about 3rd party Identity providers (IDP). In general, these are the things that you should watch out for.

While Azure AD does support SAML protocol with the IDP, there are a few use cases that do not work with SAML IDP's and require the IDP to support WS-Trust.

• Acquisition of Primary Refresh Token (PRT, think of this like an internet compatible kerb TGT) when a user logs into an Azure AD Joined or a Hybrid Azure AD Joined device. This is because the Windows client uses WS-Trust to talk to the IDP and get a token for the user which is then used to translate to a PRT. Failure to PRT will manifest in the following issues.
  • Users fail to login into an Azure AD Joined device with a password
  • Users manage to login into a Hybrid Azure AD Joined device but do not get Single Sign On to applications
  • Users manage to login into a Hybrid Azure AD Joined device but fail to access applications protected with device based Conditional Access controls. This is because the PRT also contains the device information that is used to validate against a device based CA policy.
• Windows Hello For Business (Cert Trust) is only supported with ADFS for federated customers. This is because there is tight integration between the windows client to trigger and provision the WHFB Certificate for the users. ADFS (2016+) acts as registration authority for the TPM protected certificates and integrates with a customer's enterprise PKI system. Note that you may not need Cert Trust deployment of Windows Hello For business and can use the Key based deployment. For this, you will need to ensure that you have moved your domain controllers for user account forests up to Windows Server 2016 or higher. Additionally, you will need to ensure that you have an adequate solution that works using an alternate form of credentials.

There are other use cases that use WS-Trust. These cases tend to be optimizations and not necessarily blockers.

• Instant registration for Hybrid Azure AD Joined devices for federated customers: The client attempts to register the device post reboot on a domain joined device. If the customer is federated, it optimistically attempts to register the device as the computer account using WS-Trust kerberos endpoint. Subsequently, the sync mechanism (via AAD Connect) keeps this consistent with Azure AD. If the instant registration fails, it falls back to the sync mechanism registering in the cloud, but with a delay (typically 30 minutes). This fall back mechanism is only available if you are on Windows OS build 1803 or higher.  If you are considering Hybrid Azure AD Join with VDI sessions, I'd strongly recommend using an IDP that supports WS-Trust (like ADFS), other wise the delay will impact end user sessions.
• First time SSO to Office apps on domain joined machines: When Office apps run the first time on a domain joined machine (including Office Pro Plus activation), it checks for the local logged in UPN and attempts to use WS-Trust kerberos authentication to seamlessly sign-in the user with no user interaction. If this optimization fails, Office will prompt a dialog where the user will be asked to minimally enter their UPN on the Azure AD sign-in page so that Azure AD can then redirect to the appropriate IDP.
• Legacy Mail Authentication: All legacy mail clients (Outlook 2010 or lower) use HTTP basic authentication to Exchange Online (EXO). Here EXO proxies this back to the federated IDP via WS-Trust. This also includes any mobile clients that uses EAS protocol. The only exception is on latest versions of iOS where the EAS client uses modern authentication (with OAuth) to sign-in the user. Legacy authentication is generally considered a security risk as it exposes password authentication API's to the extranet. It is recommended to move all Office clients over to modern authentication patterns that provide better security.

Additionally, there are certain other use cases that you should evaluate your IDP for. These may be blockers for your organization depending on the use case. These are:

• 3rd party MFA support integrated with Azure AD Conditional Access: While specific vendors are available within Azure AD for MFA support via custom control in Conditional Access, your MFA provider may not be in the supported list or you may not have the necessary AAD Premium 2 licenses for this or your MFA provider is an on-premises only solution. In this case, you would want to have MFA integrated with your IDP. Integration with Azure AD Conditional Access is supported but your IDP needs to support the ability to respond to a protocol element that requests for MFA and issues additional assertion in the SAML token for AAD to accept it. Some additional notes about this.
  • The 'supportsMFA' flag MUST be set on the federated domain settings. This can be done via AAD PowerShell
  • The IDP must support triggering MFA when AAD sends a request to the IDP. For IDP's that use WS-Fed, it must support "wauth=https://schemas.microsoft.com/claims/multipleauthn". For IDP's that use SAML protocol, it MUST support when the uri "https://schemas.microsoft.com/claims/multipleauthn" is sent in the "<samlp:RequestedAuthnContext>" element as per SAML specification.
  • The IDP must issue the SAML token with the assertion of "https://schemas.microsoft.com/claims/multipleauthn". For WS-Fed, it needs to be added as an attribute assertion of type "https://schemas.microsoft.com/claims/authnmethodsreferences". For SAML protocol, it needs to be added as part of the "<saml:AuthnContext>" element in the SAML token.
  • NOTE: The SAML protocol exchange is not supported in AAD for production yet but is expected to be coming soon.

Summary

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.

Cheers,

Sam

Twitter: @MrADFS

Version History:  

• 1/16/2019: Added WHFB cert trust bullet for 3rd party IDP support
• 12/11/2018: Added section on 3rd party IDP support
• 3/15/2018: PTA support for EAS added. Also added a couple of coming soon for first time sign-in to Office apps on Windows.
• 12/18/2017: Added note on Azure SQL
• [Don't remember all the updates I've made as things changed]

Comments

• Anonymous
  June 15, 2017
  Nice Overview! Tip: The text in the table is hard to read with the table colors chosen.
  • Anonymous
    June 22, 2017
    Fixed. Diff between HTML5 and my out-dated CSS :)
• Anonymous
  June 20, 2017
  not sure what header you can put this under suspect adfs only and that azure app service use of active directory integrated authentication. Correct me if I'm wrong but even with the newest aad connect this is not supported, right? thanks
  • Anonymous
    June 22, 2017
    Which Azure App Service? Could you send URL? I'll look into it.
    • Anonymous
      July 02, 2017
      I'm confused about this statement "which app service?" basically I'm saying if developercreates an azure app service and you want to use ACTIVE DIRECTORY INTEGRATED authentication you must federate azure ad with ADFS, or does the newest aad connect circumvent this now, this would be awesome since I don't want to implement a full adfs solution for the app developers.thanks
      • Anonymous
        July 10, 2017
        Could you point a URL on where you are enabling "ACTIVE DIRECTORY INTEGRATED". Is it Visual Studio? If so, I need to follow up. In general, if you integrate with Azure AD, it shouldn't matter what option the customer or your organization has for the sign-in. All 3 options in the blog will be supported.
• Anonymous
  September 11, 2017
  Sam, thanks for the great overview.