Secure access to Office 365 with Active Directory Federation Service 2019

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:

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:

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 == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

Rule 2: Allow Exchange ActiveSync

@RuleName = "Allow Exchange ActiveSync"

c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"]

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

Rule 3: Allow extranet browser and browser dialog traffic

@RuleName = "Allow extranet browser and browser dialog traffic"

c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] &&

c2:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"]

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", 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 docs.microsoft.com 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

For more information about the different policy types and how to configure Azure Active Directory Identity Protection, visit the following docs.microsoft.com 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.

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.

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.