the client has the service ticket to the target and the fun begins. This is special to AAD-joined target machines only. In the forth case something like PKU2U happens. In the second case user-to-user is skipped, and the client just requests a ticket to termsrv/ and the KDC encrypts the ticket using the service long term key. In any case the ticket is returned to the client. User-to-user is interesting because the KDC will encrypt the service ticket it's about to mint using the session key contained in the additional-tickets TGT instead of the usual long term key of the service itself. The client has the targets TGT and then does a Kerberos TGS-REQ to AD asking for a service ticket to the target name (EDIT host/) termsrv/, and passes the TGT into the additional-tickets field to do something called user-to-user or encrypt-in-session-key auth. It's encrypted so only Active Directory can decrypt it, so its safe to pass around. In the first case the target provides its machine account's Kerberos Ticket Granting Ticket. The target happily responds and depending on a few conditions might do a couple different things. NLA works by first opening an SPNEGO Negotiate connection with the target. NLA is the first stage of the CredSSP protocol, which is how those creds you typed in make it to the target server securely. Once the user enters their creds NLA kicks in. Doesn't do anything special, just prompts. The client then immediately prompts for credentials. In this case the target responded and said please do NLA - network level authentication.
The first thing the client does is ask what protocol is supported. 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. Have you ever wondered how that works for things like Remote Desktop? /8r16tHkclN A couple weeks ago I created a thread about logging into Windows.
0 kommentar(er)
