Luiz Henrique Lima Campos – Microsoft MVP

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.

Uma das dúvidas mais comuns em projetos com Windows LAPS é entender o que realmente dispara a troca da senha da conta administradora local. Muita gente olha apenas para o Password Age Days e assume que toda rotação depende exclusivamente desse valor. Na prática, o comportamento é mais amplo. O Password Age Days define a janela normal de expiração, mas o LAPS também permite rotação imediata em cenários específicos, como testes, contenção de incidente ou troca forçada após uso administrativo.
Esse ponto é importante porque ambientes híbridos normalmente misturam Windows Server 2025, Windows 11, Intune e Active Directory. Quando a equipe não separa rotação agendada de rotação sob demanda, a operação fica confusa: a política parece “não obedecer” o prazo configurado, quando na verdade outro mecanismo foi acionado para substituir a senha antes do vencimento natural.
Onde essa configuração aparece no Intune
A Figura 1 mostra a área de configuração do Windows LAPS no Intune. É nessa família de definições que a equipe ajusta o comportamento do recurso, inclusive o diretório de backup e os parâmetros que influenciam a rotina de rotação. Mesmo quando a administração é feita por nuvem, a leitura correta da política continua sendo essencial para diferenciar o que é expiração programada do que é ação manual ou excepcional.

Figura 1 — Área de configuração do Windows LAPS no Intune.

Em um desenho mais organizado, o Password Age Days deve ser tratado como a base da rotação periódica. Ele determina o intervalo máximo para a senha continuar válida antes da próxima troca automática. Isso ajuda a manter previsibilidade operacional e reduz o risco de a mesma senha local permanecer ativa por tempo excessivo. Ao mesmo tempo, esse prazo não elimina a possibilidade de uma rotação antecipada, e esse é justamente o ponto que merece atenção em operações mais maduras.
O que muda quando a rotação é forçada
Quando existe necessidade de trocar a senha imediatamente, o LAPS oferece meios próprios para isso. Em vez de esperar a próxima expiração, a senha pode ser rotacionada de forma antecipada, o que é especialmente útil depois de uma atividade administrativa sensível, em um teste de segurança ou após suspeita de exposição de credencial. Esse comportamento não substitui a política de expiração; ele atua como exceção controlada para responder a uma necessidade operacional específica.
No cenário com Active Directory tradicional, a equipe também precisa observar permissões delegadas e o modo de administração escolhido. Já no cenário gerenciado por nuvem, o importante é validar se a origem da política está clara e se não existe concorrência desnecessária entre CSP/Intune e GPO. Quando a origem fica ambígua, o troubleshooting costuma virar perda de tempo.
Como validar o mesmo comportamento no GPO
A Figura 2 mostra a visão das políticas do Windows LAPS no Editor de Diretiva de Grupo. Esse ponto continua relevante em ambientes que ainda administram servidores e estações por GPO. A recomendação prática é evitar configurar parâmetros equivalentes em duas origens diferentes sem necessidade clara. Quando o objetivo for padronização, o melhor caminho é definir a fonte principal de gerenciamento e validar o resultado no dispositivo, em vez de confiar apenas no que foi configurado no console.

Figura 2 — Políticas do Windows LAPS disponíveis no Editor de Diretiva de Grupo.

O que vale revisar depois da implantação

1. Origem da política. Confirmar se o dispositivo está recebendo a política pela origem esperada, sem concorrência desnecessária.
2. Janela de expiração. Revisar se o Password Age Days está coerente com o perfil de risco do servidor ou da estação.
3. Rotação antecipada. Validar quem pode forçar uma troca imediata e em quais cenários isso será usado.
4. Backup da senha. Confirmar se o diretório de backup configurado é o mesmo planejado para o ambiente.
5. Comprovação operacional. Verificar logs, data de expiração e comportamento real do dispositivo após a aplicação da política.
   Conclusão
   Em projetos com Windows LAPS, entender a diferença entre rotação programada e rotação imediata evita boa parte dos erros de interpretação. O Password Age Days continua sendo uma configuração central, mas ele não é o único elemento que influencia a troca da senha. Quando esse conceito fica claro, a administração de Windows Server 2025 e Windows 11 passa a ser mais previsível, o troubleshooting fica mais simples e a equipe consegue usar o LAPS de forma muito mais alinhada com o risco real do ambiente.

