none
AdminSDHolder itself has inheritable?

    Question

  • Greetings,

    I understand that the permissions on AdminSDholder are applied to all objects that have admincount=1 (protected) on a regular basis.

    When I looked at the adminsdholder container in our AD, the container itself allows inheritable permissions and Im thinking that is not a good idea as we have a large number of permissions assigned at the domain level which really shouldnt apply to protected objects.

    For example, we have a group, membership of which allows you to modify membership of all AD groups. As this applies to adminsdholder it means that protected objects also have this permission. So even though SDProp removes inheritance from protected objects, they still get 'inherited' permissions as the adminsdholder container inherits them.

    Is it normal for the adminsdholder object to allow inheritable permissions or has someone turned this on manually?

    Thanks

    David Z

    Thursday, March 16, 2017 9:34 PM

Answers

  • First, objects protected by the SDProp process will have the adminCount attribute set to 1, but when objects are removed from all protected groups, the adminCount attribute is no updated. So just because adminCount is 1 does not mean the object is protected. It could be orphaned. I describe the situation in this Wiki:

    https://social.technet.microsoft.com/wiki/contents/articles/33307.active-directory-find-orphaned-objects.aspx

    In that article I also state:

    ======== quote ===========

    The AdminSDHolder object is in the cn=System container of the domain. The permissions assigned to this object will be applied to all protected objects in the domain by the SDProp process. By default this includes disabling the inheritance of permissions from any parent organizational units. Although it is generally not recommended, an administrator can modify the default permissions assigned to this object.

    ======= end of quote ========

    So, no, it is not normal to allow inheritable permissions. And it is certainly not recommended, as it defeats the purpose of the AdminSDHolder object.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    • Marked as answer by David Zemdegs Thursday, March 16, 2017 10:06 PM
    Thursday, March 16, 2017 9:51 PM

All replies

  • First, objects protected by the SDProp process will have the adminCount attribute set to 1, but when objects are removed from all protected groups, the adminCount attribute is no updated. So just because adminCount is 1 does not mean the object is protected. It could be orphaned. I describe the situation in this Wiki:

    https://social.technet.microsoft.com/wiki/contents/articles/33307.active-directory-find-orphaned-objects.aspx

    In that article I also state:

    ======== quote ===========

    The AdminSDHolder object is in the cn=System container of the domain. The permissions assigned to this object will be applied to all protected objects in the domain by the SDProp process. By default this includes disabling the inheritance of permissions from any parent organizational units. Although it is generally not recommended, an administrator can modify the default permissions assigned to this object.

    ======= end of quote ========

    So, no, it is not normal to allow inheritable permissions. And it is certainly not recommended, as it defeats the purpose of the AdminSDHolder object.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    • Marked as answer by David Zemdegs Thursday, March 16, 2017 10:06 PM
    Thursday, March 16, 2017 9:51 PM
  • That's what I thought.

    Wonder why someone would do that?

    Thursday, March 16, 2017 10:07 PM