[Feature] - Enforce null values in User Rights (Win)

[CyberChelonian]

Is your feature request related to a problem? Please describe.
Now that Intune provides a way (found in most recent CIS Intune benchmark) to enforce null values, the values from baselines/benchmarks this project aims to align to should be enforced.

Describe the solution you'd like

Access Credential Manager As Trusted Caller = (<![CDATA[]]>)
Act As Part Of The Operating System = (<![CDATA[]]>)
Create Permanent Shared Objects = (<![CDATA[]]>)
Create Token = (<![CDATA[]]>)
Enable Delegation = (<![CDATA[]]>)
Lock Memory = (<![CDATA[]]>)
Modify Object Label = (<![CDATA[]]>)

[SkipToTheEndpoint]

Hi @CyberChelonian

I've gone back-and-forth with CIS on a number of occasions now and I did actually have these values included until v3.4 when I removed them for the following reason:

All of the above are empty by default on Windows, and it's difficult to tell whether the policy is just silently erroring (as the use of () is only valid when using Custom OMA-URI as per the docs) but remaining empty because that's default. Either way, it's an enforcement of defaults, and with the difficulty of verifying the policy even works correctly, I'm removing the offending settings until a better solution presents itself.

Source

In fact, using their own CIS-CAT Pro tool to validate the OIB has all of these values marked as a Pass, because they're only checking the value is set to "No one", which is the Windows default value:

[CyberChelonian]

I had read your thoughts before on null values and avoiding custom CSP

What I forgot to state, was in my latest testing, custom CSP is no longer needed. Intune accepts CDATA blank value for null using the template, and it applies to endpoints without any errors report back.

[SkipToTheEndpoint]

I'm aware, as I said, in version 3.3 and below I was defining the CDATA property as part of a normal Settings Catalog policy, it applied fine and without any errors back then (2+ years ago): https://github.com/SkipToTheEndpoint/OpenIntuneBaseline/blob/8def9e2ba1d96f5f92efb1b7eef8f0bb0ad1969f/WINDOWS/IntuneManagement/SettingsCatalog/Win%20-%20OIB%20-%20Device%20Security%20-%20D%20-%20User%20Rights%20-%20v3.1.json

My point is, I'm not certain that doing so is actually applying in the way it's intended, and the "correct" application is more of a side-effect than an intended outcome.

Ultimately, as "No One" is Windows default for those particular User Rights, any malicious usage would have to:
a) Have admin rights to begin with.
b) Even on a best-case scenario with Config Refresh active, an attacker would have a 30-minute window of abuse with above admin rights.
c) The potential attack vector involved here, while not zero, is unlikely due to far better attack paths being available.

[CyberChelonian]

@SkipToTheEndpoint:

I ran the following test to verify whether blank CDATA entries are enforced correctly:

• Elevated to Local Security Policy using LAPS.
• Added the Administrators group to a User Rights Assignment setting that is configured as null via CDATA in the User Rights template. Specifically, I tested "Enable computer and user accounts to be trusted for delegation" (displayed in Intune as "Enable delegation").
• Forced an Intune sync and rebooted the device. (I did not wait long after the sync before rebooting.)

Result: After policy reapplication, the Administrators group was automatically removed from the "Enable computer and user accounts to be trusted for delegation" user right. The setting was restored to a blank/null state as defined in the template.

Based on this testing, the blank CDATA entries are functioning as intended and are being actively enforced. Given this behaviour, I do not see a reason not to enforce null values within the baseline.