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. 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.
  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 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.

  1. 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. 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 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.
  4. 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. 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.

Option P#S + DSSO agent PTA + DSSO agent ADFS
# of Servers 1

Rec: 2 (+'Staging' server)

Min: 1

Rec: 2 for HA

Min: 1

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


Partial Connect Health


AD - Password Sign-in YES YES YES
AD - Desktop SSO YES

(No EDGE support)


(NO EDGE support)

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 account in AD has been locked out NO YES YES
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

YES NO YES (2016)
Users in single AD forest to multiple AAD tenants NO NO YES
3rd party LDAP - Password sign-in

See note 4

NO NO YES (2016)


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 & Hardware token support) NO NO YES
Win10 Hello For Business (Key trust) YES YES YES (2016)
Win10 Hello For Business (Cert trust)

See note 5

YES (w/ Intune) YES (w/ Intune) YES
3rd party MFA

See note 6

Yes (Premium 2) Yes

(Premium 2)



Build Custom MFA NO NO YES


Exchange Active Sync (EAS) YES YES YES
Native apps (legacy auth) YES Coming Soon YES
Native apps (modern auth) YES YES

(except for Skype For Business)

Win 10 desktop sign-in with U/P on a AAD joined device YES YES YES
Azure SQL with AD Integrated Authentication NO NO YES
Customize logo, image and sign-in description YES (premium)


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 7

Seamless first time sign-in to O365 native apps on Domain Joined devices inside corp network (includes Office Pro Activation)

See note 8

Coming Soon Coming Soon YES
Seamless 2nd time sign-in to O365 native apps on Domain Joined devices YES YES YES
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
Device Registration: Win10 DJ YES YES YES
Device Registration: Win7/8.1 DJ Coming Soon YES YES
Block legacy protocols Public Preview (Premium) Public Preview (Premium) YES


Allow legacy protocols only from intranet (e.g. Office 2010) Coming Soon (Premium) Coming Soon (Premium) YES
Protect U/P logins against leaked credentials YES YES (requires p/w sync) YES (requires p/w sync)


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.


  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. 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.
  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.


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.




Twitter: @MrADFS

Version History: 

  • 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 (7)

  1. Nils says:

    Nice Overview!

    Tip: The text in the table is hard to read with the table colors chosen.

    1. Fixed. Diff between HTML5 and my out-dated CSS 🙂

  2. tony says:

    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?

    1. Which Azure App Service? Could you send URL? I’ll look into it.

      1. tony says:

        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.

        1. 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.

  3. Ivan says:

    Sam, thanks for the great overview.

Skip to main content