This topics cover the Authentication and Authorization option in Microsoft 365.
What is a Basic Authentication and Modern Authentication client?
Basic Authentication Clients: Clients or applications that is not a browser-based client that access Office 365 services are Basic authentication clients. Outlook 2013 by default is a basic authentication client and few other clients like EWS clients and EAS clients are Basic authentication clients.
Modern Authentication Clients (OAuth): Modern Authentication uses Active Directory Authentication Library (ADAL) based sign-in for Office clients. ADAL based sign-in supports features like MFA, certificate based authentication and smart card authentication. Outlook 2016 by default is a modern authentication office client, where Outlook 2013 requires an Office update and registry settings modified to act like a Modern Authentication client.
When you try to access an Office 365 service, it will open a web browser and prompts to authenticate which will accept the credential as well as Multi factor authentication if enabled. Basic clients will not support this option and if MFA enabled, basic authentication supported clients cannot prompt the user for MFA authentication and those clients cannot access the service.
What is Authentication and Authorization?
Authentication is the act of challenging the client for valid credential when you are accessing a resource. It is the process of proving who you are by providing your credential. AuthN
Authorization is the act of granting access to authenticated client to do something on the accessed resource. It defines what sort of data that you get access and what you can do with it. AuthZ
Azure AD is the Office 365 Identity service which takes care of Authentication and Authorization. Azure AD using Authentication protocol like OAuth 2.0 and OpenID connect.
What is OAuth 2.0 and what is the use of it?
OAuth 2.0 is an authentication protocol used by Azure AD and it provides 2 tokens (Access and Refresh tokens) to the client when it successfully authenticates against Azure Active Directory. Access token is a JSON Web Token (JWT), which is valid for 1 hour and a Refresh token valid for 14 days, if it is continuously accessed it will be valid for 90 days.
If we run the Hybrid configuration wizard on a Pure Exchange 2013 and above environment, it enables OAuth.
Explain the Authentication flow for Basic authentication client? Important
Basic Authentication Flow: User access Office 365 service like EXO using a basic client and it prompts the user to enter the credential -> EXO sends the credential to Azure AD using proxy authentication -> Azure AD authentication endpoint find the authentication provider as STS in On-Premise for these kinds of basic auth requests and notify EXO to reach STS and the request will be sent to ADFS Proxy by EXO (Exchange Online) -> ADFS Proxy server proxies the EXO authentication request to ADFS -> ADFS validates the credentials with AD and on successful authentication, AD will provide a logon token and user related information as claim to ADFS -> ADFS sends the information to EXO -> EXO send the logon token received from ADFS to Azure AD and it will authenticated in Azure AD and EXO will be provide an access token by Azure AD which will allow the user to access the service.
Explain the Authentication flow for Modern authentication client? Important
Modern Authentication Flow: User access Office 365 service like EXO using a modern authentication client -> EXO redirects the client to authenticate with Azure AD -> Client will reach Azure AD and the it will prompt for user name and the Azure AD authentication end point deduct the UPN of the domain is federated and redirect the client to STS -> ADFS will ask the client to authenticate (If client is internal to network, it will take Windows Integrated Authentication to authenticate with AD) -> Once authentication successful in AD, it will send user claims to ADFS -> ADFS will send the SAML token along with user claims to Client -> Outlook sends the token to Azure AD and validates the token received from AD and the authentication will be successful -> On successful Authentication, Azure AD will provide an access token and refresh token to Client -> Client will send the access token to EXO and user will be allowed to access the service.
What are the authentication options available for Office 365 / Azure AD?
Below are the authentication or Sign-In options available for Office 365 / Azure AD.
- Federation Authentication
- Password Hash Synchronization Authentication
- Pass-through Authentication
- Seamless SSO (enabled when choosing PHS or PTA)
This Content Is Only For Subscribers
Explain how the federated authentication option works?
Most of the Companies preferred to use federated authentication. When the federation sign in option enabled, the domain used for authentication will be configured as federated domain in Azure AD. Below shows the authentication flow for federation sign-in
How it works
To explain the Federation Sign-in flow, when you access any claims aware application that trusts Azure AD as the STS, the application will redirect you to authenticate with Azure AD, Azure AD prompts you to login with the user name option only and when you enter the user name, the domain validated whether it is a federated domain. Since it is a federated domain, you are redirected to On-Premise ADFS infrastructure, (to WAP server if you are in Internet and to ADFS server if you sign-in from Intranet). ADFS prompts you to enter the user name and password passed and it authenticates with Active Directory. On successful authentication with AD, ADFS send a Security token to User that will be send back to Azure AD for successful authentication.
Note: You need to maintain a ADFS infrastructure to have this federation sign-in option and it is having additional benefits like you use On-Premise MFA server for multifactor authentication.
What is Password Hash Synchronization Authentication? And how it works?
No need to confuse about the Password Synchronization option, we are not directly synchronizing the password from On-Premise to Azure AD. Only the Hash of the Password hash synchronized with Azure AD using Azure AD connect.
How it works
When Password Hash Synchronization authentication enabled for the tenant, Hash of the password hash is available in Azure AD after Synchronization. If a user access a Azure Integrated application, user redirected to authenticate with Azure AD, Azure AD prompt the user to enter the credential, both user name and the password will be entered in Azure AD authentication dialogue window and it will be validated against the hash Synced in Azure.
If successful, user will be provided security toke to the authenticative the service\application. Switching from one application to other, prompts the user to validate the credential when this sign-in option used.
Explain Pass-through Authentication? And how it works:
If we use the Pass-through authentication, user name the password will be gathered in Azure AD but Passwords validated in On-Premise AD. AuthN Agent configured in AD Connect or any member server supports this Pass through Authentication. Below shows the pass-through authentication flow.
How it works
When user access any office 365 application, it will redirect the user to Azure AD for authentication, Azure AD prompt the user to enter both the user and password and it will be sent to AuthN agent server in On-Premise using a securing tunnel established when configuring the AuthN agent.
AuthN agent component validate the user name and password with Active Directory using a Win32 API call to Active Directory and the successful authentication will be sent back to Azure AD. Azure AD authentication successful and send a security token to access the application, the user will gain access to Application.
What is Seamless Single Sign-On Authentication and how it works:
Seamless SSO works with Password Hash Synchronization and Pass-through authentication. For the seamless SSO to work, the machine has to be domain joined and should have access to AD. Machine authenticates with Azure AD using Kerberos token.
How it works?
When Seamless SSO enabled, new computer object created in AD that holds 2 SPN for authentication with Azure AD. Let us take User access a claims aware application, user will be redirected to Azure AD for authentication, Azure AD instructs the client to do a authentication test to find the client is SSO capable and it will send a unauthorized response and to get a token a token from AD. Client requests a Kerberos token ticket from AD and the same will be send it to Azure AD, Azure AD returns a security token which will sent to application and the authentication will be successful.
If Seamless SSO fails, the other enabled option PTA or PHS will be used for authentication.
