O Powershell DSC usa o arquivo de certificado incorreto para criptografia, onde os nomes dos nós correspondem parcialmente?

1

Acho que há um erro na maneira como o DSC escolhe o arquivo de certificado usado para criptografia de credenciais, como o recurso de serviço e um PSCredential.

A configuração do DSC usa o CertificateFile incorreto da coleção AllNodes se um nome de nó estiver contido em um nome de nó subseqüente (a ordem do nó é significativa). Isso significa que o valor criptografado enviado para o nó pode estar errado.

Aqui está uma repro incluindo dois testes. Ambos os testes devem falhar, mas o primeiro é bem-sucedido (com o certificado errado):

$password = ConvertTo-SecureString "password" -AsPlainText -Force
$serviceCredential = New-Object System.Management.Automation.PSCredential ("username", $password)
$currentPath = Split-Path -Parent $MyInvocation.MyCommand.Definition

$thisShouldNotWork = @{
    AllNodes = @(
        @{
            NodeName = "web1"
            CertificateFile = "nonexistentfile"
        },

       @{
            NodeName = "customerweb1"
            CertificateFile = "$currentPath\mycert.cer"
        }
    );
}

$thisDoesNotWork = @{
    AllNodes = @(
        @{
            NodeName = "web1"
            CertificateFile = "nonexistentfile"
        },

       @{
            NodeName = "customerweXb1"
            CertificateFile = "$currentPath\mycert.cer"
        }
    );
}

Configuration DscWebServer
{
  Node $AllNodes.NodeName
  {
    Service "Service Started"
    {
      Name = "MyService"
      State = "Running"
      Credential = $serviceCredential
    }
  }
}

Write-Host "Test 1" -ForegroundColor Blue -BackgroundColor White
DscWebServer -OutputPath .\DSC -ConfigurationData $thisShouldNotWork
Write-Host "Test 2" -ForegroundColor Blue -BackgroundColor White
DscWebServer -OutputPath .\DSC -ConfigurationData $thisDoesNotWork

Eu relatei isso em Conecte , mas queria levantá-lo aqui caso seja útil ou há algo incomum sobre o que eu fiz. Alguém pode explicar esse comportamento?

ATUALIZAÇÃO: A Microsoft confirmou isso como um bug e o corrigiu em maio de 2015. Recebi este feedback: "Este problema foi corrigido no WMF5 April Preview. Por favor, deixe-nos saber se você não concorda :)"

    
por Robin M 16.02.2015 / 13:16

1 resposta

0

Isso é interessante. Você pode confirmar qual é a saída de cada teste? O Teste 2 realmente lança uma exceção?

Eu não diria que há algo incomum sobre o que você fez, já que o DSC foi projetado para lidar com vários nós dessa maneira, mas ainda há apenas um pequeno número de pessoas usando o DSC e um número ainda menor usando credenciais seguras .

Além disso, muitos de nós têm usado uma única configuração para cada nó, o que impediria que alguém desse esse comportamento.

Essa é, naturalmente, uma solução viável para você também, mas exigiria alterações em seu fluxo de trabalho.

Para utilizar os dados de configuração existentes, pode contornar o problema desta forma:

foreach($node in $thisShouldNotWork.AllNodes) {
    DscWebServer -OutputPath .\DSC -ConfigurationData @{AllNodes = @($node)}
}

Tentarei reproduzir isso amanhã, se possível, para que eu possa adicionar meu voto e a descrição da descrição ao relatório sobre conexão.

    
por 16.02.2015 / 22:41