UserRightsAssignment: 'Could not translate SID' for orphaned SID

[ShawnHardwick]

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

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = Resourceset,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredS
tateConfiguration'.
VERBOSE: An LCM method call arrived from computer SERVERNAME with user sid S-1-5-18.
VERBOSE: [SERVERNAME]: LCM:  [ Start  Set      ]  [[UserRightsAssignment]DirectResourceAccess]
VERBOSE: [SERVERNAME]:                            [[UserRightsAssignment]DirectResourceAccess] C
ould not translate SID: REDACTED_INVALID_SID on Policy: Log_on_as_a_batch
_job
VERBOSE: [SERVERNAME]:                            [[UserRightsAssignment]DirectResourceAccess] P
olicy: Log_on_as_a_batch_job. Identity: REDACTED
VERBOSE: [SERVERNAME]: LCM:  [ End    Set      ]  [[UserRightsAssignment]DirectResourceAccess]  
in 0.1880 seconds.
PowerShell DSC resource MSFT_UserRightsAssignment  failed to execute Set-TargetResource 
functionality with error message: Could not translate SID: 
REDACTED on Policy: Log_on_as_a_batch_job 
    + CategoryInfo          : InvalidOperation: (root/Microsoft/...gurationManager:String) [], Ci 
   mException
    + FullyQualifiedErrorId : ProviderOperationExecutionFailure
    + PSComputerName        : localhost

Suggested solution to the issue

• Remove orphaned SID in Set-TargetResource or
• Ignore orphaned SID in Set-TargetResource

The DSC configuration that is used to reproduce the issue (as detailed as possible)

$invokeParams = @{
Name = 'UserRightsAssignment'
ModuleName = 'SecurityPolicyDsc'
Method = 'set'
Property = @{
'policy' = 'Log_on_as_a_batch_job';
'identity' = @('domain\user')
}
}

$result = Invoke-DscResource @invokeParams

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

[prochammer]

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--500" (the wellknown SID for builtin Administrator), the resource should be able to determine that it is in state.