Office 365 identity models – Part 2 (Good for Beginners)
Office 365 identity models – Introduction
Choosing the right authentication method for Office 365 looks simple on paper, but when you get down in the weeds and take a closer look you may realize it’s not that easy.Choosing the correct authentication method is the first concern for organizations wanting to move their apps to the cloud.
This is the continuation article for Office 365 identity model. Let us see more about the identity model in this chapter.
How Pass through authentication works
As far we know until today, the best solution form the Microsoft point of view is, to use ADFS to authenticate on-premises users for cloud services such as Azure or Office 365. This is working very well and there are many articles about how to configure the clams etc. can be found in internet and also on my Blog.
However, if a company don’t want to use ADFS for authentication, there is another way Microsoft supports, but it is not so common like the ADFS solution. In this article I want to present an alternative way using AAD with Pass-through.
Please find the whole authentication progress here,
- The user tries to access an application, for example, Outlook Web App.
- If the user is not already signed in, the user is redirected to the Azure AD User Sign-in page.
- The user enters their username and password into the Azure AD sign in page, and then selects the Sign in button.
- Azure AD, on receiving the request to sign in, places the username and password (encrypted by using a public key) in a queue.
- An on-premises Authentication Agent retrieves the username and encrypted password from the queue. Note that the Agent doesn’t frequently poll for requests from the queue but retrieves requests over pre-established persistent connection.
- The agent decrypts the password by using its private key.
- The agent validates the username and password against Active Directory by using standard Windows APIs, which is a similar mechanism to what Active Directory Federation Services (AD FS) uses. The username can be either the on-premises default username, usually userPrincipalName, or another attribute configured in Azure AD Connect (known as Alternate ID).
- The on-premises Active Directory domain controller (DC) evaluates the request and returns the appropriate response (success, failure, password expired, or user locked out) to the agent.
- The Authentication Agent, in turn, returns this response back to Azure AD.
- Azure AD evaluates the response and responds to the user as appropriate. For example, Azure AD either signs the user in immediately or requests for Azure Multi-Factor Authentication.
- If the user sign-in is successful, the user can access the application.
Federated Identity
Federated identity offers some unique security options not available in other scenarios, but it also has the most requirements in terms of server infrastructure to implement. To enable federated identity, you need to deploy Active Directory Federation Services (ADFS) in an on-premise network. A typical deployment would be a two-server farm at separate sites (Azure has an option to add a second site for single datacenter customers). Two additional servers are needed in a DMZ (demilitarized zone, sometimes referred to as perimeter network) to securely publish ADFS to the internet. Once ADFS is in place, federated identity can be enabled with a few PowerShell commands.
Similar to pass-through authentication, user logon attempts are passed back to the ADFS farm to validate against your local active directory. Outlook 2013 or later will leverage modern authentication to communicate with ADFS. Web browsers will get redirected to the ADFS server to complete their authentication. This lets you use what’s called SmartLinks technology to allow users to logon directly to SharePoint online without entering a username or password.
You also have access to security features not available in other scenarios. You can enable client access filtering which lets you restrict access to Microsoft cloud services based on IP address (commonly used for hourly employees that shouldn’t be able to check email from home). You can also integrate with on-premise multi factor authentication servers (although you should be looking at Microsoft Azure options for MFA).
Pros:
- Full SSO capabilities in the web browser and Outlook.
- Advanced security configurations available including the ability to filter connection on source IP address.
- No need to sync a password hash.
- ADFS farm can be reused with other cloud services that support SAML.
Cons:
- Additional infrastructure requirements.
- Additional points of failure.
- Additional cost to setup.
- SSL certificate from a public CA is required which will require periodic updating.
