Reset AD adminCount attribute and compare to currently protected accounts

The purpose of this script is to find out which domain users are currently not protected by the AdminSDHolder anymore, but were protected in the past. These accounts should be decommissioned.

 
 
 
 
 
5 Star
(1)
2,903 times
Add to favorites
Active Directory
3/3/2014
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • Error message from Get-ADUser wrong
    1 Posts | Last post November 22, 2015
    • When the script uses Get-ADUser to first retrieve users with adminCount=1, the error message "Unexpected error occurred while loading ActiveDirectory PowerShell module" seems wrong. The error may never be raised, but the description should mention Get-ADUser.
  • admincount not returning to 1 for protected group members
    4 Posts | Last post March 03, 2014
    • Hi,
      From what I understand in your article, the admincount value should change back to 1 for any account that is still a member of a protected group, however in the 2008 R2 environment that I am supporting after 2 days the vaue is remaining at 0.
      I have tried running the runProtectAdminGroupsTask using ldp.exe, but no change.
      What do I need to check if this is working?
    • Hi Rob,
      
      I am curious which (protected) group memberships the accounts have you are referring to? If it is Server Operatos, Backup Operators, etc. please check if the AdminSDHolder was configured to ignore them. 
      
      See the following article for further information and check the "dsHeuristic" part in it: http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx
      
      HTH,
      Fabian
    • Hi Fabian,
      
      Thanks for your quick reply. This is affecting all protected group members (Domain Admins, Enterprise Admins, etc...).
      
      Thanks also for the link to the AdminSDHolder article, I found it very informative.
      In my AD environment I have checked the "dSHeuristics" attribute of the "CN=Directory Service,CN=Windows 
      
      NT,CN=Services,CN=Configuration,DC=mydomain,DC=local" object, and it is <not set>
      
      On the positive side, I have confirmed on my own account (member of Domain Admins) that even though the adminCount value is 
      
      0, that if I modify my ACL in any way SDPROP still overwrites the ACL on my account ... AND that after doing this, the 
      
      adminCount value on my account changes to 1
      
      Further testing, I removed a user from Domain Admins (did not modify their ACL, so it was still matching to AdminSDHolder), waited 2 hours, added them back to Domain Admins, ran runProtectAdminGroupsTask:1 using ldp.exe ... waited 90 mins ... this users adminCount value remained at 0
      
      From this, I deduce that the SDPROP process in my AD environment only sets adminCount to 1 _only_ if it finds an acount that: a) is a member of a protected group, & b) does not have an ACL that matches AdminSDHolder (and therefore overwrites that ACL).
      
      So, for the sake of consistency I have run the following PS commands to set adminCount to 1 on all user accounts that are a member of a protected group:
      
      $AdminGroups = get-adgroup -LDAPFilter "(adminCount=1)"
      $AdminUsers = foreach ($group in $AdminGroups) {get-adgroupmember $group | where {$_.objectClass -eq "user"}}
      $AdminUsers | export-csv C:\Temp\adminusers2.csv
      
      $replaceAttributeHashTable_1 = New-Object HashTable
      $replaceAttributeHashTable_1.Add("adminCount","1")
      $domain = Get-ADDomain 
      $domainPdc = $domain.PDCEmulator 
      
      $AdminUsers |  ForEach {Set-ADUser $_ -Replace $replaceAttributeHashTable_1  -Server $domainPdc} 
    • Hi Rob,
      
      Holy Moly, nice catch!
      
      I am not sure how I could miss this during my tests. Thanks a lot for the hint! 
      
      A new version of the script is online now - it modifies the AdminSDHolder container ACL at the beginning and in the end of the procedure to make sure that the SDPROP process stamps the AdminSDHolder ACEs and the adminCount attribute correctly.
      
      Additonally you don't have to wait anymore - only a quick break of 1 minute during the action items left. Hopefully this is enough even for bigger environments. Change the "start-sleep" value according your needs (meaning: how long the SDPROP process runs in your environment).
      
      You might want to test the script in your lab - should work now as desired. :)
      
      Regards,
      Fabian