2017-02-03 1 views
0

J'ai un serveur Windows 2012R2 DSC Pull sous WMF5 et un client Windows 2008R2 sous WMF5.1. En raison de la nécessité d'accéder aux ressources du réseau, les informations d'identification sont codées dans le MOF par le serveur Pull et cryptées à l'aide d'un certificat qui réside dans Cert: \ LocalMachine \ MyDSC - erreur client - La clé privée n'a pas pu être acquise

Basé sur https://msdn.microsoft.com/en-us/powershell/dsc/securemof la clé a été créée à l'aide:

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 

J'ai exporté ce cert, et importé dans l'ordinateur client, aussi dans Cert: \ LocalMachine \ My en utilisant cette commande

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

Les deux machines peuvent trouver le cert avec le code suivant (à exécuter avec un utilisateur admin interactif)

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

et je peux voir dans le MOF sur le serveur Tirer, les informations d'identification cryptées. Le cryptage semble fonctionner comme prévu. Du côté client, le journal de traitement MOF affiche une instance de MSFT_DSCMetaConfiguration avec le CertificateID correspondant utilisé pour le chiffrement et le LCM a été initialisé avec une fonction pour extraire le certificat correct.

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 
     } 
    } 
} 

Cependant, le Get-DSCConfigurationStatus affiche un état d'échec. Quand je regarde dans les journaux, je vois l'erreur

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

et tous mes étages de pipeline sont finalement passés de InDesiredState = False; étant InDesiredState = True; (Je suppose que DSC fait cela pour éviter une tentative perpétuelle de faire quelque chose qu'il n'a aucun espoir d'atteindre). À ce stade, ma seule pensée est que le CERT du côté client n'est pas dans un emplacement auquel l'utilisateur du SYSTÈME peut accéder - mais je n'ai pas été capable d'identifier cela comme étant la cause.

Si Cert: \ LocalMachine \ Mon n'est pas l'emplacement correct - où le certificat doit-il être installé?

EDIT:

Le certificat est créé sur le serveur PULL et le fichier .CER exporté et importé manuellement dans le noeud cible (pour l'instant - éventuellement à traiter dans AD). J'ai également essayé d'exporter le PFX complet et de l'importer dans le nœud cible, avec le même résultat.

À ce stade, je soupçonne que le cert généré, être auto-signé, est insuffisant pour but ...

+0

Pouvez-vous mettre à jour la question de dire si vous créez le cert sur le noeud cible? L'erreur sur l'ordinateur client sur l'ordinateur sur lequel vous avez généré le certificat? Par client, voulez-vous dire le nœud cible qui exécutera la configuration? – TravisEz13

Répondre

0

base sur certaines hypothèses, vous créez le cert sur le serveur Pull, y compris le public et des clés privées. Ensuite, vous importez uniquement la clé publique (fichier .cer) sur le noeud cible. Le problème est le Pull Server n'est pas la machine qui a besoin de la clé privée. Le noeud cible a besoin de la clé privée. Le processus devrait ressembler plus à ceci.

  1. Création du certificat sur le noeud cible de la configuration, y compris les clés publique et privée.Voir Securing the MOF File - Creating the Certificate on the Target Node.
  2. Exportation de la clé publique
  3. Importation de la clé publique sur Tirez serveur
  4. Compiler la configuration sur le serveur Pull
  5. D'une certaine manière la configuration est en cours d'exécution sur le noeud cible

Ceci est considéré comme une mauvaise pratique mais si vous voulez avoir un cert, le processus devrait ressembler à ceci:

  1. Création du CERT sur le service de tirage r, y compris les clés publiques et privées. Voir Securing the MOF File - Creating the Certificate on the Target Node.
  2. Exportation du cert complet à l'aide Export-PfxCertificate
  3. transporter en toute sécurité la clé du noeud cible (ce qui est généralement pas fait en toute sécurité et pourquoi il est une mauvaise pratique)
  4. Importation de la clé de traction sur le noeud cible de la configuration
  5. la configuration sur Compiler le serveur Pull
  6. d'une certaine manière la configuration est en cours d'exécution sur le noeud cible
+0

Notre intention est d'avoir un cert (éventuellement déployé par AD sur ~ 200 machines). C'est pourquoi le certificat est généré sur le serveur Pull et est déployé (quoique de manière incorrecte selon vos informations) sur le nœud cible. –

+0

a mis à jour la réponse ... – TravisEz13

+0

Marquage comme réponse que le client voit maintenant le CERT - je reçois un échec de déchiffrement maintenant, mais c'est une erreur différente :) –