Microsoft offers three different sign-in methods for your users to Office 365 applications:

  • Password-hash synchronization
  • Pass-through Authentication
  • Active Directory Federation Services, otherwise known as “AD FS”

The following diagram shows the difference between the available sign-in methods:

Sign in process for Active Directory Federation Services, Pass-through authentication and password hash synchronizaiton

Many large organizations, mostly enterprise-scale, already use AD FS for other on-premises or cloud applications. The underlying principles behind AD FS are the use of claims-based authentication and federated trusts. These establish a mechanism by which one environment, for example, your on-premises Active Directory can securely transmit a token of authentication to another environment, such as Microsoft Azure Active Directory.

You can expand your issuer’s capabilities to accept a security token from another issuer, instead of requiring the user to authenticate directly. Your issuer would issue security tokens and accept security tokens from other issuers that it trusts. This enables you to federate identity with other realms, which are separate security domains. In other words, a federation trust is the embodiment of a business-level agreement of partnership between two organizations.

The federated partner’s Identity Provider (IdP), i.e. Azure Active Directory and Active Directory Federation Services, sends claims that reflect its users’ identity, groups, and attribute data. Therefore, your organization no longer needs to revoke, change, or reset the credentials for the partner’s users, since the credentials are managed by the partner organization. You reconfigure one issuer, and many downstream applications become accessible to many new users. Additionally, if a partnership needs to be terminated, it can be performed with a single trust policy change, e.g. change, disable, or remove the trust policy. Without AD FS, individual accounts for each partner user would need to be deactivated.

Defending against Password Spray Attacks

One common way that online accounts are breached is password spray. The attackers try the most common passwords across many different accounts and services to gain access to any password-protected asset they can find. Usually, the span targets many different organizations and identity providers to enumerate all the users and then tries different passwords against all of all those accounts. A commonly available toolkit is Mailsniper. At Ignite 2018, Anand Yadav showed the common passwords in password spray attacks:

Password Spray Attacks Screenshot

Attackers know that there are some very common passwords out there. Even though the most common passwords account for only 0.5 – 1.0% of accounts, the attacker will get a few successes for every thousand accounts attacked, and that’s enough to be effective.

To avoid password spray attacks within your organization, a good approach is to disable legacy authentication from the extranet. You can disable basic authentication in Exchange Online, which is currently in preview. Basic authentication in Exchange Online accepts a username and password for client access requests, and blocking basic authentication can help protect your Exchange Online organization from brute force or password spray attacks.

Another way to block legacy authentication from the extranet is Conditional Access. For example, SharePoint Online and Exchange Online supports the legacy authentication protocol to access the service in Office 365.

Of course, you can configure issuance authorization rules to enable or block traffic at the AD FS level as well. For example, to block legacy traffic from the extranet you could configure three rules in the issuance authorization rules either in the AD FS management console or via Windows PowerShell:

Rule 1: Allow all intranet traffic
@RuleName = "Allow all intranet traffic"
c1:[Type == "", Value == "true"]
=> issue(Type = "", Value = "true");
Rule 2: Allow Exchange ActiveSync
@RuleName = "Allow Exchange ActiveSync"
c1:[Type == "", Value == "Microsoft.Exchange.ActiveSync"]
=> issue(Type = "", Value = "true");
Rule 3: Allow extranet browser and browser dialog traffic
@RuleName = "Allow extranet browser and browser dialog traffic"
c1:[Type == "", Value == "false"] &&
c2:[Type == "", Value =~ "(/adfs/ls)|(/adfs/oauth2)"]
=> issue(Type = "", Value = "true");

Legacy client apps from the extranet will be blocked at the AD FS level.

Active Directory Federation Services Smart Lockout

Smart Lockout enables AD FS to differentiate between sign-in attempts that look like they are from the valid user and sign-ins from what may be an attacker. As a result, AD FS can lock out attackers while letting valid users continue to use their accounts. It also protects against brute force password-guessing attacks. Extranet Soft Lockout was introduced in AD FS on Windows Server 2012 R2, Windows Server 2016 introduces Extranet Smart Lockout, and Windows Server 2019 provides additional advantages of Extranet Smart Lockout, like:

  • Set independent lockout thresholds for familiar and unfamiliar locations
  • Enable audit mode for smart lockout while continuing to enforce previous soft lockout behavior

Your infrastructure must meet some pre-requisites, depending on your AD FS version and Forest Functional Level. More details on the pre-requisites and how to configure different AD FS Smart Lockout features can be found in the article.

Multi-Factor Authentication (MFA)

From a security perspective, all your admin accounts should have MFA enabled. Security breaches of an Office 365 subscription, including information harvesting and phishing attacks, are typically done by compromising the credentials of an Office 365 global administrator account. Also, every user and admin access from the extranet should be secured with a second factor, like Azure MFA or other third-party solutions. For even more security, you can use Azure MFA to require multi-factor authentication for your users all the time, both in cloud authentication and AD FS. While this requires your users to always have an additional device, for example, a mobile phone, and perform multi-factor authentication more frequently, it provides the most security for your enterprise.

