Figuring out the best way to implement Single Sign-On (SSO) in a Microsoft cloud environment can be challenging given how the options have evolved over time, but it’s a key component of any successful Office 365 or Azure deployment. There are four main options on how you can configure SSO:
Each of these options are available with all flavors of Office 365 licensing, but they have advantages and disadvantages that we’ll want to understand before making our decision. Let’s review each of them in order.
The most basic option is to not implement single sign-on at all, which might make sense for smaller implementations. In this scenario, user accounts are provisioned on Office 365 and users logon independently of their local Active Directory.
- Quick implementation
- Self-service password reset is available for Office 365 accounts
- No need to dedicate servers or infrastructure for SSO
- Can be used if Active Directory is not deployed or most clients are not AD joined
- No SSO for end users
Once we’ve made the decision to implement SSO, password sync is our most basic option. Microsoft provides a tool called Azure AD Connect to synchronize user data from our on-premise Active Directory to Azure AD. This saves us from provisioning user accounts on Office 365 while also giving us the ability to synchronize a hash of the end user’s password. The end user’s full password is not synced and a password change on-premise will trigger a sync. In this scenario, users will logon to Office 365 with their email address/UserPrincipalName and then enter the same password they use in their on-premise Active Directory.
- Users have one password to remember for on-premise and Microsoft cloud services
- The same server that syncs my user data also syncs passwords which minimizes my on-premises infrastructure footprint
- My AD infrastructure or Internet can be down without restricting the ability to logon to Office 365
- Domain-joined clients will still be prompted for passwords although Outlook does can check a box to save their password
- Since logons terminate in Azure AD, we lose the ability to have more granular logon restrictions that come with full Active Directory such as restricting logon times which can be critical for some businesses due to changes in federal labor regulations regarding hourly employees.
- Self-service password reset for Office 365 accounts is unavailable without purchasing Azure AD Premium or Enterprise Mobility + Security Suite licenses.
With pass-through authentication, we’re finally getting to true SSO. Microsoft released this option in December, 2016 and it’s currently in public preview as of January 15. The latest version of the Azure AD Connect tool includes an agent that opens and maintains an outbound connection to Azure AD (no DMZ or firewall rules required). When this option is enabled, user logons to Office 365 are passed back through this open tunnel to your on-premise Active Directory where they are authenticated live. This means we have access to logon time restrictions. Of course, the downside of having machines authenticate against your local AD is that we need to provide high availability. The good news is that we can deploy additional agents which ideally would use separate internet connections.
The best part is that pass-through authentication means that we can now have domain joined machines pass through their domain credentials seamlessly. This takes place automatically in most web browsers (IE, Chrome and Firefox). If we have Outlook 2013 or later deployed and modern authentication enabled, Outlook can take advantage of seamless single sign-on as well.
- True single sign-on for domain joined PCs in Outlook (2013 or later) and in the web browser – no password needed.
- Similar experiences to password sync for external or non-domain joined PCs.
- Built into Azure AD Connect which minimizes my infrastructure footprint.
- Can deploy additional agents for redundancy.
- Some organizations have security requirements that prohibit syncing a password hash
- Building sufficient redundancy can be a challenge for companies with a single datacenter and internet connection.
- Browser based single sign-on still requires an initial “challenge” to determine where to redirect authentication. If I logon to my SharePoint online site or the Office 365 portal, I get prompted for my username. When I enter that, I get redirected to the pass-through authentication mechanism which then passes my credentials through seamless. Our next option, federated identity, offers a solution to this challenge.
Federated identity offers the best overall end user SSO experience in the Microsoft cloud and 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, we need to deploy Active Directory Federation Services (ADFS) in our on-premise network. A typical deployment would be a two-server farm at separate sites (Azure is an option to add a second site for single datecenter customers). Two additional servers are needed in a DMZ 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 us use what’s called SmartLinks technology to allow users to logon directly to SharePoint online without entering a username or password.
We also have access to security features not available in other scenarios. We can enable client access filtering which lets us restrict access to Microsoft cloud services based on IP address (commonly used when we have hourly employees that shouldn’t be able to check email from home). We can also integrate with on-premise multifactor authentication servers (although you should be looking at Microsoft Azure options for MFA).
- 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.
- Additional infrastructure requirements.
- Additional points of failure.
- Additional cost to setup.
- SSL certificate from a public CA is required which will require periodic updating.
Learn more from the blog article: Understanding Office 365 identity and Azure Active Directory
Think you are interested in SSO but want to talk with an expert about which option is best for your company and environment? Contact us today!