Examine authentication options in Microsoft 365
Microsoft Entra ID is an online instance like Active Directory. Microsoft Entra ID provides authentication and authorization for Microsoft 365 and for other Microsoft cloud offerings, including Azure. Microsoft Entra ID can authenticate cloud-only identities or identities synchronized with an on-premises directory.
There are different ways in which identities can be authenticated. Authentication can optionally use password hash synchronization. Or, you can enable user authentication with on-premises user accounts through Active Directory Federation Services (AD FS) or other single sign-on (SSO) providers.
Authentication options in Microsoft 365 fall into one of the following categories:
Cloud-only. Cloud-only identities are exactly as the name suggests; the user identity only exists in the cloud, so all password management and policy control are done through Microsoft Entra ID. The following graphic shows the sign-in of a Windows client to Microsoft Entra ID to get access to the Microsoft 365 services.
Directory synchronization with Pass-Through authentication (PTA). This authentication option provides a simple password validation for Microsoft Entra authentication services. PTA uses a software agent running on one or more on-premises servers to validate an organization's users directly with its on-premises Active Directory. With PTA, on-premises Active Directory user account objects are synchronized with Microsoft 365 and users are managed on-premises. PTA enables users to sign in to both on-premises and Microsoft 365 resources and applications using their on-premises account and password. The following graphic symbolizes the sign-in of a windows client to Microsoft Entra ID when using PTA. In this scenario, the sign-in request is redirected to an on-premises infrastructure.
Single sign-on (SSO) with AD FS. One of the main reasons for organizations to use AD FS is their compliance or business requirement that restricts them from synchronizing passwords into any cloud. As such, AD FS the only way for them to perform authentication to access Microsoft 365 services. The SSO option hands over authentication control to an organization's directory service. As such, users no longer authenticate against Microsoft Entra ID but against AD FS. When a user types their credentials (for example, user@adatum.com) into the Microsoft 365 sign-in page, the user receives a message telling them that they've been redirected to their organization’s sign-in page. They now enter their on-premises credentials and authenticate to the Microsoft 365 online services by using a delegated token. This token indicates to Microsoft 365 the user has been successfully authenticated by their on-premises directory. In the following graphic, the sign-in arrows and processes are similar to PTA. However, another federation server proxy is required for AD FS because the AD FS Server hosting the farm isn't allowed to accept connections from the public network.
In AD FS in Windows Server 2012 R2, the role of a federation server proxy is handled by a new Remote Access role service called Web Application Proxy. To enable your AD FS for accessibility from outside the corporate network, which was the purpose of deploying a federation server proxy in legacy versions of AD FS (such as AD FS 2.0 and AD FS in Windows Server 2012), you can deploy one or more web application proxies for AD FS in Windows Server 2012 R2. In the context of AD FS, Web Application Proxy functions as an AD FS federation server proxy. In addition to this, Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network. This design enables users on any device to access them from outside the corporate network.
