Luiz Henrique Lima Campos – Microsoft MVP

O Windows LAPS evoluiu de forma importante e hoje faz parte da estratégia de proteção de contas locais em ambientes Windows modernos. O recurso permite gerenciar a senha da conta de administrador local em dispositivos ingressados no Microsoft Entra ou no Active Directory, além de oferecer suporte ao backup da conta DSRM em controladores de domínio. Em ambientes corporativos, isso reduz o risco de reutilização de credenciais locais e melhora o controle sobre rotação, recuperação e suporte.
Na prática, a implementação deve começar por uma decisão simples: qual será a origem de gerenciamento da política. Para dispositivos gerenciados com Intune, o caminho mais natural é usar a política de Account protection. Para servidores e estações ingressados no Active Directory tradicional, o caminho mais direto continua sendo a GPO do próprio Windows LAPS. O ponto importante é não misturar fontes sem planejamento, porque a política baseada em CSP tem precedência sobre outras origens de configuração.
Ponto de atenção: cada dispositivo faz backup para um único diretório. Por isso, o tipo de backup precisa estar alinhado ao tipo de ingresso da máquina para evitar política aplicada sem resultado operacional.
Configuração com Intune
Quando a meta é padronizar a proteção de contas locais em Windows 11 e servidores com gestão moderna, o Intune simplifica bastante o processo. A criação da política fica centralizada em Endpoint security > Account protection, usando o perfil Local admin password solution (Windows LAPS). Esse fluxo permite definir requisitos de senha, diretório de backup, rotação, ações pós-autenticação e, em versões suportadas, os recursos de Automatic Account Management.
A Figura 1 mostra o ponto de criação dessa política no Intune. Esse passo define a origem de gerenciamento da configuração. Em ambientes híbridos, é recomendável evitar políticas conflitantes entre Intune e GPO para não gerar comportamento inconsistente no dispositivo.

Figura 1 — Criação da política Windows LAPS em Endpoint security > Account protection no Intune.

Depois da criação do perfil, o ajuste mais sensível é a escolha do Backup Directory. Esse campo determina se a senha será armazenada no Microsoft Entra ID, no Active Directory ou se a funcionalidade ficará desabilitada. Esse é o ponto que mais gera erro de implementação: quando o tipo de diretório escolhido não é compatível com o tipo de ingresso do dispositivo, a política pode até ser recebida, mas o backup não acontece com sucesso.
A Figura 2 destaca essa configuração. Para estações e notebooks modernos, o caminho mais comum é usar backup no Microsoft Entra. Para servidores ou equipamentos ainda mais dependentes do domínio on-premises, o backup no Active Directory continua sendo bastante útil, especialmente quando a recuperação e a governança da conta local ainda fazem parte do modelo tradicional de operação.

Depois da criação do perfil, o ajuste mais sensível é a escolha do Backup Directory. Esse campo determina se a senha será armazenada no Microsoft Entra ID, no Active Directory ou se a funcionalidade ficará desabilitada. Esse é o ponto que mais gera erro de implementação: quando o tipo de diretório escolhido não é compatível com o tipo de ingresso do dispositivo, a política pode até ser recebida, mas o backup não acontece com sucesso.
A Figura 2 destaca essa configuração. Para estações e notebooks modernos, o caminho mais comum é usar backup no Microsoft Entra. Para servidores ou equipamentos ainda mais dependentes do domínio on-premises, o backup no Active Directory continua sendo bastante útil, especialmente quando a recuperação e a governança da conta local ainda fazem parte do modelo tradicional de operação.

Figura 2 — Definição do Backup Directory na política do Windows LAPS no Intune.

Boa prática: mantenha apenas uma política de LAPS por dispositivo sempre que possível. Políticas concorrentes podem gerar conflito de configuração, especialmente quando definem contas diferentes ou parâmetros de rotação incompatíveis.
Configuração por GPO no Active Directory
Em ambientes mais tradicionais, a GPO continua sendo a forma mais direta de administrar o Windows LAPS em dispositivos ingressados no domínio. O caminho da política fica em Computer Configuration > Administrative Templates > System > LAPS. A partir daí, a equipe consegue definir conta administrada, tamanho e complexidade de senha, ações pós-autenticação, histórico criptografado e opções específicas de Active Directory.
A Figura 3 mostra a área da GPO onde essas definições ficam disponíveis. Esse caminho é especialmente relevante para Windows Server 2025, porque permite manter o controle de contas locais e, quando necessário, também evoluir para cenários como gerenciamento da senha DSRM em controladores de domínio.

