The SDProp option provides the ability to report which accounts are protected by the SDProp\AdminSDHolder process. It will show which group or group inheritance has resulted in the user account being protected by the SDProp process and which accounts have been orphaned by the process. Some details on the process can be found here and here.
NetTools will display the user objects that have the AdminCount set to 1 and associated group memberships that triggered the user to be in scope for the process. The group membership of the account is shown horizontally, if the account is a member of multiple protected groups subsequent group memberships are shown on the next line, as is the case with the adm-test-ad user below. This option also provides the ability to reset user accounts, by enabling ACL inheritance and clearing the AdminCount attribute. To reset all accounts, select the Reset AdminCount & ACL Inheritance option and clicking Go or by using the Reset ACL & AdminCount option from the context menu to reset one or more selected accounts.
One of the features/issues with the SDProp process is when a user is removed from a protected group the SDProp process will not longer manage the permissions for the object. Also when an object fails out of scope the process doesn't re-enable permission inheritance or reset the original permissions on the object, and as such the object is classed as orphaned, and delegated permissions may not work. In the screenshot above it shows two users, user1 and user2. User1 is a member of Domain Admins and Administrators, and as such the account will have the AdminSDHolder permissions enforced when the SDProp process is run, User2 on the other hand is not a member of any protected groups and the AdminSDHolder permissions will no longer be applied and it is now an orphaned object.
Once the permission inheritance has been reset, it is possible to trigger the SDProp process to run by clicking on the SDProp button. This will query which domain controller holds the PDC role and send the runProtectAdminGroupTask command to that DC. Below is a LDAP Search favorite Update Query that is used to trigger the SDProp process, if run against the PDC of the domain, this uses the RunProtectAdminGroupsTask RootDSE Modify Operation. The details are here
[Trigger SDProp] Options=880098929149517 Server= BaseDN=NULL Filter=(objectclass=*) Attributes=RunProtectAdminGroupsTask==1 DisplayFilter= Filename= Sort= Authentication=1158 Separator=,
Connection Profiles: when using using a Connection Profiles with elevated rights, you may receive an 'The user has insufficient access rights' error when triggering the SDProp process. This is can be caused by the logic used to trigger the runProtectAdminGroupTask method. NetTools will query the AD to find the PDC of the domain and then connects to the FQDN of the PDC to execute the runProtectAdminGroupTask method, and when it connects it may not use the current connection profile and may execute the runProtectAdminGroupTask method using default permissions of the user that started NetTools. As workaround for this issue use one of the following methods:
- Use RunAs or start NetTools with a account that has the required permissions
- Create a new Connection Profile with a profile name set to the FQDN of the PDC of the domain, and specify the account with elevated rights