How to Update HKLM-SYSTEM permissions without removing "S-1-15-3-1024-...." from the ACL

I resorted to using Powershell to sort through our issue. Hopefully pasting the logic here maintains the formatting. I do not see a way to add it into a script-block. This script will only modify the Current Owner scope from "This key and Subkeys" to "Subkeys Only" - as required by DISA STIG.

#####################################################################

##Server 2022 HKLM/System Registry Permissions Fix for Current Owner for STIG

#####################################################################

# Define the SID for Creator Owner

$sidCreatorOwner = New-Object System.Security.Principal.SecurityIdentifier("S-1-3-0")

# Define the registry rights for Subkeys Only

$permissionsSubkeysOnly = System.Security.AccessControl.RegistryRights::CreateLink -bor `

# Create an access rule for Creator Owner with Subkeys Only permissions

$ruleCreatorOwner = New-Object System.Security.AccessControl.RegistryAccessRule($sidCreatorOwner, $permissionsSubkeysOnly, "None", "None", "Allow")

# Get the current ACL

$acl = Get-Acl -Path "HKLM:\System"

# Remove existing Creator Owner rules (if any)

$acl.Access | Where-Object { $_.IdentityReference -eq $sidCreatorOwner } | ForEach-Object {

    $acl.RemoveAccessRule($_)

}

# Add the new Creator Owner access rule for Subkeys Only

$acl.AddAccessRule($ruleCreatorOwner)

# Apply the modified security descriptor to the registry key

Set-Acl -Path "HKLM:\System" -AclObject $acl

If you attempted to use GPO and removed the SID from the ACL, you will have trouble adding it back and having a clean STIG scan. I used the below logic to re-add the SID and set the appropriate permissions.

###########################################################

##Server 2022 HKLM/System Registry Permissions Fix for SID

###########################################################

# Define the SID you want to add

$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681")

# Define the registry rights for 'Read' permission

$permissions = System.Security.AccessControl.RegistryRights::ReadKey -bor `

# Get the current ACL for HKLM\System

$acl = Get-Acl -Path "HKLM:\System"

# Create a new access rule for the SID and 'Read' permission

$rule = New-Object System.Security.AccessControl.RegistryAccessRule($sid, $permissions, "ContainerInherit, ObjectInherit", "None", "Allow")

# Add the access rule to the security descriptor

$acl.AddAccessRule($rule)

# Set the "Applies to" field to "this key and subkeys"

$acl.SetAccessRuleProtection($true, $false)  # Protect the key, not the subkeys

# Apply the modified security descriptor to the registry key

Set-Acl -Path "HKLM:\System" -AclObject $acl

I believe that SID is related to Edge and personalized advertising. Have you checked the data in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities for the SID? If it is not there, can you add it and see if that will allow you to manage it?

I'm running into both issues (sort of), but in response to this question for me, yes that SID is in MY AllCachedCapabilities, but the only way I was able to add it back, after accidentally removing it, was after booting from a DaRT disk.

And I'm having the opposite problem with Creator Owner permissions for SYSTEM & SOFTWARE. I need it to be 'this key and subkeys', but it's 'Subkeys only', and will not stay changed when attempts are made. Wondering if this too will need the DaRT boot method.

I believe that SID is related to Edge and personalized advertising. Have you checked the data in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities for the SID? If it is not there, can you add it and see if that will allow you to manage it?

Thanks Techfreak for the response.

Unfortunately, the issue isn't the CREATOR OWNER - permissions that is the issue, this can be modified easily as expected through Regedit (or the Group Policy Add key--as that GP process IS essentially opening regedit to configure)

The issue is you cannot ADD

S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681

in the security DB

It's an unknown account as far as the OS is concerned

But it IS something , as per the STIG

Microsoft has also given Read permission to the SOFTWARE and SYSTEM registry keys in Windows Server 2022 to the following SID.
S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681

But the object/ Security principal cannot be found when you search

I.e.

Even when you:

Check off all of the Object Type options: Other Objects, Built-In Security Principals, Groups, Users

or

Try all locations: The Domain FQDN, Enter Domain, or the Server Hostname

So I am trying to find out how Microsoft gave Read permission to the SOFTWARE and SYSTEM, or how to modify the HKLM\SYSTEM CREATOR OWNER - permissions, without removing the Mystery principal

The odd thing is WIN2016/WIN2019 both have HKEY_LOCAL_MACHINE\SYSTEM -CREATOR OWNER - Full Control - 'Subkeys only'

and pass the Nessus scan

For some reason in MS wisdom, they set WIN2022 to HKEY_LOCAL_MACHINE\SYSTEM -CREATOR OWNER - Full Control - 'this key and subkeys' , which makes all my WIN2022 fail

Is there any reason you cannot use the registry editor on each server and apply the creator owner changes to the SYSTEM permissions to be compliant with the STIG?