+ Reply to Thread
Results 1 to 11 of 11
  1. Senior Member Devilsbane's Avatar
    Join Date
    Apr 2010
    Posts
    4,203

    Certifications
    MCSE:Security, MCDST, A+, Network+, Security+, ITIL V3 Foundations, ITIL 2011 Intermediate: Service Transition, MOS 2007 (MCAS) BAS Computer Forensics
    #1

    Default 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?
    Reply With Quote Quote  

  2. SS -->
  3. Virtual Member undomiel's Avatar
    Join Date
    Sep 2007
    Location
    Bellevue, WA
    Posts
    2,813

    Certifications
    MCSA:2008, VCP4/5, CCA (XS), MCITP: EA/VA, MCSE, MCSA, Linux+, Security+, Server+, A+
    #2
    The account may be set to not inherit the OU's security settings.
    Reply With Quote Quote  

  4. Senior Member
    Join Date
    Oct 2005
    Posts
    1,030

    Certifications
    CCNP (R&S/Voice), CCDP, CCIP, VCP, NCDA, MCSE, CCNA Security
    #3
    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
    Reply With Quote Quote  

  5. Senior Member Devilsbane's Avatar
    Join Date
    Apr 2010
    Posts
    4,203

    Certifications
    MCSE:Security, MCDST, A+, Network+, Security+, ITIL V3 Foundations, ITIL 2011 Intermediate: Service Transition, MOS 2007 (MCAS) BAS Computer Forensics
    #4
    Quote Originally Posted by kalebksp View Post
    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.
    Last edited by Devilsbane; 02-09-2011 at 04:13 PM.
    Reply With Quote Quote  

  6. Nidhoggr, the Net Serpent Claymoore's Avatar
    Join Date
    Nov 2007
    Location
    FL
    Posts
    1,622

    Certifications
    AWS Architect, MCSEx3, MCITPx6, MCTSx17
    #5
    Quote Originally Posted by Devilsbane View Post
    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.
    Reply With Quote Quote  

  7. Senior Member
    Join Date
    Oct 2005
    Posts
    1,030

    Certifications
    CCNP (R&S/Voice), CCDP, CCIP, VCP, NCDA, MCSE, CCNA Security
    #6
    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.
    Reply With Quote Quote  

  8. Senior Member Devilsbane's Avatar
    Join Date
    Apr 2010
    Posts
    4,203

    Certifications
    MCSE:Security, MCDST, A+, Network+, Security+, ITIL V3 Foundations, ITIL 2011 Intermediate: Service Transition, MOS 2007 (MCAS) BAS Computer Forensics
    #7
    Quote Originally Posted by Claymoore View Post
    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.
    Reply With Quote Quote  

  9. Senior Member Devilsbane's Avatar
    Join Date
    Apr 2010
    Posts
    4,203

    Certifications
    MCSE:Security, MCDST, A+, Network+, Security+, ITIL V3 Foundations, ITIL 2011 Intermediate: Service Transition, MOS 2007 (MCAS) BAS Computer Forensics
    #8
    Quote Originally Posted by kalebksp View Post
    what version of server holds the pdc emulator role? You may not have to install the hotfix.
    2003 sp2
    Reply With Quote Quote  

  10. Senior Member
    Join Date
    Oct 2005
    Posts
    1,030

    Certifications
    CCNP (R&S/Voice), CCDP, CCIP, VCP, NCDA, MCSE, CCNA Security
    #9
    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.
    Reply With Quote Quote  

  11. Senior Member Devilsbane's Avatar
    Join Date
    Apr 2010
    Posts
    4,203

    Certifications
    MCSE:Security, MCDST, A+, Network+, Security+, ITIL V3 Foundations, ITIL 2011 Intermediate: Service Transition, MOS 2007 (MCAS) BAS Computer Forensics
    #10
    Quote Originally Posted by kalebksp View Post
    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.
    Reply With Quote Quote  

  12. Senior Member
    Join Date
    Oct 2005
    Posts
    1,030

    Certifications
    CCNP (R&S/Voice), CCDP, CCIP, VCP, NCDA, MCSE, CCNA Security
    #11
    Quote Originally Posted by Devilsbane View Post
    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.

    Quote Originally Posted by Devilsbane View Post
    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.
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks