Yesterday we announced the public preview of, amongst other things, Azure AD Kerberos. I discussed a bit about how we did it, and why the features depend on it. But I didn't really explain why we chose the solution we did.

Here's why.

There are... mmmmmm ...a bajillion... Windows devices out in the world today (give or take). Some running the latest and greatest Windows 11, others running various versions of Windows 10, others running Windows 8, Windows 7, XP (seriously folks?), and all the various servers.

There are... mmmmmmm ...half... a bajillion line of business apps that rely on Active Directory-backed authentication. Some Windows-based, some not-Windows-based. The vast majority of them use Kerberos to authenticate in some way or another.

Over the next few years folks are going to want to migrate lots of these things to the cloud, either lift-and-shift, rewrite, replace-with-SaaS, etc. and they'll inevitably want to shift away from this on-prem dependency.

There are *very* good reasons for that. AD has networking constraints, doesn't support certain authentication methods like FIDO, doesn't have easy to use policy controls, is showing its age with the likes of NTLM, etc. I could go on.

Conversely the cloud -- Azure AD -- has moved mountains with its capabilities: Conditional Access policies, Multifactor Auth, FIDO, world-class auditing and security and reliability.

Clearly there's a gap here so it makes sense for apps to want to take advantage of what Azure AD can offer. If you're lucky you can replace functionality with OAuth or SAML, but many apps will still require protocols like Kerberos.

These are the laws of big numbers. If you have a billion things using Kerberos and replace half of them with something else, congrats! You've seriously done the unthinkable. However, you still have half a billion things to do something about.

Okay crazy idea: What if we made Kerberos a first-class modern protocol for Azure AD?

Voila: Azure AD Kerberos.

But Kerberos has its issues. It's insecure, it's hard to use, it's ugly, it's it's it's it's.

It's none of those things. You're holding it wrong. Yes, I just said that. Hear me out.

You're holding it wrong because of us.

Making sweeping changes to improve the security of these things is *hard*. Compatibility is one issue, time to market is another, time to mass adoption is yet another. These all add up to great features like gMSAs and Windows Hello, but it take's time. How do we move faster?

Kerberos is insecure because it relies on passwords and humans are bad at keeping passwords secure. The weaknesses are because the security of the protocol relies on the strength of the password and weak passwords can be easy to crack.

Conditional Access MFA

We solved that through some pretty simple rules:

  1. You just can't do password auth.
  2. Service Principal secrets are not passwords. They're randomly generated noise.
  3. There's no fallback to NTLM.

Kerberos is hard to use.

I mean, is it?

Nevertheless, we now do all the heavy lifting for you. You had to make sure you typed the password in right and had to give it the right SPN, but now we do that for you in the majority of the cases.

Kerberos is ugly. I guess? But have you looked at how TLS client certificate auth *really* works?

I'm getting off topic.

Anyway, let's talk about it in action. With on-prem AD how would you lock down a file share to require MFA like Windows Hello? Well, I guess you'd have to look up the Windows Hello SIDs and stick deny ACLs on there when they...aren't...present? How the frig do you do that sanely?

Azure AD just requires a Conditional Access policy. 

It's a checkbox.

Maybe you only want devices that comply to a certain company policy. With on-prem AD you...deploy PKI for device certs marked with EKUs that indicate compliance, force machine certificate auth, roll out claims policies issued on presence of EKUs and

Device Compliance

I can't remember what else.

Just a checkbox in Azure AD.

Location Policy

Maybe you only want users accessing the file share from certain regions or jurisdictions or countries. With on-prem AD you... if you just... ah well... or I guess ...NAP? Is that a thing still?

Still just a checkbox in Azure AD.

Well, okay. They're radio buttons.

Conditional access for Kerberos is a billion-dollar security control if you ask me, and it's just built in to Azure AD for you for free.

Auditing is another critical aspect. You have 300 Domain Controllers in your environment, and you want to find out if a user that lives in North Carolina just logged in at 3:30am from... Angola?

Yeah, I don't even know where to start.

It's a search field in Azure AD.Audit Search

So, put all of this together and you can see why you might want to modernize your Kerberos usage.