MicrosoftHi JerryDevore
I have a question regarding MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 as the Authentication Package in the EventId 4624.
Would you be able to confirm if this authentication package means that the authentication process used NTLMv1 to validate the credentials? or can we safely ignore this when auditing for any NTLMv1 authentication?
Additionally, the Package Name (NTLM only) is empty. Here's what the Detailed Authentication Information from the Event logs looks like:
Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
MicrosoftHi Ma06RC - Given the package name is empty you can safely assume NTLM (v1 or 2) was not used for this authentication. Advapi likely implies is was either some from of local logon or a simple bind to ldap.
Hi, I'd like to challenge that statement. When we first disabled NTLMv1, our NPS servers suddenly stopped working. We saw authentication events listed under Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 (msv1_0.dll), but the Package Name (NTLM only) field was empty. We resolved the problem by configuring MS-CHAPv2 to use NTLMv2, as described https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/rras-vpn-connections-fail-ms-chapv2-authentication.
Because nothing showed up in the logs, the issue wasn’t apparent at first. Although it’s now fixed, we’re still trying to understand exactly what’s happening on our network. It’s hard to do that when you can’t easily tell whether msv1_0.dll processed the request as a simple bind or an NTLM package.
All our 4624 logs processed by msv1_0.dll on the DCs are giving back the process "lsass.exe". I am sure that the majority are simple binds from UNIX type devices, when looking through the list of user based service accounts.
Thanks JerryDevore for writing these blogs. I am always looking forward for the next one!
MicrosoftHi Nonsaho - Thanks for keeping me honest and forcing me to dig deeper. Based on my sources the following senarios can result in a blank "authentication package" field.
If the logon is initiated by a local API call (e.g., LogonUser() or LsaLogonUser()), especially for service accounts or background tasks, the system may not populate the Authentication Package field. This is because the credentials are already available locally and no SSP is invoked
In Kerberos S4U or delegation scenarios, the system may impersonate a user without needing their credentials. These logons can result in Event 4624 entries with missing or blank fields, including the Authentication Package
Some logons are created purely for authorization checks (e.g., AuthzInitializeContextFromSid) and not for actual authentication. These may generate 4624 events with minimal data, including a blank Authentication Package
When services start under the LocalSystem or NetworkService accounts, the logon may not involve a traditional authentication package. This is especially true for Logon Type 5 (Service) or Logon Type 7 (Unlock)
Those activities could be using NTLM and associated with lsass.exe. I guess the best approach if there are 4624 with blank "Authentication Package" fields is to proceed with caution. I would not let it stop the hardening effort but you might want to disable NTLMv1 on those devices individually so you can quickly identity if the change caused an application to break.
Thank you JerryDevore for your response, very much appreciate it.
We've also seen some Negotiate as the Authentication Package in the Event 4624 but the Package Name (NTLM only) is also empty. How do we validate which authentication method (Kerberos or NTLM) was used? Can we also safely assume that it did not use NTLM but rather Kerberos? and if it was NTLM, how do we validate which version (v1 or v2) was used?
Looking forward to hearing back from you.
HiMa06RC ,
Based on MS documentation here is information regarding Negotiate. Hence in you case its not using NTLM.
Hi 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.
