How Azure AD Kerberos Works

Let's break this down a bit. You have Azure Virtual Desktop, and you want to stash user profiles into a centralized place. Voila: FSLogix. Not new. But you don't want to host your own file share.


Okay, we have this thing called Azure Files which is SMB over Azure Storage, so stuff the profiles there. That's...actually really cool.


How do you authenticate to it?

So AzFiles introduced Active Directory support.


In principle this is somewhat simple. You create a service principal in your own AD and give it an SPN of cifs/your.file.core.windows.net, and whenever you type \\your.file.core.windows.net your Windows client will dutifully ask AD for a ticket and away you go.


"All" Azure Files needs to know is the service principal password and it can decrypt the ticket, get your identity, get your SIDs, and everyone is happy.


Except how does the AVD host contact AD? It needs to be domain joined or AADJ'ed. And it needs line of sight to a DC.


Okay, well your AVD hosts are in the cloud, and your DCs are in your on-prem network and that means VPN or moving DCs into the cloud AND still needing a VPN for replication yadda yadda yadda. Why can't Azure Files just use AAD to authenticate users?


Let's call it impedance mismatch. Windows understands SMB. SMB understands NTLM or Kerberos. AAD understands OAuth.

.

Well, what if we make AAD understand Kerberos? How do you make the world's largest [web-based] identity provider natively understand the world's most-used [not-web-based] authentication protocol?

And so begins a two-year journey.


First of all, let's set some ground rules. Kerberos is great for many reasons, but it's also janky for others. It has two legs: AS and TGS.


AS exchanges primary creds for tickets.


TGS exchanges tickets for tickets.


The AS leg can be a bit janky.