Boa prática: mantenha apenas uma política de LAPS por dispositivo sempre que possível. Políticas concorrentes podem gerar conflito de configuração, especialmente quando definem contas diferentes ou parâmetros de rotação incompatíveis.
Configuração por GPO no Active Directory
Em ambientes mais tradicionais, a GPO continua sendo a forma mais direta de administrar o Windows LAPS em dispositivos ingressados no domínio. O caminho da política fica em Computer Configuration > Administrative Templates > System > LAPS. A partir daí, a equipe consegue definir conta administrada, tamanho e complexidade de senha, ações pós-autenticação, histórico criptografado e opções específicas de Active Directory.
A Figura 3 mostra a área da GPO onde essas definições ficam disponíveis. Esse caminho é especialmente relevante para Windows Server 2025, porque permite manter o controle de contas locais e, quando necessário, também evoluir para cenários como gerenciamento da senha DSRM em controladores de domínio.

Figura 3 — Nó LAPS no Group Policy Management Editor para dispositivos ingressados no Active Directory.

Aqui existe um detalhe importante de arquitetura: se o domínio ainda estiver em nível funcional anterior a 2016, não será possível habilitar a criptografia da senha do Windows LAPS no Active Directory. Outro cuidado prático é o Central Store: o arquivo LAPS.admx não é copiado automaticamente para o repositório central só porque o sistema operacional foi atualizado, então esse ajuste deve ser tratado como parte do processo de implantação da política.
O que revisar depois da aplicação da política
• Conta gerenciada — validar se a conta definida realmente existe no dispositivo quando não se usa o modo automático.
• Tipo de backup — confirmar se Microsoft Entra ou Active Directory foi escolhido de acordo com o tipo de join.
• Conflitos — revisar relatórios do Intune e origem de política para evitar sobreposição entre CSP, GPO ou legado.
• Permissões de leitura e rotação — garantir que o time de suporte tenha apenas os direitos necessários para visualizar ou rotacionar a senha.
• Automatic Account Management — lembrar que esse recurso está disponível em Windows 11 24H2 e versões posteriores, o que muda a forma de tratar contas locais.
Conclusão
O Windows LAPS se consolidou como uma camada prática de proteção para ambientes Windows atuais. Em Windows 11, o caminho com Intune tende a ser o mais natural. Em Windows Server 2025 e em cenários fortemente integrados ao domínio, a GPO continua extremamente relevante. O ponto central é alinhar origem de política, tipo de backup, permissões e validação pós-implantação para que o LAPS funcione como redução real de risco no ambiente.

O ponto mais interessante no Windows Server 2025 é que o Azure Arc Setup já faz parte da experiência do próprio sistema. Em vez de começar sempre por script ou por um fluxo externo, o administrador já encontra um caminho visual para iniciar a conexão do servidor com o Azure Arc e validar rapidamente se o host está pronto para entrar na camada híbrida de gerenciamento.
Na prática, isso ajuda bastante em cenários em que a equipe precisa padronizar a entrada de servidores físicos ou virtuais fora do Azure. O ganho não está apenas em abrir um assistente gráfico, mas em reduzir fricção operacional logo no início do processo. Quando esse onboarding é tratado com o mínimo de governança desde o começo, fica mais simples organizar recurso, escopo administrativo, conectividade e manutenção do agente.
A primeira validação que costuma valer a pena é confirmar se o recurso está disponível no próprio sistema. A Figura 1 mostra exatamente esse ponto: o ícone do Azure Arc na bandeja do sistema e o atalho para iniciar o Azure Arc Setup. Esse detalhe é pequeno na interface, mas muito útil no dia a dia porque reduz o tempo entre a validação do servidor e o começo do onboarding.

Figura 1 — Atalho do Azure Arc Setup na bandeja do Windows Server 2025.
O que revisar antes de avançar

Antes de seguir para a conexão, eu considero quatro revisões simples como as mais importantes: saída pela porta TCP 443, assinatura e resource group já definidos, padrão de nome e tags do recurso e clareza sobre quem vai apenas visualizar e quem realmente vai administrar o servidor depois da conexão. Esse cuidado evita que a máquina entre no Azure Arc sem contexto administrativo ou fora do padrão do ambiente.
• Conectividade de saída: confirmar comunicação HTTPS pela porta TCP 443.
• Estrutura do recurso: definir subscription, resource group e região antes do onboarding.
• Padronização: aplicar convenção de nome e tags para facilitar filtro e governança.
• Acesso administrativo: separar desde o início quem terá visibilidade e quem terá administração.
Com essa base revisada, o assistente embutido no Windows Server 2025 passa a fazer mais sentido. A Figura 2 mostra a tela inicial do Azure Arc Setup. Nessa etapa, o fluxo deixa claro o objetivo do onboarding e prepara o servidor para o registro no Azure Arc, que é justamente a fundação necessária para recursos posteriores de gestão, segurança e atualização.

