Logon failure: user account restriction -- WTF??? 1

[backlund]

OK, here goes...
We have a windows 2003 server that was working fine until some genius crashed it the other day. I'm not sure what they were doing when it crashed. Ever since this has happened we have this sparatic problem of accessing the server from the domain.

The clients appear to logon without an issue, but some times we cannot access the main server. When you browse through the network places you can access every single computer on the network except the server. When accesing the server you get the error "Logon failure: user account restriction".

Nothing was changed policy or permissions wise. As far as I can tell, everything looks normal. Now, here's where it gets REALLY wierd. If I'm on the client that can't access the server, and I reboot it a few times, suddenly everything will work. If I reboot a few more times again it will quit working. There really seems to be no structure to this problem. Sometimes you reboot once and it comes or goes, other times it takes 5 reboots to make to problem appear or disappear. One client ran 2 days without issue, and suddenly couldn't access anything again after I rebooted.

Now, here's the full meal deal: This is a server for one of our clients. The client has an in house person who CLAIMS to know I.T. I can't vouch one way or another for the person. I do know that they have been screwing around in the registry because every time I go to the server, it's the last thing typed in the RUN command. This genius has also managed to install a bunch of spyware on the server as well, since they use it to browse the web from time to time. We are running terminal services on the machine. The main user accounts are locked down policy-wise to keep them from being able to mess with anything, so I know the users didn't do it. I realized there was a spyware issue when one of the users asked me why they suddenly have a "mysearch.com" bar on IE. The supposed in house I.T. person is the only one with an administrative access account, so they are the only ones who could have installed that garbage. I ran ad aware to remove most of it, but I get a little worried doing this on a server. I've used ad aware on xp machines before, and it usually works pretty well, but occasionally you have that machine that just dies after removing stuff.

Anyway, I can't figure out what is causing the "Logon failure: user account restriction" error. My only guesses are Active directory, NTFS, or DNS corruption. I'm leaning towards DNS, because we had a backup DC at another location, and after the PDC crashed, all users were logging into the backup, even after the primary was restored. It was causing so much problems that we took the backup off line to see if it would fix the problem (which it didn't). We have decided to leave the backup offline until we get this mess sorted out. HELP!!

 

[wdoellefeld]

The username and password sound like they get accepted. He's somehow put a restriction on everyone and it sounds domain wide. Any new GPOs or a change in the default GPO? How about the log on locally permissions, are they correct?

Does this person normally play with user accounts at all? It could be tied to the hours that the account is permitted to log on.

What does the security log on the server show? It should help you pinpoint a little (you would hope!)

On a side note.. this must really suck for you, sorry man.



FRCP

http://www.frcp.net

 

[Jpoandl]

I would examine the Event View for errors especially in the System log. Do this both on the server and the problematic clients.

The strange thing is that sometimes users have no problem accessing the server and sometimes they can't. I would almost be tempted to remove the server from the domain and then to re-join it. (You may also want to try that on a client machine).

Joseph L. Poandl
MCSE 2003

If your company is in need of experts to examine technical problems/solutions, please contact

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)

 

[backlund]

Jpoandl-
I did try removing one of the clients and adding it back on to the domain. I even changed the computer name, in hopes of the SID changing. No dice. It worked for about 45 minutes and then the problem showed up again. This is driving me up a wall.

Worst yet, I've looked at the event viewer and there isn't anything helpful going on in there. No major errors that would be related to the problem. The only error I see coming up a lot is for Veritas because the "genius" decided to rename the administrator account on the server. Veritas couldn't load into its profile when starting which was making it error.

 

[MoobyCow]

First thing I would do is enable verbose logging, there could be an error that becomes obvious.

http://www.winnetmag.com/articles/index.cfm?articleid=38325

Scroll to the bottom of the article for the how to. Even when you fail to logon at all there should be some events logged that you can sort through. It's helped me out of a couple of different logon problems.

The log file, userenv.log, will be written into the %windir%\debug folder. This folder is a hidden folder.

 

[backlund]

