Windows account lockouts

[ultimatebob]

I'm having a problem with Windows 2000 Server where all of the accounts are being locked out by various password guessing worms spreading over the LAN, EXCEPT for the administrator account. For some odd reason, the administrator account cannot be locked out, regardless of what the Local Security Policy is set for.

What I'm trying to figure out is what makes the Administrator account different from other accounts with admin access, and how I can modify other accounts to act in a simular manner to Administrator. This server has a critical service running on it that cannot run as the Administrator ID, but tends to crash whenever the account that it is running under gets locked out. It's probably not the best solution, but I'd like to set that account a REALLY tough password and also set it ignore the Local Security Policy and never get locked out like all of the other accounts would.

Does anyone have any ideas? I haven't found anything in the MS Knowledge Bases, but I'd imagine that there is a registry setting or something that can force another account to act just like Administrator.

 

[bsobel]

I don't know of a solution for you, but I know the reason the 'real' administrator acts differently. It's so there is no chance of you actually getting fully locked out of the box (otherwise it would be trivial for one to mount a DOS attack against the box).

Why do you ahve worms on your LAN? Is this a corporate network?

Bill

 

[ultimatebob]

Yes, this server is on a corporate network... one filled with brain-dead users who have a bad habit of clicking on every bogus e-mail attachment that they receive

The application that the server is running also needs file and print sharing, which is how all the accounts are getting locked out to begin with.

 

[KB]

The Administrator account has a special SID (security identifier) value. This value sticks with the account even if you rename it. Since you cannot re-assign a SID, you can't make another account like the Administrator (which is why you can't delete it). It is the special SID that keeps it from being locked out.

 

[TGHI]

You can set up what's called 'power users' locally or on the domain, but no one can actually have as much control as the administrator (and that's the point).

 

[stash]

The Administrator account has a special SID (security identifier) value. This value sticks with the account even if you rename it.

Yes, the Admin SID is the same on every single Windows machine and domain. But ALL accounts have a SID that doesn't change if you rename the human friendly account name.

In 2000, the no-lockout is controlled by a registry value in HKLM\SAM\SAM\Domains\Account, that cannot be edited through the registry. I think it is different in 2003/XP, but I'm not sure.

There is a resource kit tool from NT called passprop that you could use to disable the no-lockout of the admin account. You should be very careful in using this tool. Locking out the administrator account is not a good thing.

 

[ultimatebob]

Originally posted by: STaSh

The Administrator account has a special SID (security identifier) value. This value sticks with the account even if you rename it.

Yes, the Admin SID is the same on every single Windows machine and domain. But ALL accounts have a SID that doesn't change if you rename the human friendly account name.

In 2000, the no-lockout is controlled by a registry value in HKLM\SAM\SAM\Domains\Account, that cannot be edited through the registry. I think it is different in 2003/XP, but I'm not sure.

There is a resource kit tool from NT called passprop that you could use to disable the no-lockout of the admin account. You should be very careful in using this tool. Locking out the administrator account is not a good thing.

OK... I noticed that I can edit the permissions of the SAM registry keys with regedt32, and I now have access to the keys in the SAM folder. The account settings are a bunch of long Hex values, though.... I wouldn't even dream of changing them without reading some documentation on how they work.

 

[stash]

Yeah you would need to use passprop to make any changes.

 

[Smilin]

And then you still shouldn't. Don't fool with the SAM database. You'll end up with a machine you can't login to and you'll be done. If you want, you can make other accounts lockout proof simply by changing your lockout policy for the domain. This would obviously be a stupid thing to do as is this entire direction of troubleshooting.

You are trying to cure the symptom, not the disease. You've got some good old administrator work to do and there is no ducking it.

Go kick in your auditing, find out where the account lockouts are coming from and put a stop to it. If you've got a virus/worm circulating then get some AV software in place. If you have lockouts coming from external sources, get a firewall in place.

If you keep dodging this work to be done you will eventually get a break in on your hands at one of the DCs. Game over. You willl never again secure your network without rebuilding ALL of it.

 

[Nothinman]

Disable/Rename the Administrator account and create yourself a new admin account so that noone actually gets in. Then either change the policy to not lock out the 'normal' accounts or do what Smilin said and fix the real problem.

 

[ultimatebob]

Originally posted by: Smilin
And then you still shouldn't. Don't fool with the SAM database. You'll end up with a machine you can't login to and you'll be done. If you want, you can make other accounts lockout proof simply by changing your lockout policy for the domain. This would obviously be a stupid thing to do as is this entire direction of troubleshooting.

You are trying to cure the symptom, not the disease. You've got some good old administrator work to do and there is no ducking it.

Go kick in your auditing, find out where the account lockouts are coming from and put a stop to it. If you've got a virus/worm circulating then get some AV software in place. If you have lockouts coming from external sources, get a firewall in place.

If you keep dodging this work to be done you will eventually get a break in on your hands at one of the DCs. Game over. You willl never again secure your network without rebuilding ALL of it.

The auditing is on... so I know what machine(s) they're coming from. Not that it really matters... by the time I get the network guys to shut off their port of the infected users system, they're already locked out most of the accounts on the entire network.

I don't really see a good solution to this, other than disabling file and print sharing OR firing all the stupid users who keep letting their systems get infected with these worms. Neither one is practical, unfortunately.

 

[Smilin]

Originally posted by: ultimatebob

The auditing is on... so I know what machine(s) they're coming from. Not that it really matters... by the time I get the network guys to shut off their port of the infected users system, they're already locked out most of the accounts on the entire network.

I don't really see a good solution to this, other than disabling file and print sharing OR firing all the stupid users who keep letting their systems get infected with these worms. Neither one is practical, unfortunately.

If you have a particular node on your network that is infected you'll need to isolate it, clean it, client firewall that node, patch it's OS and software, enable some antivirus, and remove administrative access from it's users. You should be able to prevent a node from getting reinfected once you have cleaned it, otherwise you're forgetting something.

What virus/worm are you dealing with anyway? You didn't say.

It is likely you will need to get this done on every machine inside your corporate firewall. No one is saying it's easy. But, you can't very well just give up and let a virus/worm run amok on your network. Unless of course your resume is well polished. Be sure to take the "slow" network guys with you if you get fired. They have responsibility in this as well.

 

[djheater]

So far as I know there is no 'sanctioned' way to stop this.. The best you can do is rename the admin account name to something ridiculous like kTHnca6_EDX49od0

 

[bsobel]

Originally posted by: djheater
So far as I know there is no 'sanctioned' way to stop this.. The best you can do is rename the admin account name to something ridiculous like kTHnca6_EDX49od0

Did you read the question?
Bill