MicrosoftHi HKUMAR365 this is not an answer to the question. Negotiate doesn't mean Kerberos was used. It means we can't say if NTLM or Kerberos was used during such authentication.
Mi1anovic Hi , you are right. It’s complex to confirm. However as per documentation Negotiate gives priority to use Kerberos over NTLM. Network Trace is solid way to confirm if it used Kerberos or NTLM.
Thanks!
Hi HKUMAR365. Thank you for your answer. I agree that network trace is a viable option how to confirm Kerberos or NTLM. However if we consider that a server can host multiple applications and so there can be multiple authentications in a relatively small time window within a same account, it also doesn't sound very promising. I think the better option would be to configure Audit logging on a domain controller a then check security logs on the domain controller. However I wonder if there's something else you can do to 100% verify what authentication protocol was used without access domain controller logs.
MicrosoftFor outbound NTLM enabling Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers - Audit all will log a 8001 event like this one which shows what the client was authenticating to using NTLM and which process was used to make the connection
If the resource server has Network security: Restrict NTLM: Audit Incoming NTLM Traffic - Enable auditing for domain accounts the server will log a 8003 event that will capture the process being connected to by the client.
If the domain controller performing the "credential verification" for that connection has Network security: Restrict NTLM: Audit NTLM authentication in this domain - Enable all (Domain Controllers Only) it will log a event 8004 which captures the user name, workstation name and server name (Secure Channel Name).
The 8001, 8002, 8004 events will be logged a log dedicated to NTLM (Applications and Services Logs\Microsoft\Windows\NTLM\Operational)
Additionall logging will soon be added to Windows 11 24H2 and Server 2025 which will enabling central logging of NTLMv1 via the domain controller logs.
|
Event ID |
4032 (Information), 4033 (Warning) |
|
Event Source |
Security-Netlogon |
|
Event Text |
The DC <DC Name> processed a forwarded NTLM authentication request originating from this domain. Client Information: Client Name: <Username> Client Domain: <Domain> Client Machine: <Client workstation> Server Information: Server Name: <Server Machine Name> Server Domain: <Server Domain> Server IP: <Server IP> Server OS: <Server Operating System> NTLM Security: Negotiated Flags: <Flags> NTLM Version: <NTLMv2 / NTLMv1> Session Key Status: < Present / Missing> Channel Binding: < Supported / Not Supported> Service Binding: <Service Principal Name (SPN)> MIC Status: < Protected / Unprotected> AvFlags: <NTLM Flags> AvFlags String: <NTLM Flag String> Status: <Status Code> Status Message: <Status String> For more information, see aka.ms/ntlmlogandblock |
The new client event (4020) will include a fields that will help identify why NTLM was used
|
Event ID |
4020 (Information), 4021 (Warning) |
|
Event Source |
NTLM |
|
Event Text |
This machine attempted to authenticate to a remote resource via NTLM. Process Information: Process Name: <Name> Process PID: <PID> Client Information: Username: <Username> Domain: <Domain Name> Hostname: <Host Name> Sign-On Type: <Single Sign-On / Supplied Creds> Target Information: Target Machine: <Machine Name> Target Domain: <Machine Domain> Target Resource: <Service Principal Name (SPN)> Target IP: <IP Address> Target Network Name: <Network Name> NTLM Usage: Reason ID: <Usage ID> Reason: <Usage Reason> NTLM Security: Negotiated Flags: <Flags> NTLM Version: <NTLMv2 / NTLMv1> Session Key Status: < Present / Missing> Channel Binding: < Supported / Not Supported> Service Binding: <Service Principal Name (SPN)> MIC Status: < Protected / Unprotected> AvFlags: <NTLM Flags> AvFlags String: <NTLM Flag String> For more information, see aka.ms/ntlmlogandblock. |
Thanks I 100% agree and I somehow knew that this can be a way how to analyze this. However, in my case I don't have access to logs of domain controllers. I'm just an admin on a server joined to a domain.