Ok, we did figure one thing out this morning. This was never an issue before, but now it's the only way to make things work. Before, everyone was logged in as a standard domain user. After everything quit working, someone added administrative rights to all the users to work around the problem. We still have the issue of sparatic connections to the share drives, but now we have the added issue of not being able to connect unless you are an administrator as well! LAME!

 

[Stevehewitt]

In a normal domain situation, you apply policies to organisational units(OU) (like folders). Whatever you put under those OU's will apply the policy.

domain.com
|_OU1
| |_User1
| |_Computer1
|
|_OU2
|_User2
|_Computer2

If I put a policy on OU1 it will not affect user 2.

On a local PC, you do not have this level of control. Instead you can only apply one policy. The local group policy. Whatever you apply to this machine will be affective to all users, regardless of their permisions.

If you are part of a domain, you can setup that the admins are in a different OU to the users, so you have different policies.

Because this control is avaliable on a local PC, instead if you lockdown the run box and cmd prompt you will not be able to run either, regardless of admin rights.

I wouldn't advise this!!!

You could get around it by creating a mmc to the group policy editor and saving it somewhere. Only admins can access the GPEDIT.MSC console so in theory you can lock down everything (within reason) and leave the GPEDIT.MSC link on the desktop or root of C: or the admins 'My Docuemnts' and when you need to change something on the policy fire it up.

Be careful not to lock yourself out of the computer!

I know its adviseable to backup your docs before installing stuff etc. (yeah, like that happens all the time! ;-)) but I strongly recommend doing it before playing with local group policies as a few wrong clicks can leave your computer useless!

Good Luck,

Steve.

 

[backlund]

SOLVED!!! Here we go guys! After extensive searching and pulling my hair out, I finally found the root of the evil in this server. I'm not 100% if it was causing the sparatic behavior, but here goes. When the server crashed, it had something to do with the security log being full in the event viewer. Basically, MS has put this awesome feature in there that gives you some completely unrelated cryptic errors for your users when they try to log on and has absolutely zero notification to the administrators of the issue, which only they can fix. That's right. MS really blows some times.

Basically, theres a fault protection in the security event viewer that when it is full and cannot add more entries, the system will halt. Yep, you heard me. It halts the system. Once this halt has happened a registry key will change and only allow Administrators to enter the system to clear the key, and the event log. This would be why the users on the server couldn't log in, and were receiving the access denied errors on the mapped drives to the server shares. I think things were happening sparatically, because we had a backup DC in another branch office of this business that the users were authenticating to. Either that, or they were logging on with locally cached credentials or something. Either way, the shares were on the server that crashed, so that makes sense why you wouldn't be able to access them when logging on to the other server.

So, I cleared the key, rebooted the server and now all works like a charm. Everyone can login, no more share problems, everything is back to normal. I don't understand why there is no error for something like this. You would think that if the system is going to deny access to all users except admins, it should at least pop up a message for system admins that explains this stuff. The funny thing about this mess is that the error we would receive when trying to connect to shares would have a part that actually says "Possible reasons include blank passwords, logon hour restrictions, or a policy restriction." Yet, none of these were the reason why the error was showing up. #*(@&*! Microsoft. Would it really be that hard to say "Your server event log is full. Please contact your system administrator to clear the logs and reset the registry key pertaining to this error." Guess so.

For those with the same problem, here's how to fix:

*open regedit

*browse to HKLM\SYSTEM\CurrentControlSet\Control\Lsa

*find the CrashOnAuditFail key

*check the value. If the value is 2, this is the root of your problem, as this is the key that gets changed and only allows admins in. If the value of your key is 1 or 0, you have other issues.

*Change the value from 2 to either 1 or 0. 0 turns off the feature that halts the system if the event log is full and allows your users to enter the system again (which we chose to set it to so we don't have this problem again). A value of 1 will keep the feature on, but also allow all usere to login again.

*Save and reboot. Users should now be able to login without admin access and all shares should be accessible.

*pray to god. buddha. golden cows. whatever. tomorrow will bring a new onslaught of BS! ;-)