2017-02-03 9 views
0

Ich habe einen Windows 2012R2 DSC Pull Server unter WMF5 und einen Windows 2008R2 Client unter WMF5.1. Aufgrund der Notwendigkeit, die Netzwerkressourcen zuzugreifen, werden Anmeldeinformationen in die MOF kodiert durch den Pull-Server und verschlüsselten ein Zertifikat verwendet, die in Cert befindet: \ Localmachine \ MyDSC - Clientfehler - Der private Schlüssel konnte nicht erworben werden

Basierend auf https://msdn.microsoft.com/en-us/powershell/dsc/securemof wurde mit dem Schlüssel erstellt:

New-SelfsignedCertificateEx ` 
-Subject "CN=${ENV:ComputerName}.${ENV:UserDnsDomain}" ` 
-EKU 'Document Encryption' ` 
-KeyUsage 'KeyEncipherment, DataEncipherment' ` 
-SAN ${ENV:ComputerName}.${ENV:UserDnsDomain} ` 
-FriendlyName 'DSC Credential Encryption certificate' ` 
-Exportable ` 
-StoreLocation 'LocalMachine' ` 
-StoreName 'My' ` 
-KeyLength 2048 ` 
-ProviderName 'Microsoft Enhanced Cryptographic Provider v1.0' ` 
-AlgorithmName 'RSA' ` 
-SignatureAlgorithm 'SHA256' ` 
-NotBefore $effDate ` 
-NotAfter $expiryDate 

ich habe dieses Zertifikat exportiert, und in den Client-Computer importiert werden, auch in Cert: \ Localmachine \ My mit diesem Befehl

certutil -addstore My C:\DSC\DscPublicKey.cer 

Beide Maschinen können die cert mit dem folgenden Code (ausgeführt mit einem interaktiven Benutzer admin)

$Cert = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object { 
    (
     ($_.Issuer -eq $IssuerCN) -and ($_.Subject -eq $IssuerCN) 
    ) 
} 
Write-Host " Thumbprint : " $Cert.Thumbprint 

finden und ich kann in der MOF auf dem Pull-Server die verschlüsselten Anmeldeinformationen sehen. Die Verschlüsselung scheint wie beabsichtigt zu funktionieren.

Auf der Clientseite zeigt das MOF-Verarbeitungsprotokoll eine Instanz von MSFT_DSCMetaConfiguration mit der übereinstimmenden CertificateID, die für die Verschlüsselung verwendet wurde, und das LCM wurde mit einer Funktion zum Abrufen des richtigen Cert initialisiert.

function Get-LocalEncryptionCertificateThumbprint 
{ 
    (dir Cert:\LocalMachine\my) | %{ 
     # Verify the certificate is for Encryption and valid 
     If (($_.Issuer -eq $encryCertCN) -and ($_.Subject -eq $encryCertCN) ) 
     { 
      return $_.Thumbprint 
     } 
    } 
} 

Der Get-DSCConfigurationStatus zeigt jedoch einen Fehlerstatus. Wenn ich die Protokolle schauen, sehe ich den Fehler

Status = "Failure"; 
Error = "The private key could not be acquired."; 

und alle meine Pipeline-Stufen schließlich geschaltet werden von InDesiredState = False; zu InDesiredState = True; (Ich gehe davon aus, dass DSC dies tut, um einen fortwährenden Versuch zu vermeiden, etwas zu tun, auf das es keine Hoffnung gibt).

An dieser Stelle ist mein einziger Gedanke, dass das CERT auf der Client-Seite nicht an einem Ort ist, auf den der SYSTEM-Benutzer zugreifen kann - aber ich konnte dies nicht als Ursache identifizieren.

Wenn Cert: \ LocalMachine \ Mein ist nicht der richtige Speicherort - wo sollte das Zertifikat installiert werden?

EDIT:

Das Zertifikat auf dem Pull-Server und die CER-Datei exportiert und manuell importiert in den Zielknoten erstellt wird (vorerst - schließlich in AD behandelt werden). Ich habe auch versucht, den vollständigen PFX zu exportieren und ihn mit demselben Ergebnis in den Zielknoten zu importieren.

An dieser Stelle mein Verdacht ist, dass das CERT erzeugt, selbst signierte sein, Zweck reicht nicht für ...

+0

können Sie die Frage aktualisieren zu sagen, wenn Sie das Zertifikat auf dem Zielknoten erstellen? Ist der Fehler auf dem Client-Computer auf der Maschine, die Sie das Zertifikat generiert? Mit Client meinen Sie den Zielknoten, auf dem die Konfiguration ausgeführt wird? – TravisEz13

Antwort

0

Base auf einigen Annahmen, können Sie das Zertifikat auf dem Pull-Server erstellen, einschließlich der öffentlichen und private Schlüssel. Dann nur den öffentlichen Schlüssel (die Datei .cer) auf den Zielknoten importieren. Das Problem ist, dass der Pull-Server nicht der Computer ist, der den privaten Schlüssel benötigt. Der Zielknoten benötigt den privaten Schlüssel. Der Prozess sollte eher so aussehen.

  1. Erstellen des Zertifikats auf dem Zielknoten der Konfiguration, einschließlich der öffentlichen und privaten Schlüssel.Siehe Securing the MOF File - Creating the Certificate on the Target Node.
  2. Exportieren des öffentlichen Schlüssels
  3. den öffentlichen Schlüssel importieren auf Pull Server
  4. Kompilieren der Konfiguration auf dem Pull-Server
  5. Irgendwie die Konfiguration auf dem Zielknoten

dies eine schlechte betrachtet läuft Übung, aber wenn Sie ein Zertifikat haben möchten, würde der Prozess wie folgt aussehen:

  1. Erstellen des Zertifikats auf dem Pull Serve r, einschließlich der öffentlichen und privaten Schlüssel. Siehe Securing the MOF File - Creating the Certificate on the Target Node.
  2. die vollständigen cert Exportieren mit Export-PfxCertificate
  3. sicher den Schlüssel zu dem Zielknoten transportieren (dies ist in der Regel nicht sicher getan und warum es eine schlechte Praxis ist)
  4. die Pull-Taste Importieren auf Zielknoten der Konfiguration
  5. Kompilieren der Konfiguration auf dem Pull-Server
  6. Irgendwie die Konfiguration auf dem Zielknoten läuft
+0

Unsere Absicht ist es, ein Zertifikat zu haben (eventuell von AD auf ~ 200 Maschinen verteilt). Aus diesem Grund wird das Zertifikat auf dem Pull-Server generiert und (wenn auch inkorrekt gemäß Ihren Informationen) auf dem Zielknoten bereitgestellt. –

+0

aktualisiert die Antwort ... – TravisEz13

+0

Kennzeichnung als Antwort, wie der Client jetzt das Cert sieht - ich bekomme jetzt einen Entschlüsselungsfehler, aber das ist ein anderer Fehler :) –

Verwandte Themen