Access problem and interesting Windows registry key
The purpose of this article is to tell about an interesting Windows registry key:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA \ CrashOnAuditFail
A couple of years ago, he gave me a few hours of intense troubleshooting of access problems to shared folders, and since neither then, nor now I see an explanation for this problem in the search, I decided to describe it. If you are wondering how it can happen that you and your colleague have access rights, but only one of you can access the shared folder, then welcome under the cat.
The situation was very simple and did not promise anything curious - we just started the transition to WIndows Server 2012 R2 and put a new server under the File Server and Pull Print solution from a third-party integrator. The problems started after a few days later, this server fell into a BSOD. Users began to complain that they could not access public folders and print to printer queues published from this server. The incident came to the stack of the server team with a rather incomprehensible history - someone from the Service Desk agents who checked the incident confirmed that he, too, did not have access to shared folders, someone said that there was access. A similar situation was observed with the printer queues. My access to both worked perfectly.
')
It should be noted here that since Pull Print was a solution from a third-party company, then by agreement with the customer, we supported the server itself, and for any problems with it, the integrator recommended a rebuild (there really was a very simple procedure and, together with the automated installation of the server , the recovery was very fast, and since the role was shared by several servers, it was easy to bring one of them to the rebuild). Therefore, after thinking about 10-15 minutes about why the server after BSOD can work so strangely, I reinstalled it. After the rebuild, everything naturally worked, but soon the server fell back to BSOD and the problem appeared again.
Now it has become clear that you will not get rid of the rebuild and you need to understand why this is happening. Tests showed that everyone in our team has access, but users do not. The hypothesis appeared immediately and, having checked it for those agents of the Service Desk, we made sure that only those who have local admin rights can access the shared folders. Looking for similar problems (limited access to shared resources) on the Internet, I did not find anything. But having looked with more general parameters, I found this curious registry key:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA \ CrashOnAuditFail
Here you can read about it. This key set to “1” translates restricts access to the system in the event of a Security Event Log overflow. That is, if your log is full and the server is down, then the key gets the value “2”, which the administrator must change manually, and before that, he will not let anyone except the administrator to the server.
Now everything became clear. In our previous builds, this key was not used and had the value "0". And in the new security team decided to put it in the "1". In addition, the Security Log settings on these servers, after installing the application, involved manual cleaning of events. Well, then, everything is clear - the log is full, the server crashes into the BSOD, it rises and only admins are allowed. Everything is as it should when using this key. The whole difficulty with finding the source of the problem was only with the fact that we approached it from an unexpected side - complaints about access to the shared folder and the printer queue.
I did not know about the existence of this key before I ran into this problem, but after reading about it in more detail, I found out that it can cause various problems. I hope the information outlined will help someone save time if they fall into this situation.
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA \ CrashOnAuditFail
A couple of years ago, he gave me a few hours of intense troubleshooting of access problems to shared folders, and since neither then, nor now I see an explanation for this problem in the search, I decided to describe it. If you are wondering how it can happen that you and your colleague have access rights, but only one of you can access the shared folder, then welcome under the cat.
The situation was very simple and did not promise anything curious - we just started the transition to WIndows Server 2012 R2 and put a new server under the File Server and Pull Print solution from a third-party integrator. The problems started after a few days later, this server fell into a BSOD. Users began to complain that they could not access public folders and print to printer queues published from this server. The incident came to the stack of the server team with a rather incomprehensible history - someone from the Service Desk agents who checked the incident confirmed that he, too, did not have access to shared folders, someone said that there was access. A similar situation was observed with the printer queues. My access to both worked perfectly.
')
It should be noted here that since Pull Print was a solution from a third-party company, then by agreement with the customer, we supported the server itself, and for any problems with it, the integrator recommended a rebuild (there really was a very simple procedure and, together with the automated installation of the server , the recovery was very fast, and since the role was shared by several servers, it was easy to bring one of them to the rebuild). Therefore, after thinking about 10-15 minutes about why the server after BSOD can work so strangely, I reinstalled it. After the rebuild, everything naturally worked, but soon the server fell back to BSOD and the problem appeared again.
Now it has become clear that you will not get rid of the rebuild and you need to understand why this is happening. Tests showed that everyone in our team has access, but users do not. The hypothesis appeared immediately and, having checked it for those agents of the Service Desk, we made sure that only those who have local admin rights can access the shared folders. Looking for similar problems (limited access to shared resources) on the Internet, I did not find anything. But having looked with more general parameters, I found this curious registry key:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA \ CrashOnAuditFail
Here you can read about it. This key set to “1” translates restricts access to the system in the event of a Security Event Log overflow. That is, if your log is full and the server is down, then the key gets the value “2”, which the administrator must change manually, and before that, he will not let anyone except the administrator to the server.
Now everything became clear. In our previous builds, this key was not used and had the value "0". And in the new security team decided to put it in the "1". In addition, the Security Log settings on these servers, after installing the application, involved manual cleaning of events. Well, then, everything is clear - the log is full, the server crashes into the BSOD, it rises and only admins are allowed. Everything is as it should when using this key. The whole difficulty with finding the source of the problem was only with the fact that we approached it from an unexpected side - complaints about access to the shared folder and the printer queue.
I did not know about the existence of this key before I ran into this problem, but after reading about it in more detail, I found out that it can cause various problems. I hope the information outlined will help someone save time if they fall into this situation.
Source: https://habr.com/ru/post/279711/
All Articles