Powershell: seqüências de caracteres seguras com o Sysprep

Question

Eu tenho dois scripts do Powershell que estou construindo para uma imagem do Windows 7. Antes da imagem eu corro PRE-IMAGE.ps1, e tem uma linha como esta:

$JoinDomainPassword = Read-Host -Prompt "Please enter the password for $joinDomainUser" -AsSecureString
$strPass = $joinDomainPassword | ConvertFrom-SecureString

Em seguida, salve a string segura $ strPass no registro e execute o sysprep.

Após a reinicialização com o sysprep, o POST-IMAGE.ps1 extrai o $ strPass do registro e tem uma linha como esta:

$strPass = $strPass | ConvertTo-SecureString
$credentials = New-Object System.Management.Automation.PSCredential ($JoinDomainUser, $strPass)

No entanto, essas linhas em POST-IMAGE.ps1 obtêm o erro "Chave não válida" que você verá ao executar convertto-securestring e convertfrom-securestring como diferentes usuários do Windows. ( semelhante a esta questão ) - mas a captura aqui é eu-AM- usando o mesmo usuário para converter de e para strings seguras. Eu estou supondo que isso tem algo a ver com o sysprep - mas eu não posso envolver minha cabeça com isso.

Peço desculpas se isso já foi perguntado, encontrei algumas perguntas que abordam partes disso, mas não descrevem meu problema EXATO.

    

Answer 1

Os cmdlets Convert*-SecureString utilizam a API de proteção de dados do Windows para criptografar e descriptografar strings.

Por padrão, a chave de criptografia composta para esse tipo de operação é específica da conta de usuário que fez a chamada e da máquina para a qual a chamada foi feita.

Quando você executa sysprep /generalize , o SysPrep (entre outras coisas) neutraliza as bases do banco de dados SAM local, gerando um novo SID de máquina e um novo conjunto de chaves de criptografia.

Este artigo da base de conhecimento explica como isso afeta a descriptografia do EFS, mas seu problema é essencialmente o mesmo

Outra maneira de pensar sobre isso:
Como o SID da máquina representa efetivamente o domínio de logon para usuários locais, a conta de usuário não é, por definição, a mesma conta de antes da execução do SysPrep.