Em projetos com Windows Server 2025 e Windows 11 24H2, um dos erros mais comuns no Windows LAPS não está na rotação da senha em si, mas na definição do Backup Directory. Quando esse ponto é configurado sem critério, a política até parece correta, mas o resultado prático costuma ser confusão entre Intune, GPO e local de armazenamento da senha.

O Backup Directory é a configuração que define para onde a senha da conta administradora local será enviada. Na prática, a decisão costuma ficar entre Microsoft Entra ID e Windows Server Active Directory. Esse detalhe parece simples, mas ele influencia diretamente a política aplicável, o local de consulta da senha, o modelo de administração e até a forma como a equipe valida se o LAPS realmente entrou em produção.
Quando o gerenciamento é feito pelo Intune, a configuração aparece no perfil do Windows LAPS dentro da política de proteção de conta. É nesse ponto que a definição precisa ser objetiva: o dispositivo vai enviar a senha para o Entra ID ou para o Active Directory? Misturar a expectativa operacional nesse momento costuma gerar troubleshooting desnecessário depois.

Figura 1 — Definição do Backup Directory em uma política do Windows LAPS no Intune.

O ponto mais importante aqui é manter coerência entre origem da política e destino do backup. Se o dispositivo será administrado por Intune, a política baseada em CSP passa a ter precedência sobre outras fontes de configuração do Windows LAPS. Em outras palavras, quando existe configuração ativa via CSP, a expectativa deve ser validar o comportamento a partir desse modelo e não tentar combinar o mesmo dispositivo com uma lógica paralela de GPO para o mesmo conjunto de definições.
Onde a GPO ainda faz sentido
Em ambientes tradicionais ou híbridos com forte dependência de Active Directory, a GPO continua sendo uma opção válida para o Windows LAPS. O caminho administrativo permanece direto e bem conhecido pelas equipes de infraestrutura, especialmente quando o objetivo é manter a senha da conta local protegida e armazenada no diretório local da organização.
A Figura 2 mostra a área de configurações do Windows LAPS na GPO. Esse modelo continua útil quando a autoridade principal da política está no Active Directory. O problema começa quando o mesmo dispositivo recebe configurações concorrentes vindas de CSP e GPO. Nessa situação, o time pode perder tempo investigando uma política que aparentemente está configurada, mas que na prática foi ignorada.

Figura 2 — Configurações do Windows LAPS via Group Policy no Active Directory.

Como evitar conflito e política sem efeito

1. Escolher uma autoridade principal por dispositivo. Se o equipamento será gerenciado por Intune, a política de LAPS deve ser pensada nesse contexto. Se o cenário for AD tradicional, a GPO precisa ser tratada como fonte principal.
2. Definir o Backup Directory de acordo com o diretório real de destino. Não adianta esperar consulta no Entra ID se a política foi desenhada para Active Directory, e vice-versa.
3. Validar o local de recuperação da senha. A confirmação correta não é apenas ver a política aplicada, mas garantir onde a senha foi realmente armazenada e de onde ela será consultada pela equipe.
4. Evitar sobreposição desnecessária. Quando o mesmo dispositivo recebe configurações diferentes do mesmo recurso, o ambiente fica mais difícil de operar e de auditar.
   Observação importante para versões mais novas
   No ciclo mais recente do Windows, o Windows LAPS ganhou recursos adicionais nas versões mais novas do sistema. O modo de gerenciamento automático de conta e o suporte ampliado a passphrases, por exemplo, estão associados ao Windows 11 24H2 e ao Windows Server 2025 em diante. Por isso, em ambientes mistos, vale sempre separar o que é política básica de rotação do que é recurso mais novo disponível apenas nas versões atuais.
   Na prática, o desenho mais saudável é simples: um dispositivo, uma origem principal de política, um destino de backup bem definido e uma rotina clara de validação. Quando isso é respeitado, o Windows LAPS fica previsível, auditável e muito mais fácil de sustentar no dia a dia.

