Open ShawnHardwick opened 3 years ago
Experiencing this same problem where unresolved SIDs are causing the resource to fail (Windows 2012R2, WMF 5.1, SecurityPolicyDSC 2.4.0.0)
At the least, when the resource allows adding/removing individual security principal privileges in a security policy then it must ignore security principals in an existing security policy that are not governed by the DSC configuration. At best, Set-TargetResource
should not attempt any security principal translation at all. In any case, no part Get-
, Set-
, and Test-TargetResource
should cause the resource to fail if translation does not succeed: neither secedit nor Windows care about the presence of unresolved SIDs in a security policy.
There is no need to perform translation between NT Account Name and Security Identifier formats during Set-TargetResource
. During a configure operation (secedit.exe /configure
), secedit will happily accept either style in the .inf file. It will also accept and de-duplicate security principals that are specified as an account name and SID in the same line item under the [Privileges] section.
Translation should be performed in Test-TargetResource
and Get-TargetResource
since the parsed .inf export (from secedit.exe /export
) may use either format. As an example, if the DSC configuration specifies "Administrator" but the parsed .inf specifies "S-1-5-21-
Details of the scenario you tried and the problem that is occurring
I am utilizing the dsc_lite Puppet module in Puppet to execute the UserRightsAssignment resource to manage the
Log_on_as_a_batch_job
property. A large number of our servers have orphaned SIDs due to legacy reasons.When executing the below DSC resource, the resource fails to Set-TargetResource due to the orphaned SID. https://github.com/dsccommunity/SecurityPolicyDsc/blob/master/source/Modules/SecurityPolicyResourceHelper/SecurityPolicyResourceHelper.psm1#L376 Using the Force parameter is not an option for our use case as it would be too strict for management.
There are a few similar issues in the repo's history:
78 and #141
Verbose logs showing the problem
Suggested solution to the issue
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
OsName : Microsoft Windows Server 2016 Standard OsOperatingSystemSKU : StandardServerEdition OsArchitecture : 64-bit
Version and build of PowerShell the target node is running
PSVersion 5.1.14393.3866
Version of the DSC module that was used
2.10.0.0 and 3.0.0-preview003