Create a deployment strategy to implement Microsoft 365 services
Microsoft 365, together with Microsoft Entra ID, provides different avenues for companies to authenticate into its services. The following list identifies the different strategies that can be implemented in an organization’s tenant and environment:
Cloud only. This strategy has the least setup compared to the other identity strategies - all that's needed is a subscription and a sign-in account. The Cloud only strategy is managed from a web interface from the Microsoft 365 Admin Center or by remotely accessing the service using PowerShell.
Password hash synchronization. Hashes of user passwords are synchronized from on-premises Active Directory to Microsoft Entra ID. When passwords are changed or reset on-premises, the new password hashes are immediately synchronized to Microsoft Entra ID. This design enables users to always use the same password for cloud resources and on-premises resources. The passwords themselves are NEVER sent to Microsoft Entra ID or stored in Microsoft Entra ID in clear text.
Microsoft Entra pass-through authentication. You can enable Seamless Single Sign-On (SSO) for users on domain-joined machines that are on your corporate network. With single sign-on enabled, users only need to enter a username to help them securely access cloud resources. Microsoft Entra pass-through authentication allows your users to sign into both on-premises and cloud-based applications using the same passwords. The Pass-Through Authentication process is summarized as follows:
- On receiving the request to sign in, Microsoft Entra ID places the username and password (encrypted by using the public key of the Authentication Agents) in a queue.
- An on-premises Authentication Agent retrieves the username and encrypted password from the queue. The agent doesn't frequently poll for requests from the queue but retrieves requests over a 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. This mechanism is similar to what is used by Active Directory Federation Services (AD FS). The username can either be the on-premises default username, usually User Principal Name, or another attribute (known as Alternate ID) configured in Microsoft Entra Connect.
- 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 returns this response back to Microsoft Entra ID, then Microsoft Entra ID evaluates the response and responds to the user as appropriate. For example, Microsoft Entra ID either signs the user in immediately or requests Microsoft Entra multifactor authentication. If the user sign-in is successful, the user can access the application.
Microsoft Entra pass-through authentication with Seamless Single Sign On (SSO). You can combine Pass-Through Authentication with the Seamless Single Sign-On. 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.
Federated SSO with Active Directory Federation Services (AD FS). With federated sign-in, users sign in to Microsoft Entra ID-based services with their on-premises passwords. This service uses an intermediary server call to a WAP, which uses proxy DNS names to route users to their required location. While they're on the corporate network, they don't even have to enter their passwords. An organization that uses the federation option with AD FS can deploy a new or existing farm with AD FS in Windows Server 2012 R2. If you choose to specify an existing farm, Microsoft Entra Connect configures the trust between your farm and Microsoft Entra ID so that your users can sign in.
Warning
Depending on your environment, this option can be the most complex and costliest to set up.
The following table compares the different deployment strategies for implementing Microsoft 365 services:
| Consideration | Password hash synchronization + Seamless SSO | Microsoft Entra pass-through authentication + Seamless SSO | Federation with AD FS |
|---|---|---|---|
| Where does authentication happen? | In the cloud | In the cloud after a secure password verification exchange with the on-premises authentication agent | On-premises |
| What are the on-premises server requirements beyond the provisioning system? Does it include Microsoft Entra Connect? | None | One server for each extra authentication agent | Two or more AD FS servers Two or more WAP servers in the perimeter network |
| What are the requirements for on-premises Internet and networking beyond the provisioning system? | None | Outbound Internet access from the servers running authentication agents | Inbound Internet access to WAP servers in the perimeter Inbound network access to AD FS servers from WAP servers in the perimeter Network load balancing |
| Is there an SSL certificate requirement? | No | No | Yes |
| Is there a health monitoring solution? | N/A | Agent status provided by Microsoft Entra admin center | Microsoft Entra Connect Health |
| Do users get single sign-on to cloud resources from domain-joined devices within the company network? | Yes with Seamless SSO | Yes with Seamless SSO | Yes |
| What sign-in types are supported? | UserPrincipalName + password Windows-Integrated Authentication by using Seamless SSO Alternate sign-in ID |
UserPrincipalName + password Windows-Integrated Authentication by using Seamless SSO Alternate sign-in ID |
User PrincipalName + password sAMAccountName + password Windows-Integrated AuthenticationCertificate and smart card authentication Alternate sign-in ID |
| Is Windows Hello for Business supported? | Key trust model Certificate trust model with Intune |
Key trust model Certificate trust model with Intune |
Key trust model Certificate trust model |
| What are the multifactor authentication options? | Microsoft Entra multifactor authentication | Microsoft Entra multifactor authentication | Microsoft Entra multifactor authentication Azure Multi-Factor Authentication Server Third-party MFA |
| What user account states are supported? | Disabled accounts (up to 30-minute delay) | Disabled accounts Account locked out Password expired Sign-in hours |
Disabled accounts Account locked out Password expired Sign-in hours |
| What are the conditional access options? | Microsoft Entra Conditional Access | Microsoft Entra Conditional Access | Microsoft Entra Conditional Access AD FS claim rules |
| Is blocking legacy protocols supported? | Yes | Yes | Yes |
| Can you customize the logo, image, and description on the sign-in pages? | Yes, with Microsoft Entra ID P1 or P2 | Yes, with Microsoft Entra ID P1 or P2 | Yes |
| What advanced scenarios are supported? | Smart password lockout Leaked credentials reports |
Smart password lockout | Multi-site low-latency authentication system AD FS extranet lockout Integration with third-party identity systems |
In summary, all resources are bound to the Microsoft Entra user, and the Microsoft Entra user is the "source" for all other resources. These conditions are true for all the deployment strategies that can be used to implement Microsoft 365 services. This concept is depicted in the following diagram.
Knowledge check
Choose the best response for the following question. Then select "Check your answers."