Windows Unattended Provisioning

Problema

Um Autounattend.xml funcional pode automatizar a instalação do Windows, mas isso não significa que ele seja automaticamente seguro para reutilização, publicação ou operação em escala.

Um arquivo de resposta pode conter senhas de administrador local, material de Wi-Fi, credenciais de ingresso no domínio, caminhos específicos do ambiente e comportamentos de setup que continuam ativos após a instalação. Reutilizar o mesmo arquivo operacional em várias implantações também dificulta rotação de credenciais, revisão, validação e resposta a incidentes.

O problema de engenharia, portanto, era mais amplo do que instalação autônoma: como transformar um setup Windows validado em uma pipeline reutilizável sem colocar segredos de produção no controle de versão?

Solução

O Windows Unattended Provisioning separa a árvore pública de código do artefato sensível usado na implantação.

O repositório contém um template sanitizado e compactado do arquivo de resposta, exemplos de configuração de ambiente, scripts PowerShell de build e execução no endpoint, lógica de validação, orientações de segurança e documentação bilíngue. Um administrador confiável fornece a credencial delegada de Domain Join e a senha do Wi-Fi de provisionamento somente durante o build local.

O processo então cria um output/Autounattend.xml específico para a implantação, gera uma senha única para o Administrator temporário quando ela não é fornecida, valida o XML e os scripts embutidos e apresenta o SHA-256 do arquivo final.

O arquivo gerado é tratado intencionalmente como mídia sensível. Ele é excluído do Git e não deve ser arquivado, enviado por e-mail ou distribuído amplamente.

Arquitetura de provisionamento

O fluxo atravessa duas fronteiras de execução.

Fronteira de build

Na estação de build confiável, o Build-Autounattend.ps1:

1. carrega a configuração de ambiente sem segredos;
2. solicita a credencial delegada de Domain Join e o segredo do Wi-Fi;
3. gera ou recebe a senha temporária do Administrator;
4. incorpora os scripts de primeiro logon, Hybrid Join e limpeza;
5. escapa os valores para os contextos PowerShell e XML;
6. rejeita placeholders não resolvidos e XML inválido;
7. grava o arquivo de resposta sensível e seu SHA-256.

O repositório público permanece genérico, enquanto o artefato de implantação passa a ser específico de um ambiente e de um lote de equipamentos.

Fronteira do endpoint

Durante o Windows Setup e o primeiro logon, os scripts embutidos:

1. iniciam o serviço de Wi-Fi e solicitam conexão ao perfil de provisionamento;
2. descobrem um controlador de domínio por registros DNS SRV;
3. validam disponibilidade LDAP antes do ingresso;
4. ingressam o dispositivo no domínio e na OU configurada usando Add-Computer;
5. registram uma tarefa adiada para concluir o Hybrid Microsoft Entra Join;
6. agendam a limpeza após a reinicialização;
7. persistem estado e logs em C:\ProgramData\WindowsDomainProvisioning.

A tarefa de Hybrid Join repete o processamento de Política de Grupo e o fluxo nativo Automatic-Device-Join independentemente do ingresso inicial no domínio.

Controles de segurança

O projeto não afirma que o fluxo atual da v1 elimina a exposição de segredos. Em vez disso, ele define e reduz a janela de exposição por controles em camadas:

• segredos de produção não existem no repositório público;
• configuração local e saída gerada são ignoradas pelo Git;
• a conta de Domain Join deve possuir delegação somente na OU de destino;
• a senha temporária do Administrator é única por build;
• a mídia de implantação é tratada como material sensível e de curta duração;
• arquivos de resposta, XML do Wi-Fi, scripts com credenciais e valores de autologon são removidos após o provisionamento;
• os logs operacionais são projetados para não registrar senhas ou o XML gerado;
• a rotação pelo Windows LAPS é esperada posteriormente por política do Microsoft Intune;
• falhas no Domain Join impedem a reinicialização automática, registram o estado de falha, limpam o autologon e agendam a limpeza.

Offline Domain Join é a direção arquitetural planejada para reduzir a exposição de credenciais reutilizáveis em uma versão futura.

Validação e observabilidade

O Test-Autounattend.ps1 valida:

• parsing do XML;
• placeholders não resolvidos;
• scripts embutidos obrigatórios;
• marcadores do comportamento de Domain Join;
• registro da limpeza;
• avisos conhecidos de configuração.

O GitHub Actions executa o build com credenciais fictícias, valida o XML gerado e confirma que a saída sensível e a configuração local não estão versionadas.

No endpoint, um documento de estado não sensível registra a etapa do provisionamento com valores como:

• domainJoin: Running, Succeeded ou Failed;
• hybridJoin: Pending, Succeeded, Disabled ou WaitingForDomain;
• cleanup: Pending, Scheduled ou Succeeded;
• lapsManagement: IntunePolicy.

O fluxo completo foi validado em equipamento piloto corporativo, passando pelo Windows Setup, ingresso no Active Directory, registro no Microsoft Entra ID, processamento de políticas do Intune e rotação pelo Windows LAPS.

Limitações atuais

A versão 1.0.0 preserva intencionalmente partes da base de arquivo de resposta validada, incluindo remoção opinativa de aplicativos, bypass de requisitos do Windows, habilitação de Remote Desktop, uma conta local padrão temporária e alterações de ACL na unidade do sistema.

Essas opções não são padrões universais. O template deve ser revisado conforme a baseline de segurança, a versão do Windows, a política de hardware e o inventário de aplicações do ambiente de destino.

O validador estrutural atual comprova propriedades esperadas do documento e dos scripts embutidos, mas não substitui implantação piloto e testes negativos em um ambiente representativo.

Estado atual

O repositório público inclui:

• template sanitizado e compactado do arquivo de resposta;
• scripts locais de build e validação;
• fluxos de Domain Join, Hybrid Join, limpeza, estado e logging;
• configuração de exemplo;
• validação por GitHub Actions;
• documentação em inglês e português do Brasil;
• política de segurança, licença MIT, changelog e versionamento semântico.

A versão 1.0.0 é uma base operacionalmente validada para provisionamento controlado de Windows, não um produto universal de implantação zero-touch.