Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PfxImport: Keys prevent multiple imports to different locations #260

Open
FiservSean opened this issue Feb 28, 2022 · 1 comment
Open

PfxImport: Keys prevent multiple imports to different locations #260

FiservSean opened this issue Feb 28, 2022 · 1 comment
Labels
discussion The issue is a discussion. enhancement The issue is an enhancement request.

Comments

@FiservSean
Copy link

Details of the scenario you tried and the problem that is occurring

I have a single certificate that needs to be provided to two service account users. The Key fields on Location, Store, and Thumbprint flag the second import as a duplicate, but notice that the PsDscRunAsCredential is different. This is because I'm running the import as the service user and installing the cert to the CurrentUser\My store.

Verbose logs showing the problem

Identifying details changed:
Test-ConflictingResources : A conflict was detected between resources '[PfxImport]MyDomain\ServiceAccount1_Cert (C:\MyDscScript.ps1::556::13::PfxImport)' and
'[PfxImport]MyDomain\ServiceAccount2_Cert (C:\MyDscScript::568::13::PfxImport)' in
node 'Node1'. Resources have identical key properties but there are differences in the following non-key properties: 'PsDscRunAsCredential'. Values
'System.Management.Automation.PSCredential' don't match values 'System.Management.Automation.PSCredential'. Please update these property values so that they are identical
in both cases.
At line:289 char:9

  •     Test-ConflictingResources $keywordName $canonicalizedValue $k ...
    
  •     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    • CategoryInfo : InvalidOperation: (:) [Write-Error], InvalidOperationException
    • FullyQualifiedErrorId : ConflictingDuplicateResource,Test-ConflictingResources

Suggested solution to the issue

Maybe add the Path as a Key to allow two copies of the same file to be imported?

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

foreach ($cert in $RoleData.Certificates)
{
    PfxImport "$($ConfigurationData.EnvironmentUserNames.Service)_Cert"
    {
	Ensure = 'Present'
	Location = $cert.Location
	Store = $cert.Store
	Thumbprint = $cert.Thumbprint
	Exportable = $true
	Path = $(GetRootedPath $ConfigurationData.SourceDirRoot $cert.Path)
	Credential = $script:CertificateCred
	PsDscRunAsCredential = $script:ServiceAccount1Cred
    }

    PfxImport "$($ConfigurationData.EnvironmentUserNames.Reporting)_Cert"
    {
	Ensure = 'Present'
	Location = $cert.Location
	Store = $cert.Store
	Thumbprint = $cert.Thumbprint
	Exportable = $true
	Path = $(GetRootedPath $ConfigurationData.SourceDirRoot $cert.Path)
	Credential = $script:CertificateCred
	PsDscRunAsCredential = $script:ServiceAccount2Cred
    }
}

The operating system the target node is running

Version and build of PowerShell the target node is running

Version of the DSC module that was used ('dev' if using current dev branch)

5.1.0

@PlagueHO PlagueHO added discussion The issue is a discussion. enhancement The issue is an enhancement request. labels Mar 9, 2022
@PlagueHO
Copy link
Member

PlagueHO commented Mar 9, 2022

Hi @FiservSean - thanks for raising this.

Unfortunately, this is a behavior of the DSC LCM. As you point out the PsDscRunAsCredential is not considered part of the key for the resource, so applying the resource twice with only the PsDscRunAsCredential differing is going to fail compilation.

There isn't an easy way around this issue, but there are possibilities:

  • Import the certificate to the LM store - which will make it available to both accounts. But that may not meet your security requirements.
  • Modify the resource to accept another credential parameter (similar to what we do with CertReq resource) that uses PDT to execute the import command under another user context. This would require making the new Credential a key value as well - which would be a breaking change and would have a wider impact.

@gaelcolas - not sure if you know any workaround to this? I've not seen anything that can address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion The issue is a discussion. enhancement The issue is an enhancement request.
Projects
None yet
Development

No branches or pull requests

2 participants