Antes de seguir para a conexão, eu considero quatro revisões simples como as mais importantes: saída pela porta TCP 443, assinatura e resource group já definidos, padrão de nome e tags do recurso e clareza sobre quem vai apenas visualizar e quem realmente vai administrar o servidor depois da conexão. Esse cuidado evita que a máquina entre no Azure Arc sem contexto administrativo ou fora do padrão do ambiente.
• Conectividade de saída: confirmar comunicação HTTPS pela porta TCP 443.
• Estrutura do recurso: definir subscription, resource group e região antes do onboarding.
• Padronização: aplicar convenção de nome e tags para facilitar filtro e governança.
• Acesso administrativo: separar desde o início quem terá visibilidade e quem terá administração.
Com essa base revisada, o assistente embutido no Windows Server 2025 passa a fazer mais sentido. A Figura 2 mostra a tela inicial do Azure Arc Setup. Nessa etapa, o fluxo deixa claro o objetivo do onboarding e prepara o servidor para o registro no Azure Arc, que é justamente a fundação necessária para recursos posteriores de gestão, segurança e atualização.

Figura 2 — Tela inicial do Azure Arc Setup embutido no Windows Server 2025.

O que vale validar depois da conexão
Depois que o servidor entra no Azure Arc, o ideal é não encerrar o trabalho ali. O primeiro ajuste é revisar se o recurso foi criado no lugar certo, com identificação coerente e dentro do escopo administrativo planejado. O segundo é confirmar a saúde do Connected Machine agent, porque ele passa a ser parte permanente da operação. O terceiro é validar se a conectividade e as políticas de saída continuam íntegras depois da conexão, principalmente em ambientes com proxy, inspeção ou regras de segurança mais restritivas.
Outro ponto importante é lembrar que esse fluxo é mais útil para servidores fora do Azure. Quando a máquina já está rodando dentro do Azure, o onboarding pelo Azure Arc Setup não é necessário. Em ambientes híbridos de verdade, porém, essa experiência embutida no Windows Server 2025 reduz bastante a fricção para incluir servidores locais ou hospedados em outros provedores dentro da mesma camada de gerenciamento.
Conclusão
No meu ponto de vista, o Azure Arc Setup embutido no Windows Server 2025 não vale apenas pela conveniência visual. O maior benefício é aproximar o onboarding do fluxo real de administração do servidor e tornar mais natural a entrada da máquina em uma estratégia híbrida mais organizada. Quando a equipe combina esse ponto de entrada com uma revisão mínima de rede, organização e acesso, o processo fica mais limpo, mais previsível e muito mais fácil de sustentar em escala.

O que vale validar depois da conexão
Depois que o servidor entra no Azure Arc, o ideal é não encerrar o trabalho ali. O primeiro ajuste é revisar se o recurso foi criado no lugar certo, com identificação coerente e dentro do escopo administrativo planejado. O segundo é confirmar a saúde do Connected Machine agent, porque ele passa a ser parte permanente da operação. O terceiro é validar se a conectividade e as políticas de saída continuam íntegras depois da conexão, principalmente em ambientes com proxy, inspeção ou regras de segurança mais restritivas.
Outro ponto importante é lembrar que esse fluxo é mais útil para servidores fora do Azure. Quando a máquina já está rodando dentro do Azure, o onboarding pelo Azure Arc Setup não é necessário. Em ambientes híbridos de verdade, porém, essa experiência embutida no Windows Server 2025 reduz bastante a fricção para incluir servidores locais ou hospedados em outros provedores dentro da mesma camada de gerenciamento.
Conclusão
No meu ponto de vista, o Azure Arc Setup embutido no Windows Server 2025 não vale apenas pela conveniência visual. O maior benefício é aproximar o onboarding do fluxo real de administração do servidor e tornar mais natural a entrada da máquina em uma estratégia híbrida mais organizada. Quando a equipe combina esse ponto de entrada com uma revisão mínima de rede, organização e acesso, o processo fica mais limpo, mais previsível e muito mais fácil de sustentar em escala.

