Problem resetting a password

Devilsbane

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?

undomiel

The account may be set to not inherit the OU's security settings.

kalebksp

Server Operators is a protected group, members of a protected group will periodically have inherited permissions removed from their account as part of the AdminSDHolder process. It is common to run into this when upgrading to Exchange 2010 and ActiveSync starts failing for members of protected groups (that's how I learned about it). More details and methods of avoiding the problem are in the link below.

AdminSDHolder, Protected Groups and SDPROP

Devilsbane

kalebksp wrote: »

Server Operators is a protected group, members of a protected group will periodically have inherited permissions removed from their account as part of the AdminSDHolder process. It is common to run into this when upgrading to Exchange 2010 and ActiveSync starts failing for members of protected groups (that's how I learned about it). More details and methods of avoiding the problem are in the link below.

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.

Claymoore

Devilsbane wrote: »

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.

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.

kalebksp

This ability to control groups that are protected by AdminSDHolder was introduced via hotfix for the RTM versions of Windows 2000 Server and Windows Server 2003 and is included in the most recent service pack for Windows Server 2003 and in the RTM versions of Windows Server 2008 and Windows Server 2008 R2.

What version of server holds the PDC emulator role? You may not have to install the hotfix.

Devilsbane

Claymoore wrote: »

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.

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.

Devilsbane

kalebksp wrote: »

what version of server holds the pdc emulator role? You may not have to install the hotfix.

2003 sp2

kalebksp

You shouldn't have to install that hotfix if you're running '03 SP2. You will have to modify the dsHeuristic attribute to exclude the necessary groups and enable inheritance on the users that were previously affected.

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.

Devilsbane

kalebksp wrote: »

You shouldn't have to install that hotfix if you're running '03 SP2. You will have to modify the dsHeuristic attribute to exclude the necessary groups and enable inheritance on the users that were previously affected.

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.

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.

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.

kalebksp

Devilsbane wrote: »

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.

It says that it's included in the most recent service pack for Windows Server 2003, SP2 is the most recent.

Devilsbane wrote: »

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.

I was thinking that it just disabled inheritance, but you're right it actually replaces the ACL.