Modern Authentication Office 365

Modern authentication is an umbrella term for a combination of authentication and authorization methods between a client (for example, your laptop or your phone) and a server, as well as some security measures that rely on access policies that you may already be familiar with. It includes:

• Authentication methods: Multi-factor authentication (MFA); smart card authentication; client certificate-based authentication
• Authorization methods: Microsoft’s implementation of Open Authorization (OAuth)
• Conditional access policies: Mobile Application Management (MAM) and Azure Active Directory (Azure AD) Conditional Access

Source: https://docs.microsoft.com/en-us/microsoft-365/enterprise/hybrid-modern-auth-overview

Introduction

Very simplistic we can say, that with modern authentication, the client is talking to the service and getting redirected to Azure AD for authentication with the username and password or other methods like MFA.

After successfully authenticated, the client is getting back a security token (Access Token and a Refresh Token) from Azure AD, which he can then use for authentication against the services he wants to access. So authentication against Azure AD occurs only once and from there the client will using the security tokens.

With legacy authentication (typically Basic Authentication), the client is talking to the service and the service will proxy the request to Azure AD. Then Azure AD will send the response back to the service which on his part will authorize the client.

For a great explanation about generally understanding Tokens in Azure AD, you can watch the following YouTube video from John Savill who posts many great videos about Azure:

Azure AD Understanding Tokens
https://www.youtube.com/watch?v=R5pXessyfIk

A great post about modern authentication vs. basic authentication from Dominick Ciacciarelli you will find here.

Modern Authentication vs. Basic Authentication
https://www.kraftkennedy.com/modern-authentication-vs-basic-authentication/

Legacy Authentication
For years, Windows (and other systems) have relied on protocols like CHAP, NTLM, and Kerberos, which don’t work particularly well over the internet. Authentication for internet resources would typically use Basic Authentication, which has the benefit of being very simple. Username and password were contained in a single header field, in plain text, base64 encoding. For this reason, Basic Auth needed to be combined with SSL to encrypt the headers.

Modern Authentication
Modern Authentication is not a single authentication method, but instead a category of several different protocols that aim to enhance the security posture of cloud-based resources. Some examples of Modern Authentication protocols are SAML, WS-Federation, and OAuth. While each are different in their execution, they all aim to move away from the classic usernamepassword method and instead rely on token-based claims. So, while the user may still provide a username and password (for now; see more below), it is used to authenticate with an identity provider to generate a token for access. This token has more specific information (in the form of a claim) that specifies what the requestor does and does not have access to.

Hybrid modern authentication overview and prerequisites for using it with on-premises Skype for Business and Exchange servers

As of August of 2017, all new Office 365 tenants that include Skype for Business online and Exchange online will have modern authentication enabled by default. Pre-existing tenants won’t have a change in their default MA state, but all new tenants automatically support the expanded set of identity features you see listed above. To check your MA status, see the Check the modern authentication status of your on-premises environment section.

Source: https://docs.microsoft.com/en-us/microsoft-365/enterprise/hybrid-modern-auth-overview

What changes when I use modern authentication?

When using modern authentication with on-premises Skype for Business or Exchange server, you’re still authenticating users on-premises, but the story of authorizing their access to resources (like files or emails) changes. This is why, though modern authentication is about client and server communication, the steps taken during configuring MA result in evoSTS (a Security Token Service used by Azure AD) being set as Auth Server for Skype for Business and Exchange server on-premises.

The change to evoSTS allows your on-premises servers to take advantage of OAuth (token issuance) for authorizing your clients, and also lets your on-premises use security methods common in the cloud (like Multi-factor Authentication). Additionally, the evoSTS issues tokens that allow users to request access to resources without supplying their password as part of the request. No matter where your users are homed (of online or on-premises), and no matter which location hosts the needed resource, EvoSTS will become the core of authorizing users and clients once modern authentication is configured.

What doesn’t change? Whether you’re in a split-domain hybrid or using Skype for Business and Exchange server on-premises, all users must first authenticate on-premises. In a hybrid implementation of modern authentication, Lyncdiscovery and Autodiscovery both point to your on-premises server.

All the scenarios for on-premises servers involve setting up modern authentication on-premises (in fact, for Skype for Business there is a list of supported topologies) so that the server responsible for authentication and authorization is in the Microsoft Cloud (Azure AD’s security token service, called ‘evoSTS’), and updating Azure AD about the URLs or namespaces used by your on-premises installation of either Skype for Business or Exchange. Therefore, on-premises servers take on a Microsoft Cloud dependency. Taking this action could be considered configuring hybrid auth.

Check the modern authentication status of your on-premises environment

