Problem resetting a password

DevilsbaneDevilsbane Posts: 4,212Member
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?
Decide what to be and go be it.

Comments

  • undomielundomiel Posts: 2,818Member
    The account may be set to not inherit the OU's security settings.
    Jumping on the IT blogging band wagon -- http://www.jefferyland.com/
  • kalebkspkalebksp Posts: 1,033Member
    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
    Contradictions do not exist. Whenever you think you are facing a contradiction, check your premises. You will find that one of them is wrong.
    -Ayn Rand

    vCabbage
  • DevilsbaneDevilsbane Posts: 4,212Member
    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.
    Decide what to be and go be it.
  • ClaymooreClaymoore Posts: 1,637Member
    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.
  • kalebkspkalebksp Posts: 1,033Member
    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.
    Contradictions do not exist. Whenever you think you are facing a contradiction, check your premises. You will find that one of them is wrong.
    -Ayn Rand

    vCabbage
  • DevilsbaneDevilsbane Posts: 4,212Member
    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.
    Decide what to be and go be it.
  • DevilsbaneDevilsbane Posts: 4,212Member
    kalebksp wrote: »
    what version of server holds the pdc emulator role? You may not have to install the hotfix.

    2003 sp2
    Decide what to be and go be it.
  • kalebkspkalebksp Posts: 1,033Member
    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.
    Contradictions do not exist. Whenever you think you are facing a contradiction, check your premises. You will find that one of them is wrong.
    -Ayn Rand

    vCabbage
  • DevilsbaneDevilsbane Posts: 4,212Member
    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.
    Decide what to be and go be it.
  • kalebkspkalebksp Posts: 1,033Member
    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.
    Contradictions do not exist. Whenever you think you are facing a contradiction, check your premises. You will find that one of them is wrong.
    -Ayn Rand

    vCabbage
Sign In or Register to comment.