When I started learning Entra ID (then still Azure AD), my biggest challenge — aside from the seemingly endless products renamings in M365/Azure — was that "SSO" (= Single Sign-On) has almost become a buzzword.
If you are currently looking for ways to standardize ldentities and less frequently interrupt a users work for logins, you are bombarded with fundamentally different technologies that are difficult to distinguish at first glance. So, I made it my task to collect all the core concepts and present when they are needed.
From here, one can then dive further into the documentation and other articles to implement what is necessary, which details need to be considered, etc.
My definition of SSO requires not only use of the same user information but more importantly, that a user has to log in only once and then gains access to other applications without further interaction.
Also outside the scope: Virtual Desktop Infrastructure (VDI), as the capabilities vary greatly depending on the provider. For instance, Azure Virtual Desktop and Windows 365 support Entra ID SSO, while a solution is on the roadmap for Citrix.
Clientside
Once I have logged into Entra ID, my device must have the capability to share this login with other applications. Under Windows, this is built directly into the operating system. Probably unsurprisingly, other manufacturers have less interest in supporting Microsoft mechanisms by default.
The login usually takes the form of PRTs, more details:
Android
Entra ID authentication is based on web protocols, with session information stored in the web browser. Without using a common browser, SSO between different applications would not be possible. Ideally, apps should use the operating system’s standard browser, but this is often not the case.
To solve this problem, the Intune Company Portal and Microsoft Authenticator can serve as "broker apps", or intermediaries. They store the current login sessions of a user and enable sharing these between applications. Unfortunately, these features are not part of the operating system itself, requiring applications to be able to communicate with these brokers. This is typically achieved using the Microsoft Authentication Library (MSAL). MSAL facilitates the implementation of authentication protocols for developers and also integrates Microsoft’s broker applications by default.
Further Reading
Enterprise SSO for iOS und macOS
What applies to Android also applies to macOS and iOS—with the minor difference that on iOS, only the Microsoft Authenticator can act as a broker, while on macOS, the Intune Company Portal exclusively takes on this role.
Additionally, the broker can be integrated directly into the operating system — Apple provides the so-called “Authentication Services Framework” in its operating systems, into which the Microsoft broker service can be integrated as a plug-in. Through appropriate configurations, authentication processes from apps that do not use MSAL can also be redirected to the broker, thus extending the SSO.
Under macOS this includes login to the device through Platform SSO, similar to Hello for Business under Windows.
Seamless SSO for Windows
I initially mentioned that the SSO mechanisms under Windows are integrated directly into the operating system. However, this integration is not entirely automatic, and this is precisely where the biggest pitfall lies in terms of understandability.
Seamless SSO encompasses two aspects: On one hand, Microsoft uses this term to describe the authentication mechanism for devices that have exclusively joined Entra ID and are accessing resources in "traditional" Active Directory domains. At the same time, it covers the opposite scenario: login of clients that are registered only in "traditional" Active Directory domains to Entra ID-protected resources or applications.
The implementation of Seamless SSO with Entra ID is particularly important at the beginning of an organization’s transformation towards hybrid infrastructure, or when terminal servers are present in an environment. This allows leveraging the benefits of connecting to Entra ID as early as possible, at least partially. For this, a computer account is integrated into the on-premises domain, which issues Kerberos tickets for Entra ID. However, it must be clear that MFA can never be included in this SSO because Kerberos does not support MFA within the protocol by default. Thus, one usually remains reliant on IP or device exceptions from MFA.
For Seamless SSO to On-Premises or rather Active Directory resources, Windows itself does most of the work. When a login from a domain is requested, which is recognized as synchronized with Entra ID, Windows can present the password and the synchronized On-Premises username that was used when signing in to the device, without needing further user interaction. Those paying attention might wonder: What if Windows does not currently have my password saved? If the user hasn’t entered a password at Windows login (e.g., because they use Hello for Business), Entra ID, with appropriate configuration, issues a Kerberos ticket that can be used On-Premises.
In both scenarios, Entra Connect Sync plays a central role: Both sides need to know which objects in Entra ID and Active Directory correspond to each other. Additionally, the Connector PowerShell Cmdlets manage the Active Directory objects and associated secrets used in the authentication process. It is also inevitable that a connection with Active Directory is necessary — so one is, unfortunately, dependent on a VPN. At least as long as there are still systems dependant on Active Directory 😉
Application Side
Our device now has access to a shared login — now we need authentication consumers. We’ve already touched on some aspects with Android and iOS — for example, the Microsoft Authentication Library (MSAL). But what about infrastructure components and server- or web-based applications? Naturally, the fundamental requirement is that the application does not exclusively authenticate with a username and password from its own database. Such apps are usually either outdated or their development leaves something to be desired (excluding apps where SSO is a paid feature), and should be considered for replacement.
SAML / OIDC
The current gold standards of web-based authentication are SAML and OIDC. SAML is probably the most widely used, due to its age. However, OIDC is gaining momentum — especially because of ongoing development and the advantages of token-based authentication. Both standards are, of course, also supported by Entra ID.
As completely open standards, it is very likely that some of the software in your arsenal already supports one of the protocols and would not need to interrupt the user at all to determine their identity and access rights. Not only can this improve the user experience, the use of an Identity Provider like Entra ID allows centralising management of user information and permissions, making life easier for administrators.
So check if your application is perhaps already listed in the Entra ID app catalog. Note, not all applications that support SAML and OIDC are listed here. The Entra ID specific guides and pre-configurations do simplify implementation though.
Application Proxy / Entra Private Access
If the application is too old for modern protocols, not all hope is lost — common "legacy" authentication methods can still be integrated. An appropriate proxy service can translate the old protocols, which are not suitable for the internet, into modern ones. For example, with Entra ID’s "Application Proxy", HTTP header, SAML, Kerberos (= Integrated Windows Authentication), and password-based authentication can be connected.
It’s important that the Microsoft solution fetches requests from Entra ID and is never directly accessible on the internet.
The same connector agent is also used by Microsoft’s new solution, Entra Private Access, which in the future will also support UDP and any TCP connections — in addition to enhanced control options. Whether Microsoft will pursue the strategy of eventually discontinuing the "free sample" Application Proxy remains to be seen.
This article was written before the connector was renamed to "Entra private network connector" – so from Microsofts perspective it is very clear which name should be put first
The translator mantle can also be donned by third-party proxy systems like F5 BIG-IP or Citrix NetScaler, to maintain more control over traffic and performance.
3rd Party Identity Provider
Existing identity providers (IdPs) can also be integrated — most IdPs can take on the role of Relying Party or Service Provider, effectively functioning like an application bound to Entra ID. Depending on the configuration and IdP, SSO sessions can be transferred seamlessly to systems that may not be directly linked to Entra ID.
You may not be aware that you are using another IdP — middleware solutions like SiteMinder, installed within a web server to centralize authentication, can also be seen as IdPs. By connecting these, login processes optimized by Microsoft can be extended to other systems.
Many applications also bring their own IdP. Shibboleth and KeyCloak are commonly used to perform the same function as MSAL — a separate provider that takes over authentication so developers do not have to implement it themselves.
Entra ID can also be configured as the receiving component — authentication occurs through another IdP, which Entra ID then trusts — Microsoft refers to this arrangement as “Federation”. However, in this setup, many advantages of Entra ID authentication can be lost, so preferably, trust would go in the opposite direction.
- Okta: Entra ID as a Connected IdP
- SiteMinder: Add a New SAML IdP
- Long-term: Migrate applications directly to Entra Auth
- MS Docs: Federation
- Typically better documented by 3rd party IdPs
- Brian Reid: Example Challenge Using Other IdP: Conditional Access
Conclusion
We see that a variety of technologies and configurations must be considered and utilized on the path to SSO. Each carries its own challenges and nuances that could fill their own articles — but at least we know the paths we can embark upon.
I hope I was able to give some readers an idea of how the user experience can be improved or provided a little guidance for a first journey.
Do you have thoughts on these options or know something that I might have missed? I would love to hear from you 😊. Join the discussion on my associated LinkedIn post.
If you’re interested in the things I do, follow me on LinkedIn.
High Resolution Diagram
Updated 30.04.24 to show where PRT is used (Thanks Merill Fernando!)
Updated 06.05.24 to include macOS Platform SSO
All paths to Entra SSO by Julian Sperling is licensed under CC BY-SA 4.0