Because modern authentication changes the authorization server used when services leverage OAuth/S2S, you need to know if modern authentication is enabled or disabled for your on-premises Skype for Business and Exchange environments. You can check the status on your Exchange servers by running the following PowerShell command:

Get-OrganizationConfig | ft OAuth*

If the value of the OAuth2ClientProfileEnabled property is False, then modern authentication is disabled.

For more information about the Get-OrganizationConfig cmdlet, see Get-OrganizationConfig.

You can check your Skype for Business servers by running the following PowerShell command:

Get-CSOAuthConfiguration

If the command returns an empty OAuthServers property, or if the value of the ClientADALAuthOverride property is not Allowed, then modern authentication is disabled.

For more information about the Get-CsOAuthConfiguration cmdlet, see Get-CsOAuthConfiguration.

Source: https://docs.microsoft.com/en-us/microsoft-365/enterprise/hybrid-modern-auth-overview

Check the modern authentication status of your Office 365 Tenant

To check Exchange Online

Import-Module ExchangeOnlineManagement
$credential = Get-Credential
Connect-ExchangeOnline -Credential $credential -ShowProgress $true

Get-OrganizationConfig | ft OAuth*

If the value of the OAuth2ClientProfileEnabled property is False, then modern authentication is disabled.

To check Skype for Business Online/Teams

Import-Module MicrosoftTeams
$credential = Get-Credential
$sfboSession = New-CsOnlineSession -Credential $credential
Import-PSSession $sfboSession

Get-CSOAuthConfiguration

If the command returns an empty OAuthServers property, or if the value of the ClientADALAuthOverride property is not Allowed, then modern authentication is disabled.


# Note !!!
Skype for Business Online Connector connections will be rejected starting May 17, 2021. Please contact Microsoft Support for help and support for migrating to Teams PowerShell Module.

Skype for Business Online Connector is currently part of the latest Teams PowerShell module. If you’re using the latest Teams PowerShell public release, you don’t need to install the Skype for Business Online Connector.

When using Teams PowerShell Module 2.0 or later, update your scripts that refers New-CsOnlineSession to Connect-MicrosoftTeams.

Import-PsSession is no longer required to establish a Skype for Business Online Remote PowerShell Session as that is done implicit when using Connect-MicrosoftTeams.

Import-Module MicrosoftTeams
$credential = Get-Credential
Connect-MicrosoftTeams -Credential $credential

Get-CSOAuthConfiguration


# Disconnect from the Microsoft Teams environment.
Disconnect-MicrosoftTeams

How to check if Outlook is using modern authentication for Office 365

Click on the Outlook system tray icon (STRG + right click) and choose from the context menu Connection status …

User connected to Exchange Online mailbox

Authn: Bearer* signifies that Modern Authentication is used for the Outlook client

The OAuth 2.0 Authorization Protocol: Bearer Tokens
https://tools.ietf.org/id/draft-ietf-oauth-v2-bearer-13.xml

Description of the Connection Status dialog in Outlook
https://docs.microsoft.com/en-us/outlook/troubleshoot/connectivity/description-of-the-connection-status-dialog-box

Authn
Indicates the authentication type that a given Outlook connection uses. Possible values include:

• ERROR
• CLEAR (Outlook uses clear to indicate basic authentication – typically used together with SSL)
• NTLM
• NEGO
• KERBEROS
• ANONYMOUS
• BEARER

User connected to on-premise mailbox Exchange Server 2019
Authn: Nego*

Identify legacy authentication use

Azure AD sign-in logs can be used to understand if you’re using legacy authentication.

1. Navigate to the Azure portal > Azure Active Directory > Sign-ins.
2. Add the Client App column if it is not shown by clicking on Columns > Client App.
3. Add filters > Client App > select all of the legacy authentication protocols. Select outside the filtering dialog box to apply your selections and close the dialog box.
4. If you have activated the new sign-in activity reports preview, repeat the above steps also on the User sign-ins (non-interactive) tab.

Filtering will only show you sign-in attempts that were made by legacy authentication protocols. Clicking on each individual sign-in attempt will show you more details. The Client App field under the Basic Info tab will indicate which legacy authentication protocol was used.

These logs will indicate which users are still depending on legacy authentication and which applications are using legacy protocols to make authentication requests. For users that do not appear in these logs and are confirmed to not be using legacy authentication, implement a Conditional Access policy for these users only.

Change modern authentication settings in Office 365

Microsoft 365 admin center -> Settings -> Org settings -> Services

You can also check the Authentication Policies through the Exchange Online PowerShell module.

Import-Module ExchangeOnlineManagement
$credential = Get-Credential
Connect-ExchangeOnline -Credential $credential -ShowProgress $true

Get-AuthenticationPolicy

