Neste artigo, o foco é o cenário em que o Windows LAPS grava a senha no Active Directory e a equipe precisa decidir quando manter o armazenamento em texto protegido pelo AD e quando ativar a criptografia, além de definir corretamente quem poderá descriptografar a senha.
Quando o Windows LAPS é usado em ambiente com Active Directory, uma das decisões mais importantes não é apenas qual conta local será gerenciada, mas também como essa senha será armazenada e quem poderá recuperá-la. Essa decisão muda bastante o nível de controle operacional do ambiente. Em cenários mais maduros, faz mais sentido trabalhar com criptografia habilitada e com um grupo bem definido de administradores responsáveis pela leitura da senha, em vez de deixar a recuperação aberta a um conjunto amplo de permissões.
A escolha começa no parâmetro Backup Directory. Ele define se a senha será enviada para o Microsoft Entra ID, para o Active Directory ou se o recurso ficará desabilitado. Esse ponto é importante porque as configurações ligadas à criptografia do Active Directory só passam a ter efeito quando o backup está apontado para AD. Se o diretório de backup estiver configurado para Microsoft Entra ID, essas opções específicas de criptografia do AD deixam de ser relevantes para aquele dispositivo.
A Figura 1 mostra esse ponto dentro da configuração por Intune. Aqui a escolha do Backup Directory define a base do comportamento do Windows LAPS. Em outras palavras, antes de discutir criptografia, decryptors ou histórico de senha, o primeiro passo é confirmar que o dispositivo realmente está enviando a senha para o Active Directory.

Figura 1 — Seleção do Backup Directory na política do Windows LAPS.

Depois que o backup para Active Directory está definido, o próximo tema é a criptografia. No Windows LAPS, a criptografia da senha armazenada no AD é o caminho mais forte para reduzir exposição administrativa. Quando esse modo está ativo, a recuperação continua possível, mas a senha deixa de depender apenas de permissões de leitura do objeto. Ela passa a depender também da definição correta de quem está autorizado a descriptografar o valor protegido.
É justamente aqui que entra a configuração de authorized password decryptors. Em vez de assumir que qualquer grupo com leitura do atributo terá acesso prático à senha, o Windows LAPS permite determinar um usuário ou grupo específico para descriptografia. Se essa configuração não for definida, o comportamento padrão é usar o grupo Domain Admins do domínio do dispositivo. Isso funciona, mas nem sempre é o melhor desenho quando a organização quer separar administração de domínio de operações de suporte ou de administração de estações e servidores.
Outro ponto importante é que o Windows LAPS trabalha com apenas um principal de descriptografia por vez. Se houver necessidade de atender várias equipes, a abordagem mais limpa é criar um grupo de segurança dedicado e colocar dentro dele os administradores ou times que realmente precisam desse acesso. Na prática, isso evita espalhar privilégio e mantém a governança mais clara.
A Figura 2 mostra esse conjunto de opções na GPO do Windows LAPS. É nesse ponto que ficam as configurações de Enable password encryption e Configure authorized password decryptors, que normalmente devem ser avaliadas em conjunto no cenário com Active Directory.

Figura 2 — Políticas de criptografia e authorized password decryptors na GPO do Windows LAPS.

Quando a criptografia está habilitada, o desenho operacional também fica mais consistente para auditoria. A organização passa a ter uma camada adicional de proteção sobre a senha armazenada no AD e pode justificar com mais clareza quem realmente tem direito de recuperação. Isso é especialmente útil em ambientes com servidores sensíveis, estações administrativas e equipes terceirizadas de suporte.
Também vale observar um detalhe operacional importante: a definição do principal autorizado à descriptografia precisa estar correta e ser resolvível pelo dispositivo. Se o nome ou SID configurado estiver inválido, o comportamento de fallback tende a voltar para o grupo Domain Admins. Em ambiente real, isso pode fazer a política parecer aplicada, mas com um resultado de segurança diferente do esperado.
Outro ponto que costuma ser ignorado é o histórico de senha. No cenário do Active Directory, o histórico criptografado só faz sentido quando a criptografia está habilitada. Sem criptografia, não há histórico protegido de senhas antigas. Isso significa que, se o objetivo da equipe é combinar rotação com capacidade controlada de consulta a versões anteriores, a configuração de criptografia deixa de ser opcional e passa a ser parte do desenho.
Na prática, o fluxo mais seguro costuma seguir esta ordem: primeiro definir o Backup Directory corretamente; depois habilitar criptografia para o cenário de Active Directory; em seguida configurar um grupo dedicado para descriptografia; por fim validar leitura, rotação e escopo de acesso. Esse encadeamento reduz retrabalho e evita que a implantação do Windows LAPS fique funcional, mas sem o nível de controle que a organização realmente pretendia.
Pontos de validação depois da configuração
• confirmar se o Backup Directory está realmente apontando para Active Directory
• validar se a criptografia de senha foi habilitada na política ativa
• confirmar se o grupo ou usuário configurado como decryptor é resolvível pelo dispositivo
• verificar se o acesso à recuperação da senha ficou restrito ao escopo esperado
• testar rotação e consulta da senha para garantir que o comportamento final corresponde ao desenho administrativo
Conclusão
No Windows LAPS, escolher o diretório de backup é apenas o começo. Quando a organização decide usar Active Directory, a discussão de segurança passa imediatamente por criptografia e por authorized password decryptors. Trabalhar esses dois pontos em conjunto ajuda a transformar uma implantação funcional em uma implantação realmente governada, com menos exposição e com uma separação de privilégios mais coerente para ambientes Windows Server 2025 e Windows 11.