Problem resetting a password

So we have a bunch of users located in an OU, and I have an account that was delegated to reset passwords for this OU. How come there is an account in there that I don't have access to?
All I can come up with is that it is in the server operators group, but I've never heard of that being a problem.
Any ideas?
All I can come up with is that it is in the server operators group, but I've never heard of that being a problem.
Any ideas?
Decide what to be and go be it.
Comments
AdminSDHolder, Protected Groups and SDPROP
I'm pretty sure you are spot on here. I read the article and then started looking into it. And the security on that specific user is different than the OU, because it has Inheritance disabled. I checked out other users in the same group compared to other standard user in the OU and that confirmed it.
First of all this seems a little silly to me. I don't understand why Microsoft would put this little back door in. Yes, extra measures should be taken to protect those accounts, but that should be up to the administrator and I'm personally not a fan of how Microsoft handled that.
Anyway rant over. The way I see it, there are 2 ways past this. The hotflix which could potentially break other things, which allows you to update the flag. Or you could modify the permissions of the AdminSDHolder object? But doing that would probably mess up permissions on Domain Admin and other heavily restriced accounts that are located in a separate OU.
Actually, they took a little back door out. It makes perfect sense that someone with lower security rights - you, the delegated account - should not be able to change the password of someone with greater security access - the account in Server Operators (or Domain Admins). Otherwise you could reset passwords and gain access to those accounts and their elevated privileges. I bet if your account were in the server operators group you could change the password. Could be worth a little lab time if you are curious.
What version of server holds the PDC emulator role? You may not have to install the hotfix.
That is an interesting question, I think I will put it on my list of things to do when I have time.
I see your side of it too, but someone has given me rights to this OU. If they don't want me hijacking a Domain Admin account, then the should place it elsewhere. I'm not a fan of Microsoft covering the @$$ of a lazy admin who didn't think about that.
A compromise to this scenario would be if there was something similar to the MBSA that ran a scan and then notified you of potential problems rather than just changing permissions. Plus I question how much CPU is being used by the PDC to run a scan on every account in one of these groups every hour.
Thanks for your input.
2003 sp2
If you don't want to make directory wide changes you could always give your account permissions directly on the affected user objects, but I try to avoid setting permissions at that level.
Where did you read that? I saw where it says make sure you have the most up to date service pack, but I didn't see where it said what that was.
Would that really work? Wouldn't the scan go through and still see that the permissions on that object are different than they should be an update them? Plus I'm not a fan of changing individual permissions on 25+ accounts. I'd likely spend more time updating permissions then would ever be spent chasing someone with a domain admin account down.
It says that it's included in the most recent service pack for Windows Server 2003, SP2 is the most recent.
I was thinking that it just disabled inheritance, but you're right it actually replaces the ACL.