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 included 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 covered by the process. This option also provides the ability to reset user accounts, by enabling ACL inheritance and clearing the AdminCount attribute. To use this option, the Reset AdminCount & ACL Inheritance must be selected and then clicking Go again.
One of the issues with the SDProp process is once a user is removed from a protected group the SDProp process doesn't re-enable SD inheritance and as such the account is orphaned. In the screenshot above is shows two users user1 and user2, this shows that 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 is now orphaned.
While it's possible to reset the permissions, there is currently no option to trigger the SDProp Process, so the correct permissions will only be re-applied to the required user accounts when the SDProp next runs, which could be as long as 60 minutes. Below is a LDAP Search favorite Update Query that will trigger the SDProp process if run against the PDC of the domain using 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=,