O Windows LAPS evoluiu bastante nas versões mais recentes do Windows, e um dos pontos que mais merecem atenção é o modo de gerenciamento automático de conta. Em vez de apenas girar a senha de uma conta já existente, esse modo permite que o próprio Windows LAPS assuma a configuração da conta local administrada, inclusive criação, nome, estado da conta e outras definições operacionais. Para ambientes que buscam reduzir scripts paralelos e padronizar a conta administrativa local, esse recurso se tornou especialmente interessante no Windows Server 2025 e no Windows 11 24H2.
O primeiro ponto importante é entender a diferença entre os dois modelos. No modo manual, o time de TI define quase tudo sobre a conta-alvo e o Windows LAPS fica responsável basicamente pela senha. Já no modo automático, o próprio recurso passa a controlar não só a senha, mas também aspectos da conta, como conta interna ou personalizada, nome ou prefixo, habilitar ou desabilitar a conta e aleatorização do nome. Essa capacidade existe apenas no Windows 11 24H2, Windows Server 2025 e versões posteriores.
A Figura 1 ilustra a configuração da política do Windows LAPS no Intune.

Nesse ponto, a definição do Backup Directory ajuda a estabelecer para onde a senha será enviada, mas o mais importante, do ponto de vista de arquitetura, é decidir qual será o plano de gerenciamento principal do dispositivo.

Nesse ponto, a definição do Backup Directory ajuda a estabelecer para onde a senha será enviada, mas o mais importante, do ponto de vista de arquitetura, é decidir qual será o plano de gerenciamento principal do dispositivo.

Figura 1 — Exemplo de política do Windows LAPS no Intune.
Na prática, o gerenciamento automático de conta faz mais sentido quando a organização quer diminuir dependência de tarefas paralelas para manter a conta local administrativa em conformidade. Nesse modo, o Windows LAPS pode administrar uma nova conta personalizada ou a conta Administrador interna, definir se ela ficará habilitada, randomizar nome e aplicar proteções adicionais contra alterações indevidas. Em ambientes mais sensíveis, manter a conta desabilitada até o momento de uso pode reduzir a superfície para password spray e outras tentativas de abuso.
Outro ponto importante é evitar mistura de mecanismos de política sem necessidade. Quando existe pelo menos uma configuração do Windows LAPS aplicada via CSP/Intune, as configurações aplicadas por GPO deixam de ser a política ativa naquele dispositivo. Isso não impede coexistência no ambiente, mas exige clareza sobre qual plano está governando cada grupo de máquinas.
A Figura 2 mostra o caminho das configurações do Windows LAPS no Group Policy Management Editor. Em ambientes ingressados no Active Directory, esse ponto continua sendo útil, principalmente quando a estratégia de administração do servidor ainda depende de GPO como plano principal.

Figura 2 — Configurações do Windows LAPS no Group Policy Management Editor.

Ao desenhar essa implantação, alguns cuidados ajudam bastante a evitar retrabalho:
• Escolher um único plano de política por cenário: Se o servidor ou endpoint será gerenciado por Intune/CSP, o ideal é manter esse caminho como fonte principal. Se o ambiente for orientado a Active Directory clássico, a GPO continua sendo uma abordagem válida.
• Separar modo manual de modo automático: No modo manual, a conta personalizada precisa existir antes da aplicação da política. No modo automático, o Windows LAPS assume a configuração da conta administrada.
• Definir o estado operacional da conta: Em ambientes mais restritivos, vale avaliar conta desabilitada por padrão e habilitação apenas quando houver necessidade operacional controlada.
• Padronizar nome, prefixo e convenção: Se houver uso de conta personalizada, padronizar nomenclatura ajuda auditoria, troubleshooting e leitura operacional do ambiente.
Conclusão
O gerenciamento automático de conta do Windows LAPS representa uma evolução importante porque tira da equipe uma parte da complexidade de manter a conta administrativa local bem controlada. No Windows Server 2025 e no Windows 11 24H2, esse recurso passa a fazer muito mais sentido em cenários que querem simplificar a operação, reduzir dependência de scripts e manter um padrão mais consistente entre servidores e estações. Quando a escolha entre Intune e GPO fica clara desde o início, a implantação tende a ser mais previsível e muito mais limpa operacionalmente.