2017-02-03 6 views
0

У меня есть Windows 2012R2 DSC Pull сервер под WMF5 и клиент Windows 2008R2 под WMF5.1. В связи с необходимостью получить доступ к сетевым ресурсам, учетные данные кодируются в MOF сервером Выдвижная и зашифрованы с использованием сертификата, который проживает в Cert: \ LocalMachine \ MyDSC - ошибка клиента - закрытый ключ не удалось получить

основе https://msdn.microsoft.com/en-us/powershell/dsc/securemof ключ был создан с помощью:

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 

Я экспортировали этот сертификат, и импортировать его в клиентский компьютер, а также в Cert: \ LocalMachine \ My с помощью этой команды

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

Обе машины могут найти сертификат с помощью следующего кода (запустить с помощью интерактивного пользователя с правами администратора)

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

и я могу видеть в MOF на сервере дергать, зашифрованные учетные данные. Похоже, что шифрование работает по назначению.

На стороне клиента журнал обработки MOF показывает экземпляр MSFT_DSCMetaConfiguration с соответствующим идентификатором CertificateID, который использовался для шифрования, и LCM был инициализирован функцией для вытягивания правильного сертификата.

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

однако, Get-DSCConfigurationStatus показывает статус отказа. Когда я смотрю в журналы, я вижу ошибку

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

и все мои этапы трубопровода, в конечном итоге перешли от InDesiredState = False; - InDesiredState = True; (Я предполагаю, что DSC делает это, чтобы избежать постоянной попытки сделать что-то, чего у него нет надежды на достижение).

На данный момент моя единственная мысль заключается в том, что сертификат на стороне клиента не находится в местоположении, доступ к которому пользователь SYSTEM может получить, но я не смог идентифицировать это как причину.

Если Сертификат: \ LocalMachine \ Мой Неправильное расположение - где должен быть установлен сертификат?

EDIT:

Свидетельство создается на PULL сервер и файл .CER экспортируемой и импортируемой вручную в целевой узел (в настоящее время - в конце концов, должны быть обработаны в AD). Я также попытался экспортировать полный PFX и импортировать его в целевой узел с тем же результатом.

На данный момент, мое подозрение, что сертификат генерируется, будучи самозаверяющим, недостаточно для целей ...

+0

вы можете обновить вопрос, чтобы сказать, если вы создаете сертификат на целевом узле? Является ли ошибка на клиентском компьютере на компьютере, сгенерированном вами сертификатом? По клиенту вы имеете в виду целевой узел, который будет запускать конфигурацию? – TravisEz13

ответ

0

База по некоторым предположениям, вы создаете сертификат на сервере дергать, в том числе общественности и частные ключи. Затем только импорт открытого ключа (файл .cer) на целевом узле. Проблема заключается в том, что Pull Server не является машиной, для которой нужен секретный ключ. Целевому узлу нужен закрытый ключ. Этот процесс должен выглядеть более как это.

  1. Создание сертификата на целевом узле конфигурации, включая общедоступные и закрытые ключи.См. Securing the MOF File - Creating the Certificate on the Target Node.
  2. Экспорт открытого ключа
  3. Импорт открытого ключа на Выдвижная сервере
  4. Компиляция конфигурации на Выдвижная сервере
  5. Как-то конфигурация выполняется на целевом узле

Это считается плохим но если вы хотите иметь один сертификат, процесс будет выглядеть так:

  1. Создание сертификата на вытягивании r, включая общедоступные и закрытые ключи. См. Securing the MOF File - Creating the Certificate on the Target Node.
  2. Экспорт полного сертификата с помощью Export-PfxCertificate
  3. надежно транспортировать ключ к целевому узлу (обычно это не сделано надежно и почему это плохая практика)
  4. Импорт ключа тянуть на целевом узле конфигурации
  5. Компиляция конфигурации на сервере Выдвижной
  6. как-то конфигурация выполняется на целевом узле
+0

Наше намерение состоит в том, чтобы иметь один сертификат (в конечном итоге развернутый AD до ~ 200 машин). Вот почему сертификат генерируется на сервере Pull и развертывается (хотя и неправильно в соответствии с вашей информацией) на целевом узле. –

+0

обновил ответ ... – TravisEz13

+0

Отметить как ответ, так как клиент теперь видит сертификат - теперь я получаю дешифровку, но это другая ошибка :) –

Смежные вопросы