The SDProp option in NetTools provides the ability to report on which accounts are protected by the SDProp\AdminSDHolder process. It will also show which group or group inheritance has resulted in the user account being protected by the SDProp process. The report will also show which accounts have been orphaned, as they are no longer a member of a protected group. Some more details on the SDProp 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 shown below. You also have the ability to reset a 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 no longer enforce the permissions on the object. A side effect of a user or group dropping out of scope the process, is that the user or group doesn't get inheritanced permission re-enabled or reset the original permissions on the object, and as such the object is classed as orphaned. This can result in the delegated permissions not being applied to the object, this is normal seen as the service desk not being able to manage the user password.
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 no longer a member of a protected group and the AdminSDHolder permissions will no longer be applied and it is now classed as an orphaned object.
The SDProp button allows you to request that the SDProp process is triggered manaully. 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, 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