У меня есть два сценария Powershell, которые я создаю для образа Windows 7. Перед изображением я запускаю PRE-IMAGE.ps1, и в нем есть такая строка:
$JoinDomainPassword = Read-Host -Prompt "Please enter the password for $joinDomainUser" -AsSecureString
$strPass = $joinDomainPassword | ConvertFrom-SecureString
Затем я сохраняю защищенную строку $ strPass в реестре и запускаю sysprep.
После перезагрузки с помощью sysprep POST-IMAGE.ps1 затем извлекает $ strPass из реестра и содержит следующую строку:
$strPass = $strPass | ConvertTo-SecureString
$credentials = New-Object System.Management.Automation.PSCredential ($JoinDomainUser, $strPass)
Однако эти строки в POST-IMAGE.ps1 получают ошибку «Ключ недействителен», которую вы увидите при запуске convertto-securestring и convertfrom-securestring от имени разных пользователей Windows. (похоже на этот вопрос) - но загвоздка здесь в том, что я -AM- использую одного и того же пользователя для преобразования в защищенные строки и обратно. Я предполагаю, что это как-то связано с sysprep - но я не могу об этом думать.
Прошу прощения, если об этом спрашивали раньше, я нашел несколько вопросов, которые касаются некоторых частей этого, но не описывают мою ТОЧНУЮ проблему.
В Convert*-SecureString командлеты используют API защиты данных Windows для шифрования и дешифрования строк.
По умолчанию ключ шифрования, составленный для этого вида операции, зависит от учетной записи пользователя, который совершил вызов, и машины, на которую был сделан вызов.
Когда ты бежишь sysprep /generalize, SysPrep (среди прочего) подрывает основы локальной базы данных SAM, генерируя новый SID машины и новый набор ключей шифрования.
Эта статья в базе знаний объясняет, как это влияет на расшифровку EFS, но ваша проблема, по сути, та же
Другой способ подумать об этом:
Поскольку идентификатор безопасности компьютера эффективно представляет домен входа для локальных пользователей, учетная запись пользователя по определению НЕ является той же учетной записью, что и до запуска SysPrep.