Desktop SSO with SecureAuth
When I log on to my Microsoft Windows domain-joined laptop, it’s the only login I do the entire day, giving me full access to our internal servers and my workplace cloud apps. This is the holy grail of user experience, and it’s often referred as Desktop SSO.
In large part Desktop SSO requires two components to run in tandem – IWA for local SSO and SAML or OIDC for cloud SSO. Combined, this setup creates a seamless desktop SSO experience regardless of how on-prem and cloud apps are integrated – one app can be IWA integrated, one is SAML integrated, and other is OIDC integrated, but from an end-user’s perspective, they have seamless SSO access to these applications directly from their Windows PC.
What is IWA?
When Microsoft initially designed IWA (Integrated Windows Authentication), companies ran their entire IT within local area networks, behind the firewall. IWA was conceived as a way to provide user-friendly Desktop SSO (or DSSO) from domain-joined Windows desktops to domain-joined Windows web servers, all connected to a Microsoft Active Directory server running locally.
Today, large enterprise companies have shifted parts of their IT infrastructure to the cloud, effectively creating a hybrid environment of internal web servers and public cloud services. Identity and Access Management (IAM) solutions have also largely moved to a SaaS model creating challenges around protecting resources across both environments.
Despite major innovations in authentication for web apps (think OIDC), IWA remains incredibly popular in Microsoft-heavy networks and—as a result—companies are looking to keep IWA in place for the foreseeable future. They want to ensure that their Cloud IAM works with SaaS apps as well as any legacy intranet apps, including those that are IWA-protected.
But IWA becomes challenging with Azure and Cloud Identity due to the need to validate Kerberos tickets at the Domain.
Deployment-agnostic desktop SSO
To maintain the familiar user experience of local SSO for users accessing Windows servers and applications from their domain-joined Windows and Mac laptops, SecureAuth offers Windows SSO for Cloud, a dynamic and secure authentication experience without an agent.
Imagine you have a domain-joined user. She logs on to her Windows laptop, her credentials are checked against the Active Directory server. She opens her browser and tries to visit a password-protected intranet web app. Instead of asking her for server credentials, the intranet app server silently authenticates her using the credentials she previously used to log on to her Windows laptop. This flow, called Desktop SSO, provides a much-simplified user experience. For Desktop SSO to work, her laptop must be domain-joined and the Windows intranet web app must be protected by IWA.
Adaptive authentication with IWA and SecureAuth Endpoint
Could you apply risk-based adaptive authentication to the IWA flow? The answer is yes – when you add SecureAuth Endpoint for Windows to IWA, things get really interesting.
SecureAuth Endpoint for Windows enforces contextual risk-based authentication at the time of Windows OS log on. Instead of evaluating risk only at the time of IdP-initiated or SP-initiated auth flow from the browser, SecureAuth Endpoint looks at contextual and risk data at the time the user is physically logging into their PC laptop. For example, when the laptop connects using an unexpected LTE smartphone hotspot, SecureAuth may prompt for additional MFA validation or perhaps refuse the logon attempt completely.
For companies looking to further improve their cybersecurity defenses, it’s worth looking at doubling down on endpoint security. A network perimeter that was historically a firewall has become an endpoint perimeter. Context-based endpoint adaptive authentication or—simply put—MFA for desktop OS login delivered through the SecureAuth Endpoint client provides higher security assurance, and with IWA in place does not compromise on the flawless user experience.