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.

Have you ever tried to access an admin SMB share on your local machine (\\localname\c$) only to find out you don't have admin perms despite being a local administrator? Why is that? Here's something you maybe didn't know: It's by design -- it's a way of preventing UAC bypass. pic.twitter.com/1SwNrWn4j8

— Steve Syfuhs (@SteveSyfuhs) January 19, 2021

You might be saying "well duh! That's what UAC does!" 

But we're talking SMB, so it's over the network, therefore it's Kerberos, and Kerberos can't doesn't do UAC over the network because Kerberos doesn't contain local authz information, and UAC is all about local authz.

Note: SMB loopback actually uses NTLM. But let's not let details get in the way of a good explainer. (NTLM does work similarly though)

What's the difference between \\localmachine\c$ and \\othermachine\c$ then? Actually, nothing.

Some background: when a client needs a kerb ticket to something it asks Windows. Windows creates an AP-REQ, which is the requested ticket plus authenticator.

The ticket is created by the KDC. The client can't see inside it, and can't manipulate it. It's opaque. However, the client can ask the KDC to include extra bits in the ticket. See here for fiddly details: A bit about Kerberos (syfuhs.net)

These extra bits are just a way to carry information from the client to the target service during authentication. As it happens one of the things the client always asks to include is a machine nonce.

See, when the client asks the client Kerberos stack for a ticket, the stack creates a random bit of data and stashes it in LSA and associates it to the currently logged on user. This is the nonce. This nonce is also stuck in the ticket, and then received by the target service.

The target service, i.e. the same Windows Kerberos stack, knows about this nonce and asks LSA if it happens to have this nonce stashed somewhere. If it doesn't, well, then it's another machine and just carry on as usual.

However, if it does have this nonce, LSA will inform the Kerberos stack that it originally came from user so and so, and most importantly that the user was *not* elevated at the time.

What does that mean? Not elevated?

This is UAC -- User Account Control. UAC is the thing that *tries* to prevent you from doing something stupid with admin privileges.

See, when you log onto Windows you're granted a set of local privileges. Some of these give you lots of control over the system, like local administrator. UAC is a way of preventing you from doing silly things as administrator unless you reeeeeeally want to.

The way it works is conceptually simple. During login you're given two NT tokens. The first is your high privilege token. It contains all those special privileges. The second is your low privilege token. Everything you do uses your low privilege token by default.

So when you do need to do something with higher privileges you need to ask Windows "Hey! I need the high privilege token, pleeeeeeeeeeeeease".

Anyway, LSA knows all about these tokens, so when it receives this Kerberos ticket and contains that nonce and finds the user, voila it has a low privilege token.

Now the Kerberos stack makes a copy of the ticket contents for it's own SSO session and whenever you do anything in that session, say try write to c$\windows\system32, the authorization system checks the privileges and in this case says nooooope. How Windows Single Sign-On Works (syfuhs.net)

So as a result you don't get to bypass UAC by going through the network. /fin

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.

Speaking of #passwordless... did you ever wonder how we made it work with on-prem Active Directory? It's kind of magic. We built a KDC in the cloud. Here's how it works... https://t.co/ww7qtg0r3P

— Steve Syfuhs (@SteveSyfuhs) August 21, 2020

If you ever want any proof that Microsoft is taking this #passwordless thing seriously, the Windows security org has a custom policy that requires changing their password every 2 weeks just so they're motivated to make the new technology work well.

— Steve Syfuhs (@SteveSyfuhs) August 20, 2020

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.

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.

It's Monday evening, the weather is great, and we're in the middle of a pandemic. Lets talk Kerberos! Or rather, it's little known nephew FAST and Armoring.

— Steve Syfuhs (@SteveSyfuhs) July 28, 2020

You might have heard about it from such features as Windows Kerberos Armoring. It's in fact three separate things. What's New in Kerberos Authentication | Microsoft Docs

First, it's part of a larger body of work called the pre-authentication framework, a way to provide a generic extensible model of adding authentication methods to Kerberos. It gets more interesting, honest.

Second, it's a method of creating a generic secure tunnel for information to flow between a client and a KDC within the original Kerberos protocol. I swear, it'll get interesting.

Third, it's a method where you bind your authentication to the machine account to prevent password attacks like Kerberoasting -- aha, there's the exciting thing! 

Kill all password attacks. Here's how it works.

Kerberos is deceptively simple: you, the client, request a ticket from the KDC. The KDC happily responds and encrypts the response to your password. You decrypt it with your password, and voila you have a ticket. This is dangerous because...

You now have this oracle that'll return encrypted blobs of structured data to any caller, encrypted to a password. This makes cryptographic attacks super easy for weak passwords. A solution was added: the pre-auth timestamp, which is the current time encrypted with your password.

The KDC receives this timestamp, decrypts it because it knows your password (-ish) and verifies the request was within a short period of time. But still, attackers can intercept the messages and perform those same attacks. They just need to convince you to get a ticket first.

The protocol itself is bound by this weak thing -- your password. It needs more randomness. Incidentally, most callers happen to be on a domain joined computer when doing Kerberos, and the computer uses a super random password. Innnnnteresting.

So this framework has this thing called Armoring, which is the idea that you take a key and mix in a whole lotta randomness from another source, and use that instead. So here we take the computer account, and have it request a TGT. The TGT has this thing called a session key.

That session key is protected within the TGT and only the client and the KDC know it. So why not let the KDC use the randomness of that session key to protect the client?

The client gets this new mixed key and can now communicate with the KDC. The randomness of the computer password makes any crypto attack infeasible, and the user can still user a password.

Okay, but what about users that aren't on a domain joined computer? There's a small provision in the spec that lets callers request an anonymous ticket. You lose server authentication, but when you're out alone in the wild, what're you gonna do?

...assuming the KDC supports that provision of course.

Now that's all well and good, but what about this tunneling thing? Well back in the dark ages crypto was export controlled (ugh), which left a lot of protocol designers deciding to leave a bunch of crap in cleartext. FAST said nuh uh, attackers can modify that over the wire.

So you have this super secret shiny key now, and a nice dark hole to shove stuff. So what do we do? We make a copy of the entire request, encrypt it, and shove it in the hole. And leave the outer message in cleartext for appearances sake. 

Because why not?

The cool thing about all this, aside from making password attacks more difficult, is it lets developers easily extend the protocol to include new pre-auth methods like OTPs or PAKEs, and does a reasonably good job of hardening the aging crypto properties of the protocol.

So, go turn it on. It's super easy.

Requisite puppies.