Secrets Vault

Domain-join passwords, service accounts, and other credentials are never stored in plain JSON. They live in a secrets vault that task sequences reference by key.

Creating a vault

Initialize-SecretVault -Secrets @{
    domainJoinPassword = 'ServiceAccountPassword!'
}

By default this uses DPAPI, which encrypts the vault with the Windows account that created it.

DPAPI vs AES — which one to use

DPAPI only works when the vault is read on the same machine, by the same account that created it. In a networked deployment scenario this breaks down:

Vault created on SERVER (account SVC-DEPLOY)
  → encryption bound to SVC-DEPLOY on SERVER

Target machine (WORKSTATION-01) tries to read the vault
  → different DPAPI context → silent failure → falls back to an interactive prompt

For a vault that needs to be read from a different machine (e.g. by WinPE or a freshly imaged workstation), use AES with a password instead — the vault becomes portable because the decryption key is the password itself, not tied to a Windows account:

Initialize-SecretVault -Secrets @{
    domainJoinPassword = 'ServiceAccountPassword!'
} -Password 'VaultPassword!'

The same password must then be supplied wherever the vault is read.

Referencing a secret in a sequence step

{
  "type": "JoinDomain",
  "params": {
    "domain":     "corp.local",
    "ou":         "OU=Workstations,OU=IT,DC=corp,DC=local",
    "username":   "svc-joindomain",
    "credential": { "source": "vault", "key": "domainJoinPassword" }
  }
}

Dedicated service account

Do not use a domain administrator account for JoinDomain. Create a dedicated service account (e.g. svc-joindomain) with only the "Join computers to domain" delegation on the target OU.