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 or group 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 background SDProp process can be found Protected Accounts and Groups in Active Directory and Five common questions about AdminSdHolder and SDProp.
NetTools will display the objects that have the AdminCount set to 1 and associated group memberships that triggered the object 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 administrator user shown below.
You also have the ability to reset a user accounts, by enabling ACL inheritance on the object and clearing the AdminCount attribute. To reset all accounts, select the Reset AdminCount & ACL Inheritance option before 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 object doesn't get inherit permission re-enabled or reset to the original permissions of 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.
The results will also highlight which objects are orphaned with an blue exclamation mark on the object icon. In the screenshot below it shows a number of orphaned objects. Pwdtest is a member of Administrators, and as such the account will have the AdminSDHolder permissions enforced when the SDProp process is run. Teena Lee on the other hand is no longer a member of a protected group, either directly or nested and the AdminSDHolder permissions will no longer be applied and it is now classed as an orphaned object and has the blue exclamation mark.
The SDProp button allows you to request that the SDProp process is triggered manually. 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 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