Na minha visão, uma das mudanças mais interessantes do Windows Server 2025 é a forma como o Azure Arc entra de maneira mais natural na rotina do administrador. O sistema já traz o Azure Arc Setup como recurso integrado e, com isso, o onboarding híbrido deixa de parecer um processo separado da administração do servidor. Para mim, esse detalhe faz diferença porque reduz atrito logo no primeiro contato com a gestão híbrida.
Eu gosto desse modelo porque ele aproxima o time de operações de uma experiência mais simples. Em vez de depender apenas de script, procedimento paralelo ou documentação dispersa, eu consigo iniciar o assistente de forma gráfica e seguir um fluxo mais direto. No Windows Server 2025, esse recurso fica habilitado por padrão e pode ser aberto pelo ícone da bandeja do sistema, pelo menu Iniciar ou pelo Server Manager, o que torna o processo bem mais acessível no dia a dia.
O ponto principal, para mim, não é apenas registrar o servidor no portal. O valor real está em trazer máquinas que continuam on-premises para uma camada de governança mais moderna. Quando um servidor entra no Azure Arc, ele passa a ser tratado dentro de um modelo de administração que conversa melhor com inventário, organização, políticas e serviços de gerenciamento do Azure. Ou seja: o workload continua onde está, mas a administração ganha mais consistência.
Eu vejo isso como um caminho muito prático para empresas que ainda não vão migrar tudo para a nuvem, mas precisam elevar visibilidade e controle. Em muitos ambientes, o primeiro ganho não é técnico demais nem teórico demais: é operacional. Fica mais fácil padronizar onboarding, organizar servidores por grupo, aplicar uma convenção de tags, revisar permissões e preparar a base para recursos complementares de atualização, segurança e monitoramento.
Outro ponto que eu considero importante é o efeito de continuidade. O Azure Arc não precisa ser visto só como um cadastro de servidor, e sim como uma porta de entrada para uma operação híbrida mais madura. No próprio Windows Server 2025, por exemplo, a Microsoft já posiciona o Hotpatch para máquinas conectadas ao Azure Arc, o que mostra como a conexão híbrida está cada vez mais ligada à estratégia de manutenção moderna do sistema operacional.
O que eu observaria antes de conectar um servidor
• Definir em qual subscription, resource group e padrão de tags esse servidor vai entrar.
• Revisar RBAC para que a equipe certa tenha visibilidade e permissão sem excesso de privilégio.
• Validar conectividade de saída e requisitos básicos para o onboarding funcionar sem retrabalho.
• Começar com um piloto controlado antes de expandir para ambientes críticos ou em escala.
Se eu tivesse que resumir, eu diria assim: o servidor não deixa de ser on-premises, mas a administração passa a ter uma camada muito mais atual. Para quem trabalha com Windows Server e quer modernizar sem quebrar a operação, eu vejo o Azure Arc no Windows Server 2025 como um excelente ponto de partida.
Leitura prática: eu enxergo o Azure Arc Setup no Windows Server 2025 como uma forma de tornar a gestão híbrida menos artesanal, mais previsível e mais alinhada ao ecossistema Windows.

Imagens de configuração

Imagem 1 — Atalho do Azure Arc Setup no Windows Server 2025, com acesso rápido pelo ícone na bandeja do sistema.

Imagem 2 — Tela inicial do assistente do Azure Arc Setup, destacando a experiência guiada de onboarding.

Imagem 3 — Ações iniciais do assistente, mostrando um fluxo simples para começar a conexão do servidor.

O Windows LAPS evoluiu bastante e, na minha visão, uma das configurações mais importantes hoje é a de post-authentication actions. Muita gente foca apenas em rotação de senha, comprimento e complexidade, mas esquece do momento posterior ao uso da conta local administrada. É exatamente aqui que essa configuração ajuda, porque ela reduz a janela de exposição depois que a senha foi usada com sucesso.
Em vez de deixar a credencial continuar válida por muito tempo depois da autenticação, o Windows LAPS permite definir ações automáticas para encerrar esse ciclo com mais segurança. Dependendo da política aplicada, o sistema pode apenas resetar a senha ou combinar o reset com logoff da conta gerenciada e outras ações adicionais. Para ambientes mais sensíveis, isso ajuda bastante a reduzir abuso de credenciais locais compartilhadas.
Quando a administração é feita pelo Intune, a configuração fica centralizada dentro da política de Windows LAPS. A Figura 1 mostra esse ponto de configuração no perfil de Account protection. Esse modelo funciona muito bem quando a organização já opera Windows 11 e servidores com gestão moderna, porque a revisão da política fica mais simples e a distribuição ganha mais previsibilidade.

Figura 1 — Exemplo de configuração do Windows LAPS via Intune.

Em ambientes com Active Directory tradicional, o mesmo conceito pode ser aplicado por Group Policy. A Figura 2 mostra a área administrativa da política do Windows LAPS. Esse cenário continua fazendo muito sentido quando a gestão do parque ainda depende de GPO ou quando o objetivo é manter alinhamento com servidores e estações em modelo híbrido.

