Authentication problem

Question

Hello!

While investigating an authentication issue with our db server I was puzzled by the following:

a) there's a production db server (domain-joined) - named say Srv
b) there's a test standalone server - named say Test

On Srv there're no current network sessions:

On Test there are no cached credentials for Srv or kerberos tickets:

Theoretically in this case when accessing a network share on Srv from Test I'm expecting to see the authentication dialog requesting domain credentials but access is being granted as if the credentials had been already cached:

The event 4624 on Srv displays successful logon using KERBEROS authentication.

Would anybody please tell me where these cached credentials are kept if I can see them neither in Credential Manager nor in Klist? As far as I understand they should NOT stay in memory after the session is closed...

Regards,
Michael

Answer 1

Hi @Hram Admin

Thank you for contact Microsoft Q&A community, hope you have a nice day!

When you access a network share and are granted access without an authentication dialog, Windows is likely using cached domain credentials. These credentials might not store in Credential Manager or visible in Klist because they are not generic credentials or Kerberos tickets. Instead, Windows stores an encrypted verifier of the password in the registry's security hive, specifically for domain logons. This verifier is a salted MD4 hash computed twice, and it allows users to log on locally when the domain controller is unavailable. These cached credentials are not the actual username or password, and they do not persist in memory after the session is closed—they are stored on disk in the registry and used only for validating logons when disconnected from the domain controller.

Allow me to share related Microsoft articles bellow:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn751047(v=ws.11)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh994565(v=ws.11)

Please accept the answer if you believe this information adds some value, so that your experience with the issue would help contribute to the whole community.

T&R

Kate!

Answer 2

Hi Kate,

Thank you so much for the very interesting articles!

Regarding this: "Instead, Windows stores an encrypted verifier of the password in the registry's security hive, specifically for domain logons."

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn751047(v=ws.11)

I always thouth that this - "Each time a user logs on to a domain, Windows caches the credentials supplied and stores them in the security hive in the registry of the operation system." - means that

1 User is pressing CTRL+Alt+Del on a DOMAIN-JOINED workstation and supplies his/her domain credentials

2 After successfull log on he or she may later repeat the process from step 1 without access to a DC (and the "Number of cached logons..." means how many times a user can log on without contacting a DC).

Am I getting you right that the term "~domain logon" can also mean the process of accessing a server share (for example by navigating to \domainserver\share) FROM a NON-DOMAIN computer and supplying user credentials? And that in this case those credentials will also be cached in regestry?

Regards,
Michael

Answer 3

Hi Kate,

Thank you so much for the clarification!

..and this - "So, cached logons in the registry only apply to offline interactive logons on domain-joined machines, not to network share access from non-domain systems." - effectively means that the first answer

• ("Instead, Windows stores an encrypted verifier of the password in the registry's security hive, specifically for domain logons. This verifier is a salted MD4 hash computed twice, and it allows users to log on locally when the domain controller is unavailable.") -

... - does not apply in this case as I'm connecting to \domainserver\share from a NON-DOMAIN computer!

And this brings us back to the original question:

if this is true -

• When you connect to \domainserver\share from a workgroup or non-domain machine, you supply credentials, but these are not stored in the registry’s Security hive.
• Instead, they may be temporarily cached in memory for the session or stored in Credential Manager if you choose “Remember my credentials.”
• Kerberos tickets won’t apply because the machine isn’t domain-joined; NTLM is typically used.

then how come I can access \domainserver\share from a standalone computer when

a) the connection from Test to SRV initiates a brand NEW session
b) there are no saved credentials in Credential Managerand and

c) WHY DOES THIS CONNECTION HAS the AUTHENTICATION TYPE = KERBEROS and NOT NTLM ???

Regards,
Michael