In case you change the settings above, it can take a while in Office 365 to synchronize them and therefore kick in. You can enforce the new Authentication Policies by setting his actual using Token to expired with the following command in Exchange Online PowerShell Module.

Set-User -identity jdoe -StsRefreshTokensValidFrom $([System.DateTime]::UtcNow)

# For all user mailboxes you can run
$Mailboxes= (Get-User).UserPrincipalName
foreach ($mailbox in $Mailboxes) {Set-User -Identity $mailbox -StsRefreshTokensValidFrom $([System.DateTime]::UtcNow)}

What are security defaults?
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-default

In case you have enabled a custom Conditional Access policy, you can’t enable Security defaults and have to configure custom policies with Conditional Access.

How to: Block legacy authentication to Azure AD with Conditional Access
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication

How can you prevent apps using legacy authentication from accessing your tenant’s resources? The recommendation is to just block them with a Conditional Access policy. If necessary, you allow only certain users and specific network locations to use apps that are based on legacy authentication.

Conditional Access policies are enforced after the first-factor authentication has been completed. Therefore, Conditional Access is not intended as a first line defense for scenarios like denial-of-service (DoS) attacks, but can utilize signals from these events (for example, the sign-in risk level, location of the request, and so on) to determine access.

There are two ways to use Conditional Access policies to block legacy authentication.

• Directly blocking legacy authentication
• Indirectly blocking legacy authentication

You will find Conditional Access in the Azure portal under Azure Active Directory -> Security -> Conditional Access

As you can see, for my lab environment I have configured a custom Conditional Access policy, which allows only users with IPs located in Germany access.

What is Conditional Access?

The modern security perimeter now extends beyond an organization’s network to include user and device identity. Organizations can utilize these identity signals as part of their access control decisions.

Conditional Access is the tool used by Azure Active Directory to bring signals together, to make decisions, and enforce organizational policies. Conditional Access is at the heart of the new identity driven control plane.

Source: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

Who should use Conditional Access?

• If you are an organization currently using Conditional Access policies to bring signals together, to make decisions, and enforce organizational policies, security defaults are probably not right for you.
• If you are an organization with Azure Active Directory Premium licenses, security defaults are probably not right for you.
• If your organization has complex security requirements, you should consider Conditional Access.

Disable Basic authentication in Exchange Online

Basic authentication in Exchange Online uses a username and a password for client access requests. Blocking Basic authentication can help protect your Exchange Online organization from brute force or password spray attacks. When you disable Basic authentication for users in Exchange Online, their email clients and apps must support modern authentication. Those clients are:

• Outlook 2013 or later (Outlook 2013 requires a registry key change. See Enable Modern Authentication for Office 2013 on Windows devices for more information.)
• Outlook 2016 for Mac or later
• Outlook for iOS and Android
• Mail for iOS 11.3.1 or later

If your organization has no legacy email clients, you can use authentication policies in Exchange Online to disable Basic authentication requests, which forces all client access requests to use modern authentication. For more information about modern authentication, see Using modern authentication with Office clients.

How Basic authentication works in Exchange Online

Basic authentication is also known as proxy authentication because the email client transmits the username and password to Exchange Online, and Exchange Online forwards or proxies the credentials to an authoritative identity provider (IdP) on behalf of the email client or app. The IdP depends your organization’s authentication model:

• Cloud authentication: The IdP is Azure Active Directory.
• Federated authentication: The IdP is an on-premises solution like Active Directory Federation Services (AD FS).

Source: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online

Authentication methods for Azure Active Directory hybrid identity solutions

Azure AD supports the following authentication methods for hybrid identity solutions.

Cloud authentication

When you choose this authentication method, Azure AD handles users’ sign-in process. Coupled with seamless single sign-on (SSO), users can sign in to cloud apps without having to reenter their credentials. With cloud authentication, you can choose from two options:

• Azure AD password hash synchronization. The simplest way to enable authentication for on-premises directory objects in Azure AD. Users can use the same username and password that they use on-premises without having to deploy any additional infrastructure. Some premium features of Azure AD, like Identity Protection and Azure AD Domain Services, require password hash synchronization, no matter which authentication method you choose.
  
  Passwords are never stored in clear text or encrypted with a reversible algorithm in Azure AD.
  
• Azure AD Pass-through Authentication. Provides a simple password validation for Azure AD authentication services by using a software agent that runs on one or more on-premises servers. The servers validate the users directly with your on-premises Active Directory, which ensures that the password validation doesn’t happen in the cloud.
  
  Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours might use this authentication method. For more information on the actual pass-through authentication process, see User sign-in with Azure AD pass-through authentication.

Federated authentication

