Finding Stale SIDs on GPOs

One of my clients has a tool from Microsoft that scans the AD infrastructure and generates a report of items that can fixed/improved. One of the items on a recent report was stale SIDs on GPOs that could affect GPO processing. However, the tools didn't give us the stales SIDs. Just said we had them.

First, let's talk about what a stale SID is...

All Windows security is based on a Security Identifier (SID) that is unique for each user or group. In the Access Control List (ACL) for an resource, it is the SID that is assigned permissions, not the name of a user or group. The Windows tools just translate that SID back to a user or group name for use to manage them easier.

A stale SID occurs when a user or group has been assigned permissions to access a resource and the user or group is later deleted. There is no link back from the user or group to where the permissions have been assigned. So, Windows cannot go back and remove the SID from the ACL. The SID that's left behind without a matching user or group object is a stale SID. When you are using graphical tools to view permissions and it shows a SID instead of a user or group name, that's typically a stale SID.

NOTE: Just because a graphical tool is showing a SID does not 100% guaranteed that the SID is stale. It could be a user or group from a trusted domain that the tool is having trouble resolving. If you have trusted forests or domains, you should verify that SID is in your domain.

If there were only a few GPOs, it would be fairly fast to use the Group Policy Management Console to find the stale SIDs. However, this client had about 500 GPOs and manually verifying the permissions would have been quite painful.

To find the stale SIDs on GPOs, I wrote up a small script that scans the GPOs and finds any security permissions that are unknown:

 Import-Module GroupPolicy  
   
 $gpo = Get-GPO -All  
   
 Foreach ($g in $gpo) {  
   $permissions = $g.getsecurityinfo()  
   Foreach ($p in $permissions) {  
     If ($p.Trustee.SidType -eq "unknown") {  
       Write-Host "Policy with unknown SID: $($g.DisplayName)"  
       Write-Host "Trustee SID: $($p.Trustee.Sid)"  
     } #end if  
   } #end foreach permissions  
 } #end foreach gpo  
   
    

Here is what the script does:

• Loads the GroupPolicy module (required for Windows Server 2008 R2, Windows Server 2012 will do that automatically.
• Pulls all GPOs into the variable $gpo.
• Starts a foreach loop to process each gpo in $gpo.
• Pulls the permissions for the current GPO into the $permissions variable by suing the getsecurityinfo() function for gpo objects.
• Starts a foreach loop to process each permission in $permissions.
• Tests whether the SidType for the trustee in the permissions is unknown. An unknown SidType identifies a SID that couldn't be resolved to a user or group.
• The name of the gpo and the SID of the trustee are written to screen.

 This script writes output to screen, but you could easily modify it to dump the output to fine instead.

June 2016 Security Update Breaks Group Policy

So, this was a thing back in the middle of June and I missed it at the time. Looking back there are a few articles about it, but I just ran into this with a client (happily, before the update was applied) and I think it's worth raising awareness of.

In some security updates for Vista and later released on June 14, 2016 the process for Group Policy object (GPO) downloading has been changed. To make the download process more secure, the computer account is now responsible for downloading all GPOs. In the past, the user account could download the GPOs also.

The result of this change is that any computer that is downloading GPOs needs to have Read access to the GPO. The computer accounts do not need Apply permission, only Read is required.

By default the Authenticated Users group has Read and Apply permission for all GPOs. The Authenticated Users group includes all users and all computer accounts. So, if you haven't changed this, then you'll have no issues when these security updates are applied.

Even though you don't think you modified the permissions on your GPOs, you might have. If you use security filtering to control GPO application, that modifies the GPO permissions. When you remove Authenticated Users for security filtering, you also remove Read permission for Authenticated Users.

The quick fix is to add Authenticated Users or Domain Computers with Read permission to all of your GPOs. This doesn't modify which users or computers apply the GPOs, but it does give the computer accounts the necessary permissions to download the GPOs. Some of the links below show how to automate this process.

If you'd like to verify whether you have any GPOs without any permissions assigned to Authenticated Users, I've created a short script that looks for that and dumps the list of GPOs and their current permissions to a file.

 #Script Requires the GroupPolicy cmdlets  
 #A manual import of the GroupPolicy module is required for pre-Win2012  
   
 Import-Module GroupPolicy  
   
 #Define badGPO as an array or you get one big string  
 #that's hard to work with  
   
 $badGPO = @()  
   
 #Get a list of all Group Policy objects  
 $gpo = Get-GPO -All  
   
 #Find Group Policy objects that don't have permissions  
 #assigned to Authenticated Users  
    
 Foreach ($g in $gpo) {  
      Try { Get-GPPermissions -GUID $g.id -TargetName "Authenticated Users" -TargetType Group -ErrorAction Stop }  
      Catch { $BadGPO += $g.DisplayName }  
 }  
   
 Write-Host "List of GPOs without Authenticated Users permissions"  
 $badGPO  
   
 #Create File for Report  
 "Permissions Report of GPOs without Authenticated Users" | Out-File GPO-NoAuthUser.txt  
   
 Foreach ($b in $badGPO) {  
      "GPO: $b" | Out-File GPO-NoAuthUser.txt -NoClobber -Append  
      Get-GPPermissions -Name $b -All | Out-File GPO-NoAuthUser.txt -NoClobber -Append  
 }  
   
 Write-Host "Created GPO-NoAuthUser.txt with permissions report"  
 Write-Host "Use this report to verify that computer accounts"  
 Write-Host "have read access to the GPO for application after"  
 Write-Host "applying June 2016 Security Updates. For more info"  
 Write-Host "see: https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/"  

Some links with more information:

• Ask Premier Field Engineering (PFE) Platforms - Who Broke My User GPOs
• MS16-072: Security update for Group Policy: June 14, 2016
• PowerShell script to adjust permissions for Authenticated Users on Group Policy