— Steve Syfuhs (@SteveSyfuhs) August 21, 2020
Twitter warning: Like all good things this is mostly correct, with a few details fuzzier than others for reasons: a) details are hard on twitter; b) details are fudged for greater clarity; c) maybe I'm just dumb.
Note this thread was created a while back. Just catching up.
You log into Windows with your FIDO key. Our cloud auth package in Windows (CloudAP) knows how to handle FIDO auth and does the handshake with https://login.microsoftonline.com. That returns an OAuth PRT and a special cloud-minted Kerberos Ticket Granting Ticket.
The TGT is encrypted using the session key agreed to earlier, so only the client machine can process it. Windows knows this key, and knows that this TGT is special, so it triggers a TGS-REQ to a nearby on-prem KDC using this special TGT as the evidence ticket.
Prior to all this you had to register your domain with AAD so it could use FIDO, and in doing so what we did was we created a special Read-Only Domain Controller and RODC krbtgt secret. That secret got synced to AAD and is what we use to encrypt the special TGT.
When your on-prem KDC receives this special TGT it knows that it's special and uses the RODC krbtgt_### secret to decrypt it. The KDC exchanges it for a real TGT and returns it to the client. The client is now in a steady state as far as Kerberos is concerned.
But what about NTLM? Guh. Well, it turns out we can't kill NTLM yet, so when the client had this special TGT in hand and knew to exchange it for a real TGT, it included a special flag on the TGS-REQ to ask the KDC to include some additional SSO creds in response.
Those SSO creds are returned to the client and handed off to the various SSO packages in Windows, one being NTLM, and those packages handle them as they would any other credential. Voila, now they know how to handle NTLM and any other supported SSO protocols. Magic!
Can't forget the pups.