When you choose this authentication method, Azure AD hands off the authentication process to a separate trusted authentication system, such as on-premises Active Directory Federation Services (AD FS), to validate the user’s password.

The authentication system can provide additional advanced authentication requirements. Examples are smartcard-based authentication or third-party multifactor authentication. For more information, see Deploying Active Directory Federation Services.

Source: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn

You can configure these authentication methods through the Azure AD Connect tool.

What is Azure Active Directory Pass-through Authentication?

When users sign in using Azure AD, this feature validates users’ passwords directly against your on-premises Active Directory.

This feature is an alternative to Azure AD Password Hash Synchronization, which provides the same benefit of cloud authentication to organizations. However, certain organizations wanting to enforce their on-premises Active Directory security and password policies, can choose to use Pass-through Authentication instead. Review this guide for a comparison of the various Azure AD sign-in methods and how to choose the right sign-in method for your organization.

You can combine Pass-through Authentication with the Seamless Single Sign-On feature. This way, when your users are accessing applications on their corporate machines inside your corporate network, they don’t need to type in their passwords to sign in.

Source: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta

Office 365 Legacy Authentication End of Life

Basic Authentication and Exchange Online – February 2021 Update
https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-february-2021-update/ba-p/2111904

We previously announced we would begin to disable Basic Auth for five Exchange Online protocols in the second half of 2021. Due to the pandemic and the effect it has on priorities and work patterns, we are announcing some important changes to our plan to disable Basic Auth in Exchange Online. Please read this post carefully, as there’s a lot of detail.

The first change is that until further notice, we will not be disabling Basic Auth for any protocols that your tenant is using. When we resume this program, we will provide a minimum of twelve months notice before we block the use of Basic Auth on any protocol being used in your tenant.

We will continue with our plan to disable Basic Auth for protocols that your tenant is not using. Many customers don’t know that unneeded legacy protocols remain enabled in their tenant (Security Defaults takes care of this for newly created tenants now). We plan to disable Basic Auth for these unused protocols to prevent potential mis-use. We will do this based on examining recorded usage of these protocols by your tenant, and we will send Message Center posts providing 30 days notice of the change to your tenant. This work will begin in a few months.

The next change to the previously announced plan is that we are adding MAPI, RPC, and Offline Address Book (OAB) to the protocols included in this effort to further enhance data protection.

As clarified in previous blogs, Outlook depends upon Exchange Web Services (EWS) for core features; therefore, tenants using Basic Auth with Outlook must enable Modern Auth before Basic Auth for EWS is disabled. Outlook uses only one type of authentication for all connections to a mailbox, so including these protocols should not adversely affect you. If EWS has Basic Auth disabled, Outlook won’t use Basic Auth for any of the other protocols or endpoints it needs to access.

At this time, we are not including AutoDiscover, another protocol and endpoint used by Outlook. There are two reasons for this. First, AutoDiscover doesn’t provide access to user data; it only provides a pointer to the endpoint that the client should use to access data. Second, as long as a tenant has some EWS or Exchange ActiveSync (EAS) usage, AutoDiscover is necessary for client configuration. Once Basic Auth is disabled for the vast majority of tenants, we’ll consider disabling Basic Auth for AutoDiscover.

Finally, we are aligning our plans with those for SMTP AUTH. We had previously announced that we would begin to disable SMTP AUTH for newly created tenants (and have already done so), and that we would expand this to disable SMTP AUTH for tenants who do not use it. We are continuing to do that, but we will include SMTP AUTH in all future communications and Message Center posts to make it easier for you to track the overall plan.

In summary, we have postponed disabling Basic Auth for protocols in active use by your tenant until further notice, but we will continue to disable Basic Auth for any protocols you are not currently using. The overall scope of this change now covers EWS, EAS, POP, IMAP, Remote PowerShell, MAPI, RPC, SMTP AUTH and OAB.

More about modern authentication you will also find in my following posts.

Links

What is modern authentication?
https://docs.microsoft.com/en-us/microsoft-365/enterprise/hybrid-modern-auth-overview?view=o365-worldwide#what-is-modern-authentication

What authentication and verification methods are available in Azure Active Directory?
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods

Modern Authentication vs. Basic Authentication
https://www.kraftkennedy.com/modern-authentication-vs-basic-authentication/

How to: Block legacy authentication to Azure AD with Conditional Access
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication

Switching off legacy authentication for Exchange Online
https://practical365.com/switching-off-legacy-authentication-for-exchange-online/

Account setup with modern authentication in Exchange Online
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/setup-with-modern-authentication

The OAuth 2.0 Authorization Protocol: Bearer Tokens
https://tools.ietf.org/id/draft-ietf-oauth-v2-bearer-13.xml