Why does ADFS, WIA and Kerbeos work togethere?

Google search for ADFS and Kerberos, will tell you ADFS uses Kerberos Constrained Delegation, in order to validate your credentials, so there is kerberos authentication between ADFS and your Domain Controllers.

Windows Integrated Authentication (WIA) or true SSO, is when you sign-in without entering your credentials. But why does it only work from inside your local infrastructure? Its the desired experience of SSO.

Because true SSO or WIA, is kerberos authentication. But wait a minute, ain’t ADFS suppose to be SAML-federation? Are we still using kerberos when we have the desired experience of SSO?

When on the inside, by cable or VPN, the client will ask for a kerberos ticket from the Domain Controllers when your connected to your corporate network.
Then when DNS resolves the internal ADFS Servers the client will try to access the sts.domain.com/WIA endpoint on ADFS. You can see this with Fiddler or such tool on the client, if the client for some reason doesn’t have a kerberos ticket it will fail over to basic authentication. Usually happens when you forgot to add your ADFS DNS Name into the clients intranet site settings.

This is true for bought Domain Joined, Hybrid Joined and Azure AD Joined devices, all though it is only spoken of when Hybrid Joined devices can have a kerberos ticket inside your corporate network, in order to access legacy web-services with kerberos authentication.

We discovered this in a special combination with AllwaysOn VPN on Azure AD Joined devices, because the device had the desired SSO experience, when connected to corporate network through Cisco AnyConnect, but once connected to AllwaysOn VPN, we experience fallback to basic authentication.

WIA uses session credentials from Credential Manager, which AllwaysOn VPN also uses, but unless you have configured AllwaysOn VPN as it was a Intune SCEP certificate, it will not include the necessary information to support true SSO experience. Therefore it failed to basic authentication on AllwaysOn VPN, but because Cisco AnyConnect doesn’t use session credentials, it managed to have true SSO.

But, what about Azure AD Applications like Office 365? We didn’t see this issue with them, and that’s because of Modern Authentication. Or Open Authentication, aka OAuth, and OpenID Connect. Where OAuth does the authentication and OpenID Connect built on top of OAuth 2.0 does the authorization. This means Azure AD doesn’t use SAML federation, but OAuth/OpenID Connect federation.

So start moving all your federated applications to Azure AD, but keep Azure AD federated with AD FS, until your ready to change that for Password Hash Sync or Pass-through authentication with Seamless SSO.

You learn something every day of your life 🙂