How to properly handle SID translation failures

[jcwalker]

I would like to get feedback from the community on the best way to handle SID translation exceptions. Currently the resource will throw an exception if a SID cannot be translated. There have been requests/suggestions that this behavior should be changed to silently handle the exception and have Test-TargetResource return false. In both cases the configuration will need to be updated. The way the resource currently works makes it obvious a correction needs to be made. If the resource is changed to silently handle the exception and return false the administrator will not know anything is wrong until they validate the configuration was successful. Is there anything else that I'm missing here? What are your thoughts?

[hackjammer]

I would prefer a Write-Warning alongside returning false - as of right now, throwing during Test-TargetResource means that Set doesn't run - which is more problematic. There are many examples of cases where SIDs will not get translated where nothing needs to be explicitly fixed (e.g. temporary accounts) - not applying the configuration is bad, reapplying with a warning is far better.

[jcwalker]

I would argue that something does need to get explicitly fixed. Even if the we write a warning and return false the node will not be in compliance until the configuration script is updated and the identity that cannot be resolved is removed or corrected.

[danielboth]

I would be ok with throwing an exception if the SID that could not be translated is in the part of the policy I actually want to configure. The problem is that with the current implementation all SIDs are translated, even in parts that I did not describe in the DSC configuration. That feels just wrong.

Also we might needs some exclusion list? In my case, I'm having failures on this resource since IIS is installed on the box and the " Classic .NET AppPool " identity cannot be resolved. So that's one that probably never will work.

When thinking about it, we are configuring a desired state here so let's take this config:

UserRightsAssignment LogonAsAService {
    Policy = 'Log_on_as_a_service'
    Identity = 'DOMAIN\MyCustomGroup'
    Ensure = 'Present'
}

What do we need to do in this case? We need to resolve the identity for MyCustomGroup and ensure that it is present in the Log_on_as_a_service policy. Nothing more, I don't care about any lingering identities that cannot be resolved, I care about what I've described in my DSC configuration. So if we cannot resolve the identity for MyCustomGroup we should throw an exception, but not on other, unrelated, identities.

@jcwalker, does this help? It would be nice if this issue could be solved in the next release!

[johlju]

I agree with @danielboth that it is the configuration that is important. If the SID's cannot be resolved that is not part of the configuration then that is not a big deal, although if a SID cannot be resolved that are in the configuration that means that the Set-TargetResource function will always run.

There are a suggestion here in the #74 (comment). I'm also curious what scenarios this happens in, so this can be regression tested, see #74 (comment).

For reference: PR #65, #72 and #74 is dependent on this discussion

[johlju]

@jcwalker do you have suggestion to how we move forward with this issue?

[jcwalker]

@johlju I've talked with a lot of folks on the best way to handle this. I think that Test-TargetResource needs to run without error and return false that way someone can run Test-DscConfiguration and it will actually complete. There are a lot of issue where folks report the resource is not propertly resolving SIDs that I can't reproduce. Further investigation on why SID resolution fails is needed and document when credentials are needed for resolution to be successful, such as an identity from a different domain.

[danielboth]

@jcwalker All the SID resolution issues that I've seen so far have not been caused by what we described in the DSC configuration. All were caused by other not SIDs that could not be resolved. Like non existing accounts or the Classic .NET AppPool I described. However, I don't care about those at all.

Is it possible to just focus the resource at what the user intents to have in desired state and ignore all the other errors?

[jcwalker]

@danielboth you are the first one to bring up this scenario and I'm puzzled why it's evening happening because Test-TargetResource and Set-TargetResource only handle the policies being managed. But I think what maybe happening is when the code gets the current configuration it grabs all the policies. I will look into that scenario. I think if we make the SID conversion process not throw it would fix it also.

[pjolsen]

Hi jcwalker,

I've just raised an issue regarding exactly that issue. I have seen multiple machines erroring out due to unresolved SIDs being present in user rights that are not managed through DSC. The target user rights are clean (all SIDs resolving properly) but it seems that function "Get-UserRightsAssignment" doesn't filter to the specific user right to be targeted and attempts to resolve everything in the secedit.exe /export file.

[pjolsen]

Sorry - I think the code may actually be required in the Get-SecurityPolicy policy function. I think it should be as simple as having an extra parameter (e.g. $userright) passed into the get-securitypolicy function that holds the specific user right being targeted and then modifying the code with a where statement similiar to the below:

foreach ($key in ($privilegeRights.keys | where {$_ -eq $userright})