It contains all your user details including your display name and group memberships.
#WIRESHARK WINDOWS PASSWORDS PASSWORD#
Well LSA knows that password so it decrypts the ticket! Within that ticket is your PAC - Privilege Attribute Certificate - yeah, silly name. The ticket for this machine is encrypted to that password.
Your machine is registered as a computer object in AD and has a password. Well, the next thing Kerberos does is uses the TGT to make a TGS-REQ to AD for the machine you just logged on to: host/. It doesn't get stored in the SAM.Īt this point you're at the desktop, you now have a TGT and can run around the network, but how exactly did the local computer know anything about you, like your name, your groups, any of that? The TGT is encrypted where the client can't ever read any contents, so what gives? Identifying Yourself to the the Local Machine Kerberos uses the password to do an AS-REQ to Active Directory and gets a TGT. You're at the desktop and LSA moves on to the next package: Kerberos. Well, it turns out cached logon always happens first. What about Active Directory? What about kerberos? Authenticating to Active Directory You've signed in and all you've done is touched the cache. This logon triggers your desktop to load. The blob from this is then compared to the verifier stored in the SAM cache and if it matches it tells LSA the user is logged on. } SECPKG_FUNCTION_TABLE, *PSECPKG_FUNCTION_TABLE PLSA_AP_POST_LOGON_USER_SURROGATE PostLogonUserSurrogate PLSA_AP_PRE_LOGON_USER_SURROGATE PreLogonUserSurrogate SpGetTbalSupplementalCredsFn *GetTbalSupplementalCreds SpGetRemoteCredGuardSupplementalCredsFn *GetRemoteCredGuardSupplementalCreds SpGetRemoteCredGuardLogonBufferFn *GetRemoteCredGuardLogonBuffer SpValidateTargetInfoFn *ValidateTargetInfo SpUpdateCredentialsFn *UpdateCredentials SpChangeAccountPasswordFn *ChangeAccountPassword SpSetCredentialsAttributesFn *SetCredentialsAttributes SpSetContextAttributesFn *SetContextAttributes SpSetExtendedInformationFn *SetExtendedInformation SpQuer圜ontextAttributesFn *Quer圜ontextAttributes SpGetExtendedInformationFn *GetExtendedInformation SpAcceptLsaModeContextFn *AcceptLsaModeContext SpInitLsaModeContextFn *InitLsaModeContext SpDeleteCredentialsFn *DeleteCredentials SpFreeCredentialsHandleFn *FreeCredentialsHandle SpQuer圜redentialsAttributesFn *Quer圜redentialsAttributes SpAcquireCredentialsHandleFn *AcquireCredentialsHandle SpAcceptCredentialsFn *AcceptCredentials PLSA_AP_CALL_PACKAGE_PASSTHROUGH CallPackagePassthrough PLSA_AP_CALL_PACKAGE_UNTRUSTED CallPackageUntrusted PLSA_AP_LOGON_TERMINATED LogonTerminated PLSA_AP_INITIALIZE_PACKAGE InitializePackage Here is, for instance, all the different functions a package can expose to LSA. One of these, msv1_0, chimes in and says it'll give it a try, and takes the password and runs it through a KDF (pbkdf2). Some packages say "pfft, no." Others say "why yes, yes I can". LSA asks each package "hey can you deal with these credentials?". Well, LSA itself doesn't really know what any of these do so it just loops through all of them. Maybe you've heard of them: negotiate, Kerberos, msv1_0, etc. Now we're in LSA, and LSA has a list of these things called authentication packages. Now what? Well, the credential provider takes that password and converts it into a data structure and makes an RPC call to LSA. Okay, so you've selected your credential provider and entered your password. Windows knows what credentials are supported on this machine, so it enumerates them and shows them. Windows has a list of maybe 2 dozen credential providers to do various tasks, like take your password, handle your smart card, scan your fingerprint, etc. For a bit of a detour into building Credential Providers see Creating Custom Windows Credential Providers in. All they do is take keystrokes and convert them to data structures LSA understands. They are the thing that ferries your human-entered credentials into LSA. Windows needs to know how it'll accept your creds. 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.įirst things first. Have you ever wondered what happens behind the scenes when you type your password into the Windows logon screen and hit enter? I'm waiting for a build to complete, so I'm gonna tell you. Update: I recorded a video on this! OPS108: Windows authentication internals in a hybrid world ()
0 kommentar(er)
