Impersonating operations

[Mark Johnson]

By default, operations will be performed as the user that the agent service runs as (Local System). I am trying to perform some group and user operations using PSDsc. Because this DSC operation must reach out to the domain, it will not have domain rights to query the members being added to the group.

PSDsc Group
(
    Otter_ConfigurationKey: CreateDummyGroup,
    GroupName: DummyGroupCreatedByOtter,
    Ensure: Present,
    Description: Test using PSDsc from Otter,
    Members: "`@('mydomain\myuser')"
);

This will produce the error:

PowerShell DSC resource MSFT_GroupResource failed to execute Set-TargetResource functionality with error message: Credentials are required to resolve the domain account mydomain\myuser.

Perhaps allowing General blocks to execute with specific credentials (impersonate) might be a solution? I have done this type of impersonation in PowerShell, and found that a different type of impersonation is required to perform network operations.

I think offering impersonation may offer a better solution than running agents as a domain user, as it is by default low privileged, and only impersonate when absolutely needed.

[Mark Johnson]

The 'Group' DSC resource does accept a 'Credential' parameter, but I am not sure how to pass an Otter credential into that, as the PSDsc only supports strings, arrays, booleans, decimals and hashes for parameter values.

[Alana]

Unfortunately, impersonation is not trivial complicated, especially with the hosted powershell model. It's definitely doable -- and the new agent model would support launching different sub-agents under a different user -- but we looked to the "sudo problem" when consideration solution.

That is, if the automation tool easily has the capability to elevate permissions, then it effectively always has those permissions, because you're /automatically elevating/ to a different level. At best, it may prevent a typo in an automation script... but, it isn't a great security thing.

Regarding the question, you can use the GetCredentialProperty variable unction to extract the password property from a credential stored in otter and pass to script.

[Mark Johnson]

Regarding the question, you can use the GetCredentialProperty variable function to extract the password property from a credential stored in otter and pass to script.

The problem is, in this instance, I need to pass an actual PSCredential object into the "Credential" parameter of the DSC resource. Is there a way to accomplish this in Otter without creating a custom PowerShell script to invoke the DSC resource?

[Alana]

You know, I believe this came up at one point, in this GitHub issue. So, it's not implemented... but do you think it could work?

set $password = $GetCredentialProperty(mysecret, password);

PSDsc Group
(
    Otter_ConfigurationKey: CreateDummyGroup,
    GroupName: DummyGroupCreatedByOtter,
    Ensure: Present,
    Description: Test using PSDsc from Otter,
    Members: "`@('mydomain\myuser')",
    Credential: $ToPsCredential(someusername, $password)
);

[Mark Johnson]

Sure, that would solve the issue.