Kerberos Might Not Be Dead, but It's Not Feeling Well

At the 2012 Cloud Identity Summit, Kuppinger Cole analyst Craig Burton declared that "SAML [Security Assertion Markup Language, a web services authentication standard] is dead." SAML is the most broadly adopted authentication standard in the web services world, so this pronouncement caused quite a stir. The debates that followed established that, no, SAML isn't dead, but the momentum of future implementations has shifted toward other standards such as OAuth 2.0, OpenID Connect, and SCIM. In other words, the growth of SAML-based services is slowing and will continue to slow down. (Burton's fellow analyst Dave Kearns has a good summary of the "SAML is dead" debate.) Some other folks have since used the " is dead" meme, most notably for the XACML authorization standard.

At the risk of being accused of jumping on Burton's very long coat tails, Kerberos faces this same situation. Standards have a lifecycle. They rise when existing standards don't meet the needs of modern use cases. They very slowly fade into the sunset when a new set of requirements evolve that the standard can't adapt to, and a new standard emerges. Kerberos is on the cusp of that long slow slide.

Authentication in the Enterprise

Today, Kerberos dominates the enterprise universe. This security protocol first appeared in 2000, when Windows 2000 Server and its Active Directory (AD) security component were released, and as AD and AD-enabled applications grew in market share, so did the use of Kerberos. It's been the primary security protocol for the Microsoft-centric world ever since; it handles authentication and passes authorization data to domain resources.

When Kerberos was chosen to be AD's authentication protocol in the mid- to late-1990s, the World Wide Web was a shadow of what the Internet offers today. Although the Kerberos ticket contained an encrypted password hash that could be attacked, there wasn't any substantial requirement to provide support outside the highly protected corporate firewall.

Authentication in the Web Services World

The rise of cloud services is changing many aspects of our lives, and these services don't support external authentication via Kerberos because of that password vulnerability. If a web service uses standards, it handles claims-based authentication using SAML 2.0 or, increasingly, OAuth 2.0 and OpenID Connect. Microsoft's own Azure Active Directory doesn't use Kerberos; it supports SAML and OAuth 2.0 as its authentication protocols.

I don't mean to imply that web services have implemented authentication standards in the same thorough way that the closed Windows Server security model has implemented Kerberos. Far from it! Web services have standards—but actually implementing them is another matter. Getting cloud service providers to adopt standards is like herding cats; a quick review of the hundreds of SaaS apps available on OneLogin's IDaaS portal shows that only a very small percentage support identity federation standards. The rest support only form-based authentication—in other words, a user ID and password. That's why it's so important that customers help drive standards adoption to reduce the password proliferation that has us all grinding our teeth in frustration.

Microsoft and Its Cloud Commitment

Even within the Microsoft ecosystem, software architectures are moving away from Kerberos due to the cloud. In addition to their on-premises versions, Microsoft partners are developing hybrid or web-only versions of their products. Microsoft itself is "all in" to the cloud, and is driving aggressively forward in its cloud services portfolio and (at a slower pace) its support of cloud identity standards. AD itself is a perfect example.

In Windows Server 2012 R2, the most significant enhancements to the AD platform were made to Active Directory Federation Services (AD FS), not Active Directory Domain Services (AD DS). AD FS is an authentication head for AD DS that extends AD DS's reach to the world of web-based services that support SAML 2.0 and—in Windows Server 2012 R2's AD FS implementation—OAuth 2.0. (Think of AD FS as the teenager translating new technology to the AD DS adult that just doesn't understand it.) The largest identity-related scenario in Windows Server 2012 R2 focuses on the capability to access web-based corporate resources from iOS devices inside or outside the corporate network. Also referred to as Workplace Join (one of the scenario's features), it only works for web-based resources such as websites like Outlook Web Access (OWA) that use Windows Integrated authentication, or servers like SharePoint that now support claims-based authentication. SMB and Kerberos are not supported in this scenario. A friend calls this rise in web-friendly, on-premises services "the SaaSification of the enterprise."

These new access enhancements to web resources were made possible by major enhancements to AD FS and its new proxy service—not AD DS. Relatively minor changes were made to AD DS, and indeed the other AD DS enhancements in the Windows Server 2012 R2 release are not earth-shaking. It's a mature product.

I'm Not Dead Yet!

As with SAML, Kerberos isn't going away any time soon. As long as there are AD DS domains and forests, there's a place for Kerberos. Even in the unlikely event that on-premises AD DS forests are cut down in favor of cloud services, innumerable forests will live on in public cloud IaaS installations. But developers are increasingly turning their focus to cloud services at the expensive of on-premises applications.

This also means that you, the IT pro, need to be able to understand these new standards, at least from a configuration and support viewpoint. The better you can translate this different world to your management, the more valuable you'll be.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.