Winning GPO information can help identify conflicts for key settings

[olamotte-roche]

Hello Mick,

Copying over from scipag/HardeningKitty#21 as requested ;)
As mentioned we've made use of RSOP* CIM classes to audit key settings.
I have looked at the list of URA we want to audit at scale and had come up with the following code sample for it. In this case, the effectiveness of AD Tiering GPOs, and control of other sensitive privileges in an environment.

#User Right Assignment of interest
$URA=@('SeDenyServiceLogonRight',
    'SeDenyBatchLogonRight',
    'SeDenyNetworkLogonRight',
    'SeDenyInteractiveLogonRight',
    'SeDenyRemoteInteractiveLogonRight',
    'SeDebugPrivilege',
    'SeEnableDelegationPrivilege',
    'SeImpersonatePrivilege',
    'SeBatchLogonRight',
    'SeServiceLogonRight',
    'SeInteractiveLogonRight',
    'SeNetworkLogonRight',
    'SeRemoteInteractiveLogonRight')

# Inspect RSOP classes
# Having a precedence of 1 indicates the winning GPO
$URA_RSOP = Get-WmiObject RSOP_UserPrivilegeRight -namespace "root\RSOP\Computer" | where UserRight -in $URA | where precedence -eq 1 | select UserRight,AccountList,GPOID

The GPOID is the Distinguished Name of the object in AD, in the policies container. I'll have a look at the overall structure of HK, perhaps the name or GUIDs of GPOs expected to manage these settings can be stored in a config as well? Do you see this check fit in the current execution flow of HK?

A full list of RSOP classes can be found here, somehow this content is "outdated", but there's a ton more settings to review if needed.
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/policy/rsop-wmi-classes

Cheers

[0x6d69636b]

Hi Oliver,
Thank you for copying the issue over here. I'll look into it and keep you posted!

[ls-milkyway]

Yeah, possibilities of a conflict are high when registry entries are not reflected in the GPO entries. For example:

In file "finding_list_msft_security_baseline_windows_10_22h2_machine.csv"

ID: 11001,"Administrative Templates: Windows Components","Windows Ink Workspace: Allow Windows Ink Workspace"

creates registry entry HKLM:\Software\Policies\Microsoft\WindowsInkWorkspace,AllowWindowsInkWorkspace as 1
but gpedit.msc shows it "Not Configured" ??

I also don't understand how enabling it can it enhance security with low impact?

[0x6d69636b]

The group policy editor uses the registry.pol file to store all settings and does not read it from the registry as far as I know. I don't know how to properly edit this file and therefore HardeningKitty HailMary does not put entries in that file. Therefore, you can't see the configuration in gpedit. If anyone knows how to securely maintain registry.pol, please contact me.

My guess is that Microsoft won't disable the feature completely, therefore the recommend setting it to "1", so it only available for authenticated users and not on the lock screen.

[ls-milkyway]

If anyone knows how to securely maintain registry.pol, please contact me.

I have a hectic schedule but will certainly return and help as much as possible with pull requests ..thanks for your replies.

[rafalfitt]

registry.pol - file format:
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/policy/registry-policy-file-format

[An-dir]

I would also be interested in more integration in GroupPolicies. The Pol-Files can be read with https://github.com/PowerShell/GPRegistryPolicy#parse-polfile