BitLocker Network Unlock: Arranque Automático de Servidores
São 3 horas da manhã, a janela de patches corre e um servidor Windows Server 2025 reinicia depois de instalar actualizações. O disco de sistema está cifrado com BitLocker e o protector é TPM+PIN. No pré-arranque, o ecrã fica à espera que alguém digite o PIN. Sem ninguém no datacenter, o servidor não chega a arrancar e a janela de manutenção perde-se. É este vazio que o Network Unlock elimina em ambientes com Active Directory.
O Network Unlock é um key protector do BitLocker para volumes de sistema. Em vez de exigir o PIN em cada reinício, o servidor recebe parte da chave pela rede a partir de um servidor com a função Windows Deployment Services (WDS), enquanto a outra parte fica selada no TPM (Trusted Platform Module). O desbloqueio automático só acontece com o servidor ligado por cabo à rede da empresa, em que o pedido trocado no arranque usa DHCP na subrede local. Fora desse contexto, o BitLocker volta ao comportamento normal e pede o PIN.
Este guia configura o lado do servidor de unlock (WDS, feature, certificado, GPO) e o lado do servidor protegido (BitLocker com TPM+PIN) num domínio Active Directory com Windows Server 2025. Os mesmos passos servem para Windows Server 2019 e 2022 e a funcionalidade existe também para clientes Windows 10 e Windows 11. Nada fica por presumir: a instalação das funções entra no primeiro passo.
Neste artigo
- 1. Requisitos e Instalação das Funções no Servidor
- 2. Passo 1 — Criar o Certificado de Network Unlock
- 3. Passo 2 — Distribuir o Certificado por GPO
- 4. Passo 3 — Activar BitLocker com TPM+PIN no Servidor
- 5. Passo 4 — Verificar o Protector e Testar o Desbloqueio
- 6. Passo 5 — Restringir Subredes no Servidor de Unlock
- 7. Manutenção de Certificados e Desactivação
- Erros Comuns
- Checklist
- Artigos Relacionados
- Fontes Oficiais
1. Requisitos e Instalação das Funções no Servidor
O desbloqueio reparte-se por quatro peças: um servidor com a função Windows Deployment Services (WDS), a feature opcional BitLocker Network Unlock nesse servidor, um servidor DHCP separado do WDS e clientes com TPM e pelo menos um protector TPM. O lado do cliente exige UEFI (Unified Extensible Firmware Interface) 2.3.1 ou superior, em modo nativo e sem CSM (Compatibility Support Module), com a pilha de rede activa no firmware e um driver DHCP implementado no UEFI. O certificado de 2048 bits RSA com o par de chaves público e privado bem configurado fecha a lista de requisitos.
Um detalhe que apanha quem monta servidores com várias placas de rede: a primeira placa enumerada, normalmente a onboard, tem de ter DHCP a funcionar. O processo de unlock pára de enumerar adaptadores quando chega a uma placa com falha na porta DHCP. Numa máquina com iDRAC, iLO ou outro adaptador de lights-out management sem DHCP entre os primeiros a serem enumerados, o unlock falha mesmo com a configuração correcta no resto — a Microsoft descreve exactamente este caso: adaptadores sem DHCP, como os de gestão, param a enumeração.
No servidor de unlock, a instalação resume-se a duas funções e a uma confirmação de serviço:
Install-WindowsFeature WDS-Deployment
Install-WindowsFeature BitLocker-NetworkUnlock
Get-Service WDSServer
Exemplo de saída do último comando:
Status Name DisplayName
------ ---- -----------
Running WDSServer Windows Deployment Services Server
A configuração da instalação do WDS não é necessária. A exigência da Microsoft é que o serviço WDSServer esteja em execução no momento dos pedidos de unlock.
2. Passo 1 — Criar o Certificado de Network Unlock
O certificado é o elemento central do esquema. O cliente cifra a chave de rede com a chave pública RSA de 2048 bits deste certificado e só o servidor de unlock, com a privada, a consegue devolver. O certificado precisa de uma aplicação própria, com o Object Identifier (OID) 1.3.6.1.4.1.311.67.1.1 registado como BitLocker Network Unlock.
Numa PKI com Active Directory Certificate Services (AD CS), o caminho passa pelo certtmpl.msc: duplicar o template User e, no separador Compatibility, fixar Certification Authority em Windows Server 2016 e Certificate recipient em Windows 10. No Request Handling, definir Purpose como Encryption e permitir a exportação da chave privada. No Cryptography, fixar 2048 bits com o Microsoft Software Key Storage Provider e limpar todos os outros providers. No Subject Name, escolher Supply in the request. No Issuance Requirements, activar CA certificate manager approval e Valid existing certificate. No Extensions > Application Policies, remover as três policies que vêm do template User (Client Authentication, Encrypting File System e Secure Email) e adicionar a Application Policy BitLocker Network Unlock com o OID 1.3.6.1.4.1.311.67.1.1. Na extensão Key Usage, activar key encipherment e marcar a extensão como crítica. Na Security, confirmar que Domain Admins tem Enroll. Publicado o template em certsrv.msc, o certificado pede-se no servidor de unlock pelo certmgr.msc e exporta-se em duas partes: o .cer com a chave pública, para a GPO, e o .pfx com a privada, para o servidor.
Num laboratório, ou numa PME sem PKI, o New-SelfSignedCertificate cria o certificado com os atributos exigidos:
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=BitLocker Network Unlock certificate" -Provider "Microsoft Software Key Storage Provider" -KeyUsage KeyEncipherment -KeyUsageProperty Decrypt,Sign -KeyLength 2048 -HashAlgorithm sha512 -TextExtension @("1.3.6.1.4.1.311.21.10={text}OID=1.3.6.1.4.1.311.67.1.1","2.5.29.37={text}1.3.6.1.4.1.311.67.1.1")
O comando devolve o thumbprint do novo certificado. Copie-o, porque identifica o certificado na configuração de subredes do passo 5.
⚠️ O import no servidor não se faz no contentor Personal. Abra o certlm.msc no servidor de unlock e importe o .pfx no contentor BitLocker Drive Encryption Network Unlock, em Certificates (Local Computer). É exactamente aí que o provider do WDS procura a chave privada.
3. Passo 2 — Distribuir o Certificado por GPO
Do lado dos clientes, o certificado público chega por Group Policy (GPO) e é essa distribuição que liga os protectors ao servidor de unlock. No gpmc.msc, a configuração tem duas partes. A primeira activa a política base, em Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption: activar Require additional authentication at startup e escolher Require startup PIN with TPM ou Allow startup PIN with TPM. A Microsoft recomenda ligar o BitLocker com protectors TPM+PIN — é esse o par que o Network Unlock completa. Falta a segunda política, sem a qual o protector de rede nunca é criado: na sub-pasta Operating System Drives, activar Allow Network Unlock at startup — é esta política que escreve o valor OSManageNKP=1 que o passo 5 verifica no registo.
A segunda parte distribui o certificado. Copie o .cer para o controlador de domínio e, na GPO dos servidores, navegue até Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > BitLocker Drive Encryption Network Unlock Certificate. Clique com o botão direito, escolha Add Network Unlock Certificate e importe o ficheiro. A Microsoft documenta que só pode existir um certificado de Network Unlock de cada vez: para trocar, apague o actual antes de distribuir o novo.
No cliente, o certificado fica visível na chave de registo HKLM\Software\Policies\Microsoft\SystemCertificates\FVE_NKP. Só depois de um reinício, com a política activa e o certificado presente nesse contentor, é que o protector de rede é adicionado ao volume. Se a GPO demorar, corra gpupdate /force no servidor protegido e reinicie.
4. Passo 3 — Activar BitLocker com TPM+PIN no Servidor
No servidor a proteger, o BitLocker activa-se com o protector TPM+PIN. O PIN fica como segundo factor para os arranques fora da rede de unlock, por exemplo quando a máquina se desloca para outro edifício:
$pin = Read-Host -AsSecureString "PIN de arranque"
Enable-BitLocker -MountPoint "C:" -TpmAndPinProtector -Pin $pin -EncryptionMethod XtsAes256 -SkipHardwareTest\nAdd-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
O Enable-BitLocker com -TpmAndPinProtector cria só o protector TPM+PIN. O Add-BitLockerKeyProtector acrescenta o RecoveryPassword e devolve os 48 dígitos — anote-os e guarde-os num sítio separado do servidor, porque é esse o caminho de recuperação quando o TPM e o desbloqueio de rede falham em simultâneo. Faça o escrow da recovery password em AD DS ou Entra ID, como descreve a documentação de recuperação do BitLocker. Com a cifra concluída, a GPO aplicada e um reinício feito, confirme a lista de protectors no passo seguinte.
Aqui está o ponto que mais confunde em implementações: não existe nenhum cmdlet para adicionar o protector de rede. Quem procura um parâmetro Network Unlock no Enable-BitLocker ou no Add-BitLockerKeyProtector não o encontra. O BitLocker cria o protector sozinho, a partir da combinação de GPO activa com certificado presente na FVE_NKP, logo ao primeiro reinício depois de ambos estarem no sítio.
5. Passo 4 — Verificar o Protector e Testar o Desbloqueio
A verificação passa pelo manage-bde, a ferramenta de linha de comandos que acompanha o BitLocker em qualquer versão suportada:
manage-bde.exe -protectors -get C:
Na lista de protectors, o Network Unlock aparece como um protector do tipo TpmCertificate (9). É o identificador que a Microsoft usa na página de problemas conhecidos para confirmar que a configuração está correcta. Ao lado dele devem estar o TPM+PIN (listado como TpmPin) e o RecoveryPassword — e só estes. Um protector TPM simples na lista indica que o BitLocker foi ligado sem PIN, cenário em que o Network Unlock não se aplica. A mesma página pede duas confirmações no registo do cliente: o valor OSManageNKP igual a 1 em HKLM\SOFTWARE\Policies\Microsoft\FVE e uma entrada com o thumbprint do protector em HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\FVE_NKP\Certificates.
O teste prático tem dois cenários. Reinicie o servidor ligado por cabo à rede: o pré-arranque não deve pedir o PIN e o Windows deve chegar ao ecrã de logon sozinho. Desligue o cabo e reinicie: o desbloqueio de rede falha, o BitLocker cai para o protector seguinte e o ecrã TPM+PIN clássico aparece. Este segundo cenário é o comportamento desenhado pela Microsoft e é a prova de que o failover está vivo.
Se o primeiro cenário falhar, active o registo de debug do WDS, que está desligado por omissão:
wevtutil.exe sl Microsoft-Windows-Deployment-Services-Diagnostics/Debug /e:true
Depois do reinício de teste, compare o log BitLocker do cliente com o log Microsoft-Windows-Deployment-Services-Diagnostics-Debug do servidor. As mensagens mostram o thumbprint do certificado usado em cada lado, que é o ponto de desacordo mais comum. Um capture na placa de rede do servidor WDS, filtrado pelo IP do cliente, fecha o diagnóstico do lado da rede.
6. Passo 5 — Restringir Subredes no Servidor de Unlock
Por omissão, o servidor responde a qualquer cliente com certificado e protector válidos que troque DHCP com ele. Num ambiente com várias subredes, um ficheiro de política limita as origens dos desbloqueios. O ficheiro chama-se bde-network-unlock.ini e tem de ficar no mesmo directório que o provider do WDS, em %windir%\System32\Nkpprov.dll. Aplica-se a DHCP IPv4 e IPv6. As subredes declaram-se em CIDR:
[SUBNETS]
SUBNET1=10.185.250.0/24
SUBNET2=10.185.252.200/28
SUBNET3=2001:4898:a:2::/64
Uma secção por certificado, identificada pelo thumbprint sem espaços, fixa as subredes de onde esse certificado pode desbloquear:
[2158a767e1c14e88e27a4c0aee111d2de2eafe60]
SUBNET1
SUBNET3
Uma subrede comentada com ponto e vírgula fica excluída sem apagar a linha. Para desactivar um certificado por inteiro, uma linha DISABLED nessa secção chega. Dois avisos da Microsoft: thumbprints com espaços quebram a configuração e um ficheiro corrompido faz o provider parar de responder a todos os pedidos. Guarde uma cópia antes de editar e repita o teste de reinício do passo 4 depois da alteração.
7. Manutenção de Certificados e Desactivação
Certificados expiram e a substituição tem uma ordem própria. Gere o novo certificado, distribua-o pela mesma GPO e reinicie os clientes. Como só pode existir um certificado de cada vez, o antigo sai da GPO quando o novo entra. Os servidores que não receberem a GPO actualizada voltam a pedir o PIN no arranque, sintoma típico de replicação de GPO falhada ou de uma OU que ficou fora do filtro.
Para desligar o mecanismo, a Microsoft recomenda desactivar a política Allow Network Unlock at startup, o que apaga os protectors de Network Unlock nos clientes quando a política chega. Desinstalar ou remover o provider do WDS trata o lado do servidor. Apagar o store FVE_NKP no servidor também silencia as respostas, mas a Microsoft classifica essa via como condição de erro e método não suportado.
Erros Comuns
| Problema | Causa | Solução |
|---|---|---|
| O protector TpmCertificate (9) não aparece após o reinício | GPO não aplicada ou certificado ausente na FVE_NKP | Correr gpresult / RSOP, confirmar HKLM\Software\Policies\Microsoft\SystemCertificates\FVE_NKP e reiniciar |
| O servidor pede o PIN mesmo ligado à rede | Serviço WDSServer parado no servidor de unlock | Get-Service WDSServer e arranque do serviço, confirmando a feature instalada |
| Nenhum cliente desbloqueia com a rede activa | Certificado no contentor errado ou OID 1.3.6.1.4.1.311.67.1.1 ausente | Importar o .pfx em BitLocker Drive Encryption Network Unlock e recriar com o OID exigido |
| O unlock falha em servidores com várias placas de rede | A primeira placa enumerada está sem DHCP ou sem cabo | Configurar a primeira placa (normalmente a onboard) com DHCP e ligada à rede de arranque |
| Clientes deixam de desbloquear após actualizar o certificado | GPO desactualizada em parte dos servidores | Confirmar a nova GPO e replicação, reiniciar os clientes sem a política nova |
| Terceiro pedido DHCP sem resposta na troca de unlock | Servidor DHCP configurado como DHCP and BOOTP responde como BOOTP | Mudar o âmbito DHCP de DHCP and BOOTP para DHCP (caso documentado pela Microsoft num cenário com clientes Windows 8 e Windows Server 2012 — o mesmo ajuste aplica-se a âmbitos herdados dessas versões) |
Checklist
- [ ] Função WDS instalada e serviço WDSServer em execução
- [ ] Feature BitLocker Network Unlock instalada no servidor de unlock
- [ ] Servidor DHCP separado do WDS a servir a rede dos clientes
- [ ] Certificado com o OID 1.3.6.1.4.1.311.67.1.1 importado em certlm.msc no contentor BitLocker Drive Encryption Network Unlock
- [ ] GPO com Require additional authentication at startup e PIN com TPM permitido ou exigido
- [ ] Certificado público distribuído pela GPO BitLocker Drive Encryption Network Unlock Certificate
- [ ] BitLocker activo com TPM+PIN e recovery password guardada fora do servidor
- [ ] Protector TpmCertificate (9) visível em manage-bde -protectors -get C:
- [ ] Teste feito com reinício ligado à rede (sem PIN) e com o cabo desligado (pede PIN)
- [ ] bde-network-unlock.ini criado no directório do Nkpprov.dll se houver restrições de subrede
- [ ] Plano de rotação de certificados e registo WDS debug activo para troubleshooting
Artigos Relacionados
- BitLocker Enterprise com Intune em 2026: Implementação e Gestão para PME
- Hyper-V no Windows Server: Virtualização Prática para PME com PowerShell
- WSUS: Gestão de Patches no Windows Server 2025 em 2026