Symptoms:
The computer crashes and reboots for no apparent reason, and now users get an error message when trying to access any of the file or printer shares on the server/computer. This is related to a registry setting, the Security Event Log filling up, and a possible bug in 2008 R2 that doesn’t allow users to access the server even after the Security Event Log issue has been resolved.
Upon further inspection, the Windows Security Event Log is full and HKLMSYSTEMCurrentControlSetControlLsaCrashOnAuditFail = 1. You resolve this issue by right-clicking the Security event log, selecting properties, then doing one of the following:
- Increase the “Maximum log size”
- Allow the Security event log to “Overwrite events as needed (oldest events first)”
- “Archive the log when full, do not overwrite events”
This has solved the Security Event Log issue, but now users report they can no longer access \computername, or any of the shares or shared printers on that machine. You (a member of the administrators group on the machine), and other administrators on the machine can access shares and shared printers without a problem.
Regular users receive this error:
\computername is not accessible. You might not have permission to use this network resource. Contact the administrator oft his server to find out if you have access permissions.
Logon failure: user account restriction. Possible reasons are blank passwords not allowed, logon hour restrictions, or a policy restriction has been enforced.
Cause:
The Windows Security Event Log has filled up, causing the server to crash. This was caused by the following registry value:
HKLMSYSTEMCurrentControlSetControlLsaCrashOnAuditFail = 1
This could have been set by a security template, group policy, or manual registry change. In any case, the server crashed because it could no longer log audit-able events to the security log. Users can not access this server until this issue is resovled (see steps 1-3 above). But even after the Security log is happy again, users may still receive the “\computername is not accessible” error.
Resolution:
- Increase the “Maximum log size” to 1GB or more
- Allow the Security event log to “Overwrite events as needed (oldest events first)”
- Set HKLMSystemCurrentControlSetControlLsaLimitBlankPasswordUse = 0
- Reboot
- Set HKLMSystemCurrentControlSetControlLsaLimitBlankPasswordUse = 1
- Reboot
This took hours to figure out. Hopefully this post saves someone else some time.
Related Event Log IDs
<Event ID 4625>
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 4/30/2010 4:20:59 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: <computer where this event was logged>
Description:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: –
Account Domain: –
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: <username>
Account Domain: <domain>
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006e
Sub Status: 0x0
Process Information:
Caller Process ID: 0x0
Caller Process Name: –
Network Information:
Workstation Name: –
Source Network Address: <IP address of client>
Source Port: 3089
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: –
Package Name (NTLM only): –
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
– Transited services indicate which intermediate services have participated in this logon request.
– Package name indicates which sub-protocol was used among the NTLM protocols.
– Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
</Event ID 4625>
<Event ID 4776>
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 4/30/2010 4:20:55 PM
Event ID: 4776
Task Category: Credential Validation
Level: Information
Keywords: Audit Failure
User: N/A
Computer: <computer where this event was logged>
Description:
The computer attempted to validate the credentials for an account.
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: <username>
Source Workstation: <client computername>
Error Code: 0xc0000064
</Event ID 4776>
Hello Aaron
we had the exact same issue which we solved by reading your blog entry.
The resolution path we took was simply to disable crash on Audit Fail and the server did work again as expected.
I guess disabling crash on Audit Fail and instead enabling “Archive Log when full, do not overwrite events” ensures a propper security log trail.
The Log itself shouldn’t be larger than 128 MB in that case.
Thank you VERY much for this blog entry. Saved hours of digging in the dark
Best regards
Patrick