Since AD FS 2016, you have the ability to use Azure MFA as primary authentication for passwordless authentication, which means you don’t have to provide a username and password, for example from extranet connections. This is great to guard against password spray and password theft attacks. Additionally, you can use form-based authentication with username and password as the second factor only after your OTP (one time password) has been validated with Azure MFA. This method keeps your internal network “clean” from attackers because they first must provide the Azure MFA authentication prior to accessing your AD FS infrastructure.

Azure Active Directory Identity Protection

Identity Protection detects risk events involving identities in Azure Active Directory that indicate that the identities may have been compromised. This can be used with federated identities as well, but only Sign-in risk policy is included, User risk policy is currently not supported for federated domains. All of Identity Protection’s risk event types are covered for federated identities, which means you can see if botnet infections, TOR networks, or location anomalies are present in your federated sign-ins. Note that leaked credentials detection requires that you have enabled password hash sync in your federated tenant.

Azure Active Directory currently detects six types of risk events:

  • Users with leaked credentials
  • Sign-ins from anonymous IP addresses
  • Impossible travel to atypical locations
  • Sign-ins from infected devices
  • Sign-ins from IP addresses with suspicious activity
  • Sign-ins from unfamiliar locations
Secure access to Office 365 with Active Directory Federation Service 2019

For more information about the different policy types and how to configure Azure Active Directory Identity Protection, visit the following article.

Azure Active Directory Password Protection

Azure AD Password Protection (currently in public preview) enhances password policies in your organization, in the cloud and on-premises.

Microsoft uses a global banned password list, which means the Azure team continually look for commonly used and compromised passwords and block passwords that are deemed too common. Cyber-criminals also use similar strategies in their attacks, therefore Microsoft does not publish the contents of this list publicly.

Some organizations may want to take security one step further by adding their own customizations on top of the global banned password list, which is called custom banned list.

Secure access to Office 365 with Active Directory Federation Service 2019

It is also possible to install Azure AD password protection agents on-premises (currently in preview) to extend the banned password list to your existing infrastructure. Now users and administrators who change, set, or reset passwords on-premises are required to comply with the same password policy as cloud-only users.

Secure access to Office 365 with Active Directory Federation Service 2019

Microsoft provides a lot of different ways to secure your access to Office 365, even if you are using cloud-only or federated identities. This blog has covered some of the features offered by Microsoft to protect your organization from attackers for your federated identity hybrid cloud environment.

About the Author

Dominik Hoefling

Dominik Hoefling is currently a Principal Consultant at Intellity GmbH, where he works with large enterprise clients on designing and managing Microsoft 365 and Azure solutions. Dominik has been a Microsoft MVP for Office Apps & Services since the beginning of 2018, and he holds several Microsoft certifications including MCSA for Microsoft 365, MCSE Messaging and MCITP Enterprise Administrator for Windows Server.


  1. Mark


    I implemented ADFS 2016 with Azure MFA. Now when I enable it, I can only provide a username and than the OTP from the Authenticator App. I’ve got two questions:

    1. I want users to provide username and password first as the primary authentication method and after that, trigger MFA.
    2. I want to use the Push Notification instead of entering the OTP.

    Any ideas on how to configure this right?

    1. Dominik

      Hey Mark,

      You can read this post about AD FS 2019, the configuration for primary auth:

      Tou your second question: AFAIK only OTP is available with AD FS 2016, but I have to test it with 2016 first as the blog is for 2019. I found the following statement in the above link:
      “AD FS 2016 introduced Azure MFA as primary authentication so that OTP codes from the Authenticator App could be used as the first factor”


  2. Sumit

    I already have ADFS 2016 in place for authentication.

  3. Sumit

    I would like to use ADFS certificate based authentication for any user authenticating for Office 365 services. If user’s machine have certificate installed provided by our CA then user should be given direct access to the service without asking for credentials. How can i achieve this?

    1. Dominik

      You can use cert based authentication as primary auth method and sign in password-less.

      Please have a look at my conference slides which are available at my blog for further information:

  4. Kelvin Ng

    Do I need to have Azure Active Directory Premium P1 or EMS E3 license to use MFA?

    1. Dominik

      Yes, for Azure MFA P1 is needed. Or EMS E3 which includes P1.

  5. sankar


    please let us know whether it supported on ADSFS 2012

    1. Dominik

      Hi Sankar,

      I would highly recommend to upgrade your AD FS infrastructure. All identity protection features are available starting with AD FS 2016+ (except MFA, that can be used with 2012 as well).


  6. Israel


    I have implemented it and I didn’t have to do any change on my Ad Fs servers.

    Hope it helps,

  7. David

    I have implemented a federation with ADFS 2016 with Office 365, if I want to enable the office 365 MFA, do I need to make any changes to my ADFS settings for the office 365 MFA to work?
    Thank you,

    1. Dominik

      Hi David,

      it depends on either you want to enable MFA as primary or secondary authentication method. Azure MFA for secondary is automatically enabled.


Leave a Reply