The SDProp option in NetTools provides the ability to report on which accounts are protected by the SDProp\AdminSDHolder process. It also shows which protected group the user is a member of and caused the user permissions to be changed 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 SDProp 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.
Orphaned Objects
One of the features/issues with the SDProp process is when a user or group is removed from a protected group the SDProp process will no longer update the permissions on the object. This is compounded by the fact 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 now classed as orphaned. This will 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 or reset their 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 changes to 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
Recursive Groups
The SDProp test monitors for recursive groups, the test itself uses a simple logic to detect infinite loops, it will chase nested group to a maximum of 100 nested groups, at which point it will display a max depth error and move on to the next account. However, as it doesn't check if a group recursive has been seen before, it can display nested groups multiple times before it reaches the 100 maximum depth.