Em ambientes com Active Directory tradicional, o mesmo conceito pode ser aplicado por Group Policy. A Figura 2 mostra a área administrativa da política do Windows LAPS. Esse cenário continua fazendo muito sentido quando a gestão do parque ainda depende de GPO ou quando o objetivo é manter alinhamento com servidores e estações em modelo híbrido.

Figura 2 — Exemplo da configuração do Windows LAPS por Group Policy.

Um ponto importante é entender que as post-authentication actions não servem apenas para ‘trocar a senha depois’. Elas existem para limitar o tempo de uso prático daquela credencial. Quando bem configuradas, ajudam a diminuir o risco de reutilização da senha local em sessões que já deveriam ter sido encerradas. Em versões mais novas, como Windows Server 2025 e Windows 11 24H2, a Microsoft também adicionou uma opção mais forte, que combina reset de senha, logoff da conta gerenciada e encerramento de processos remanescentes.
Na prática, eu gosto de validar essa configuração em três frentes. A primeira é compatibilidade: confirmar se o sistema suporta a opção escolhida. A segunda é impacto operacional: entender se logoff, reinício ou encerramento de processo pode atrapalhar rotinas administrativas legítimas. A terceira é observabilidade: revisar eventos do Windows LAPS depois da implantação para confirmar se a política foi aplicada como esperado.
Do ponto de vista de desenho, a melhor escolha quase nunca é a mais agressiva por padrão. O ideal é alinhar o nível da ação com o perfil do equipamento. Em servidores críticos, por exemplo, vale avaliar com cuidado qualquer ação que possa interromper sessão ou processo ainda em uso. Já em estações administrativas e dispositivos com uso menos sensível, políticas mais restritivas costumam fazer bastante sentido.
O que eu costumo revisar antes de habilitar
• build do Windows e versão realmente suportadas para a ação desejada
• origem da política, evitando conflito entre Intune, CSP e GPO
• impacto da ação em sessões administrativas legítimas
• canal de backup da senha e grupo autorizado para leitura ou decriptação
• eventos do log operacional do Windows LAPS após a implantação
Conclusão
No meu ponto de vista, post-authentication actions é uma das configurações mais valiosas do Windows LAPS quando a meta é sair do básico e realmente endurecer o uso da conta local administrada. O recurso fica ainda mais interessante nas versões atuais do Windows Server e do Windows 11, porque entrega opções mais fortes de contenção após o uso da senha. Quando bem planejada, essa política melhora a segurança sem transformar a operação em um problema desnecessário.

Um ponto importante é entender que as post-authentication actions não servem apenas para ‘trocar a senha depois’. Elas existem para limitar o tempo de uso prático daquela credencial. Quando bem configuradas, ajudam a diminuir o risco de reutilização da senha local em sessões que já deveriam ter sido encerradas. Em versões mais novas, como Windows Server 2025 e Windows 11 24H2, a Microsoft também adicionou uma opção mais forte, que combina reset de senha, logoff da conta gerenciada e encerramento de processos remanescentes.
Na prática, eu gosto de validar essa configuração em três frentes. A primeira é compatibilidade: confirmar se o sistema suporta a opção escolhida. A segunda é impacto operacional: entender se logoff, reinício ou encerramento de processo pode atrapalhar rotinas administrativas legítimas. A terceira é observabilidade: revisar eventos do Windows LAPS depois da implantação para confirmar se a política foi aplicada como esperado.
Do ponto de vista de desenho, a melhor escolha quase nunca é a mais agressiva por padrão. O ideal é alinhar o nível da ação com o perfil do equipamento. Em servidores críticos, por exemplo, vale avaliar com cuidado qualquer ação que possa interromper sessão ou processo ainda em uso. Já em estações administrativas e dispositivos com uso menos sensível, políticas mais restritivas costumam fazer bastante sentido.
O que eu costumo revisar antes de habilitar
• build do Windows e versão realmente suportadas para a ação desejada
• origem da política, evitando conflito entre Intune, CSP e GPO
• impacto da ação em sessões administrativas legítimas
• canal de backup da senha e grupo autorizado para leitura ou decriptação
• eventos do log operacional do Windows LAPS após a implantação
Conclusão
No meu ponto de vista, post-authentication actions é uma das configurações mais valiosas do Windows LAPS quando a meta é sair do básico e realmente endurecer o uso da conta local administrada. O recurso fica ainda mais interessante nas versões atuais do Windows Server e do Windows 11, porque entrega opções mais fortes de contenção após o uso da senha. Quando bem planejada, essa política melhora a segurança sem transformar a operação em um problema desnecessário.