Compartilhar via

Principais conceitos no Windows LAP

Conheça os conceitos básicos de design e segurança para a Solução de Senha de Administrador Local do Windows (LAPS do Windows), incluindo:

  • Arquitetura
  • Fluxo de cenário básico
  • Ciclo de processamento de política em tela de fundo
  • Senhas do Microsoft Entra
  • Senhas do Windows Server Active Directory
  • Redefinição de senha após autenticação
  • Proteção contra adulterações de senha da conta
  • Modo de segurança do Windows

Arquitetura da LAPS do Windows

A figura a seguir ilustra a arquitetura da LAPS do Windows:

Diagrama da arquitetura LAPS do Windows que mostra o dispositivo gerenciado, a ID do Microsoft Entra e o Active Directory do Windows Server.

O diagrama de arquitetura da LAPS do Windows tem vários componentes principais:

  • Administrador de TI: representa coletivamente as várias funções do administrador de TI que podem estar envolvidas em uma implantação do Windows LAPS. As funções do administrador de TI estão envolvidas com configuração de política, expiração ou recuperação de senhas armazenadas e a interação com dispositivos gerenciados.

  • Dispositivo gerenciado: representa um dispositivo adicionado ao Microsoft Entra ou ao Windows Server Active Directory no qual você deseja gerenciar uma conta de administrador local. O recurso é composto por alguns binários principais: laps.dll para lógica principal, lapscsp.dll para lógica do CSP (Provedor de Soluções na Nuvem) e lapspsh.dll para lógica de cmdlet do PowerShell. Você também pode configurar a LAPS do Windows usando Política de Grupo. A da LAPS do Windows responde às notificações de alteração de GPO (Objeto de Política de Grupo). O dispositivo gerenciado pode ser um controlador de domínio do Windows Server Active Directory e ser configurado para fazer backup de senhas de conta do DSRM (Modo de Reparo de Serviços de Diretório).

  • Windows Server Active Directory: uma implantação na infraestrutura local do Windows Server Active Directory.

  • Microsoft Entra ID: uma implantação do Microsoft Entra em execução na nuvem.

  • Microsoft Intune A solução preferencial de gerenciamento de política de dispositivo da Microsoft, também em execução na nuvem.

Fluxo de cenário básico

A primeira etapa em um cenário básico da LAPS do Windows é configurar a política dela para sua organização. É recomendável usar as seguintes opções de configuração:

  • Dispositivos ingressados no Microsoft Entra: use o Microsoft Intune.

  • dispositivos adicionados no Windows Server Active Directory: use a Política de Grupo.

  • Dispositivos ingressados híbridos do Microsoft Entra registrados no Microsoft Intune: use o Microsoft Intune.

Depois que o dispositivo gerenciado for configurado com uma política que habilita a LAPS do Windows, o dispositivo começará a gerenciar a senha da conta local configurada. Quando a senha expira, o dispositivo gera uma senha nova e aleatória que está em conformidade com os requisitos de comprimento e complexidade da política atual.

Quando uma nova senha é validada, o dispositivo armazena a senha no diretório configurado, no Windows Server Active Directory ou no Microsoft Entra ID. Um tempo de expiração de senha associado com base na configuração de vencimento de senha da política atual também é computado e armazenado no diretório. O dispositivo gira a senha automaticamente quando o tempo de expiração da senha é atingido.

Quando a senha da conta local for armazenada no diretório relevante, um administrador de TI autorizado poderá acessá-la. As senhas armazenadas no Microsoft Entra ID são protegidas por meio de um modelo de controle de acesso baseado em função. As senhas armazenadas no Windows Server Active Directory são protegidas por meio de ACLs (listas de controle de acesso) e também opcionalmente por meio de criptografia de senha.

Você pode girar a senha antes do tempo de expiração esperado normalmente. Gire uma senha antes de uma expiração agendada usando um dos seguintes métodos:

  • Gire manualmente a senha no próprio dispositivo gerenciado usando o cmdlet Reset-LapsPassword.
  • Invocando a ação Executar ResetPassword no CSP da LAPS do Windows.
  • Modificando o tempo de expiração da senha no diretório (aplica-se apenas ao Windows Server Active Directory).
  • Disparando a rotação automática quando a conta gerenciada for usada para autenticação no dispositivo gerenciado.

Ciclo de processamento de política em tela de fundo

A LAPS do Windows usa uma tarefa em tela de fundo que acorda a cada hora para processar a política ativa no momento. Essa tarefa não é implementada com uma tarefa do Agendador de Tarefas do Windows e não é configurável.

Quando a tarefa na tela de fundo é executada, ela executa o seguinte fluxo básico:

Diagrama de um fluxograma que descreve o ciclo de processamento em segundo plano da LAPS do Windows.

A diferença de chave óbvia entre o fluxo do Microsoft Entra ID e o fluxo do Windows Server Active Directory está relacionada à forma como o tempo de expiração da senha é verificado. Nos dois cenários, o tempo de expiração da senha é armazenado lado a lado com a senha mais recente no diretório.

No cenário do Microsoft Entra, o dispositivo gerenciado não sonda o Microsoft Entra ID. Em vez disso, o tempo de expiração da senha atual é mantido localmente no dispositivo.

No cenário do Windows Server Active Directory, o dispositivo gerenciado faz normalmente a sondagem do diretório para consultar o tempo de expiração da senha e atua quando a senha expira.

Iniciar manualmente o ciclo de processamento da política

A LAPS do Windows responde às notificações de alteração da Política de Grupo. Você pode iniciar manualmente o ciclo de processamento da política de duas maneiras:

  • Impondo uma atualização de Política de Grupo. Veja um exemplo:

    gpupdate.exe /target:computer /force

  • Execute o cmdlet Invoke-LapsPolicyProcessing. Esse método é preferencial porque tem mais escopo.

Dica

O Microsoft LAPS (Microsoft LAPS herdado) lançado anteriormente foi criado como uma CSE (Extensão do Lado do Cliente) da Política de Grupo (GPO). As CSEs da GPO são carregadas e invocadas em cada ciclo de atualização da Política de Grupo. A frequência do ciclo de sondagem do Microsoft LAPS herdado é a mesma que a frequência do ciclo de atualização da Política de Grupo. A LAPS do Windows não é criada como uma CSE, portanto, o ciclo de sondagem dela é embutido em código uma vez por hora. A LAPS do Windows não é afetada pelo ciclo de atualização da Política de Grupo.

Senhas do Microsoft Entra

Quando você faz backup de senhas para o Microsoft Entra ID, as senhas de conta local gerenciadas são armazenadas no objeto de dispositivo Microsoft Entra. O Windows LAPS faz a autenticação no Microsoft Entra ID usando a identidade do dispositivo gerenciado. Os dados armazenados no Microsoft Entra ID são altamente seguros, mas, para proteção extra, a senha é criptografada ainda mais antes de persistir. Essa camada de criptografia extra é removida antes que a senha seja retornada para clientes autorizados.

Por padrão, somente os membros das funções Administrador global, Administrador de dispositivos de nuvem e Administrador de Intune podem recuperar a senha de texto não criptografado.

Senhas do Windows Server Active Directory

As seções a seguir fornecem informações importantes sobre como usar a LAPS do Windows com o Windows Server Active Directory.

Segurança de senha

Quando você faz backup de senhas para o Windows Server Active Directory, as senhas da conta local gerenciada são armazenadas no objeto do computador. A LAPS do Windows protege essas senhas usando dois mecanismos:

  • ACLs
  • Senhas criptografadas

ACLs

A primeira linha de segurança de senha no Windows Server Active Directory usa as ACLs configuradas no objeto de computador que contém uma UO (Unidade Organizacional). As ACLs são herdadas para o próprio objeto de computador. Você pode especificar quem pode ler vários atributos de senha usando o Set-LapsADReadPasswordPermission cmdlet . Da mesma forma, você pode especificar quem pode ler e definir o atributo de tempo de expiração da senha usando o Set-LapsADResetPasswordPermission cmdlet .

Senhas criptografadas

A segunda linha de segurança de senha usa o recurso de criptografia de senha do Windows Server Active Directory. Para usar a criptografia de senha do Windows Server Active Directory, seu domínio deve ser executado no DFL (Nível Funcional de Domínio) do Windows Server 2016 ou posterior. Quando habilitada, a senha é criptografada pela primeira vez para que apenas uma entidade de segurança específica (um grupo ou usuário) possa descriptografá-la. A criptografia de senha ocorre no próprio dispositivo gerenciado antes que o dispositivo envie a senha para o diretório.

Importante

  • É altamente recomendável habilitar a criptografia de senha ao armazenar suas senhas da LAPS do Windows no Windows Server Active Directory.
  • A Microsoft não dá suporte à recuperação de senhas da LAPS descriptografadas anteriormente em um domínio executando um DFL anterior ao DFL do Windows Server 2016. A operação pode ter êxito ou não, dependendo se os controladores de domínio que executam versões anteriores ao Windows Server 2016 foram promovidos para o domínio.

Permissões de grupo de usuários

Ao projetar seu modelo de segurança de recuperação de senha, considere as informações na figura a seguir:

Diagrama que mostra as camadas de segurança de senha da LAPS do Windows.

O diagrama ilustra as camadas da segurança de senha sugeridas do Windows Server Active Directory e a relação entre elas.

O círculo mais externo (verde) é composto por entidades de segurança que recebem permissão para ler ou definir o atributo de tempo de expiração da senha em objetos de computador no diretório. Essa capacidade é uma permissão confidencial, mas é considerada não destrutiva. Um invasor que adquire essa permissão pode impor que os dispositivos gerenciados girem os dispositivos gerenciados deles com mais frequência.

O círculo intermediário (amarelo) é composto por entidades de segurança que recebem permissão para ler ou definir atributos de senha em objetos de computador no diretório. Essa capacidade é uma permissão confidencial e deve ser cuidadosamente monitorada. A abordagem mais segura é reservar esse nível de permissão para membros do grupo de segurança de Administradores de Domínio.

O círculo interno (vermelho) só se aplica quando a criptografia de senha estiver habilitada. O círculo interno é composto por grupos ou usuários que recebem permissões de descriptografia para atributos de senha criptografados em objetos de computador no diretório. Assim como a permissão no círculo intermediário, essa capacidade é uma permissão confidencial e deve ser cuidadosamente monitorada. A abordagem mais segura é reservar esse nível de permissão para membros do grupo de Administradores de Domínio.

Importante

Considere personalizar suas camadas de segurança para corresponder à confidencialidade dos computadores gerenciados em sua organização. Por exemplo, pode ser aceitável que os dispositivos de trabalho de TI de linha de frente sejam acessíveis para os administradores de suporte técnico, mas você provavelmente desejará definir limites mais rígidos para laptops executivos corporativos.

Criptografia de senha

O recurso de criptografia de senha da LAPS do Windows tem como base a API de Criptografia: API de Proteção de Dados de Próxima Geração (CNG DPAPI). A CNG DPAPI dá suporte a vários modos de criptografia, mas a LAPS do Windows dá suporte à criptografia de senhas em apenas uma única entidade de segurança (usuário ou grupo) do Windows Server Active Directory. A criptografia subjacente baseia-se na criptografia de chave AES-256 (Advanced Encryption Standard de 256 bits).

Você pode usar a configuração de política ADPasswordEncryptionPrincipal para definir uma entidade de segurança específica para criptografar a senha. Se ADPasswordEncryptionPrincipal não for especificado, a LAPS do Windows criptografará a senha no grupo Administradores de Domínio do domínio do dispositivo gerenciado. Antes que um dispositivo gerenciado criptografe uma senha, o dispositivo sempre verifica se o usuário ou grupo especificado é resolvível.

Dica

  • A LAPS do Windows dá suporte à criptografia de senhas em apenas uma única entidade de segurança. A CNG DPAPI dá suporte à criptografia em várias entidades de segurança, mas esse modo não é compatível com a LAPS do Windows porque causa uma sobrecarga de tamanho dos buffers de senha criptografados. Se você precisar conceder permissões de descriptografia a várias entidades de segurança, para resolver a restrição, é possível criar um grupo wrapper que tenha todas as entidades de segurança relevantes como membros.
  • A entidade de segurança autorizada a descriptografar a senha não pode ser alterada depois que uma senha é criptografada.

Histórico de senha criptografada

A LAPS do Windows dá suporte a um recurso de histórico de senhas para clientes adicionados no domínio e controladores de domínio do Windows Server Active Directory. Há suporte para o histórico de senhas somente quando a criptografia de senha está habilitada. Não há suporte para o histórico de senhas se você armazenar senhas de texto não criptografado no Windows Server Active Directory.

Quando o histórico de senha criptografado está habilitado e é hora de girar a senha, primeiro o dispositivo gerenciado lê a versão atual da senha criptografada do Windows Server Active Directory. Em seguida, a senha atual é adicionada ao histórico de senhas. As versões anteriores da senha no histórico são excluídas conforme necessário para ficar em conformidade com a limitação de histórico máxima configurada.

Dica

Para que o recurso de histórico de senha funcione, o dispositivo gerenciado deve receber permissões SELF para ler a versão atual da senha criptografada do Windows Server Active Directory. Esse requisito é tratado automaticamente quando você executa o Set-LapsADComputerSelfPermission cmdlet .

Importante

É recomendável nunca conceder permissões a um dispositivo gerenciado para descriptografar uma senha criptografada para qualquer dispositivo, inclusive para o próprio dispositivo.

Suporte a senha DSRM

A LAPS do Windows dá suporte ao backup da senha da conta DSRM em controladores de domínio do Windows Server. As senhas da conta DSRM só podem ser armazenadas em backup no Windows Server Active Directory e se a criptografia de senha estiver habilitada. Caso contrário, esse recurso funciona de forma quase idêntica que o suporte a senha criptografada para clientes adicionados no Windows Server Active Directory.

Não há suporte para backup de senhas DSRM no Microsoft Entra ID.

Importante

Quando o backup de senha DSRM estiver habilitado, a senha DSRM atual de qualquer controlador de domínio será recuperável se pelo menos um controlador de domínio nesse domínio estiver acessível.

Considere um cenário catastrófico no qual todos os controladores de domínio em um domínio estão inoperantes. Nessa situação, desde que você tenha mantido backups regulares por práticas recomendadas do Active Directory, ainda é possível recuperar senhas DSRM de backups usando o procedimento descrito em Recuperar senhas durante cenários de recuperação de desastre do Active Directory.

Redefinição de senha após autenticação

A LAPS do Windows dá suporte ao giro automático da senha da conta de administrador local se detectar que a conta de administrador local foi usada para autenticação. A finalidade desse recurso é limitar a quantidade de tempo que a senha de texto não criptografado é utilizável. Você pode configurar um período de "carência" para dar a um usuário tempo para concluir as ações pretendidas por ele.

A redefinição de senha após a autenticação não tem suporte na conta DSRM em controladores de domínio.

Proteção contra adulterações de senha da conta

Quando a LAPS do Windows é configurada para gerenciar uma senha de conta de administrador local, essa conta é protegida contra adulterações acidentais ou descuidadas. Essa proteção se estende à conta DSRM quando a conta é gerenciada pelo Windows LAPS em um controlador de domínio do Windows Server Active Directory.

A LAPS do Windows rejeita tentativas inesperadas de modificar a senha da conta com um erro STATUS_POLICY_CONTROLLED_ACCOUNT (0xC000A08B) ou ERROR_POLICY_CONTROLLED_ACCOUNT (0x21CE\8654). Cada rejeição desse tipo é indicada com um evento 10031 no canal de log de eventos do Windows LAPS.

Desabilitado no modo de segurança do Windows

Quando o Windows é iniciado no modo de segurança, no modo DSRM ou em outro modo de inicialização não padrão, o Windows LAPS é desabilitado. O backup da senha da conta gerenciada não é feito durante esse período, mesmo que esteja em um estado expirado.

Integração do LAPS do Windows com a política de cartão inteligente

A conta gerenciada pela LAPS do Windows é isenta quando a política "Logon interativo: Exigir o Windows Hello para Empresas ou cartão inteligente" (também conhecida como SCForceOption) estiver habilitada. Confira Configurações adicionais da Política de Grupo de cartão inteligente e chaves de registro.

Como uma política do Windows LAPS é aplicada a um novo dispositivo cliente

As seções a seguir descrevem como uma política do Windows LAPS é aplicada a um novo dispositivo cliente.

Novo cenário de instalação do sistema operacional com uma política do Windows LAPS

O Windows LAPS é integrado ao sistema operacional Windows. É um recurso de segurança de linha de base do Windows e não pode ser desinstalado. Portanto, é importante estar ciente do efeito que uma política do Windows LAPS pode ter durante uma nova instalação do sistema operacional.

O principal fator a ser ciente é que o Windows LAPS está sempre "ativado". Assim que uma política do Windows LAPS é aplicada ao dispositivo, o Windows LAPS imediatamente começa a impor a política. Esse comportamento poderá causar interrupções se, em algum momento, o fluxo de trabalho de implantação do sistema operacional envolver a junção de domínio de um dispositivo em uma UO com uma política habilitada do Windows LAPS. Se a política do Windows LAPS for direcionada à mesma conta local com a qual o fluxo de trabalho de implantação está conectado, a modificação imediata resultante da senha da conta local provavelmente interromperá o fluxo de trabalho (por exemplo, após uma reinicialização durante a entrada automática).

A primeira técnica para atenuar esse problema é usar uma UO (Unidade Organizacional) de "preparo" limpa. Uma UO de preparo é considerada uma casa temporária para a conta do dispositivo que aplica um conjunto mínimo de políticas necessárias e não deve aplicar uma política do Windows LAPS. Somente na conclusão do fluxo de trabalho de implantação do sistema operacional é que a conta do dispositivo é movida para a UO de destino final. A Microsoft recomenda o uso de uma UO de preparo limpa como uma prática recomendada genérica.

Uma segunda técnica é configurar a política do Windows LAPS para direcionar uma conta diferente da usada pelo fluxo de trabalho de implantação do sistema operacional. Como prática recomendada, todas as contas locais desnecessárias no final do fluxo de trabalho de implantação do sistema operacional devem ser excluídas.

Novo cenário de instalação do sistema operacional com uma política de LAPS herdada

Esse cenário tem as mesmas preocupações básicas que o cenário de instalação do novo sistema operacional com uma política do Windows LAPS, mas tem alguns problemas especiais relacionados ao suporte do Windows LAPS para o modo de emulação laps herdado.

Novamente, o principal fator a ser ciente é que o Windows LAPS está sempre "ativado". Assim que uma política de LAPS herdada é aplicada ao dispositivo - e supondo que todos os critérios de modo de emulação de LAPS herdados sejam atendidos - o Windows LAPS começa imediatamente a impor a política. Esse comportamento poderá causar interrupções se, em algum momento, o fluxo de trabalho de implantação do sistema operacional envolver a junção de domínio de um dispositivo em uma UO com uma política de LAPS herdada habilitada. Se a política de LAPS herdada tiver como destino a mesma conta local com a qual o fluxo de trabalho de implantação está conectado, a modificação imediata resultante da senha da conta local provavelmente interromperá o fluxo de trabalho (por exemplo, após uma reinicialização durante a entrada automática).

A primeira técnica para atenuar esse problema é usar uma UO (Unidade Organizacional) de "preparo" limpa. Uma UO de preparo é considerada uma casa temporária para a conta do dispositivo que aplica um conjunto mínimo de políticas necessárias e não deve aplicar uma política de LAPS herdada. Somente na conclusão do fluxo de trabalho de implantação do sistema operacional é que a conta do dispositivo é movida para a UO de destino final. A Microsoft recomenda o uso de uma UO de preparo limpa como uma prática recomendada genérica.

Uma segunda técnica é configurar a política de LAPS herdada para direcionar uma conta diferente da usada pelo fluxo de trabalho de implantação do sistema operacional. Como prática recomendada, todas as contas locais desnecessárias no final do fluxo de trabalho de implantação do sistema operacional devem ser excluídas.

Uma terceira técnica é desabilitar o modo de emulação de LAPS herdado no início do fluxo de trabalho de implantação do sistema operacional e habilitá-lo (se necessário) no final do fluxo de trabalho de implantação do sistema operacional.

Detecção e mitigação de reversão de imagem do sistema operacional Windows LAPS

Quando uma imagem do sistema operacional ao vivo é revertida para uma versão anterior, o resultado geralmente é uma situação de "estado rompido" em que a senha armazenada no diretório não corresponde mais à senha armazenada localmente no dispositivo. Por exemplo, o problema pode ocorrer quando uma máquina virtual Hyper-V é restaurada para um instantâneo anterior.

Quando o problema ocorre, o administrador de TI não consegue entrar no dispositivo usando a senha persistente do Windows LAPS. O problema não é resolvido até que o Windows LAPS gire a senha - mas isso pode não ocorrer por dias ou semanas, dependendo da data de expiração da senha atual.

O Windows LAPS mitiga esse problema gravando um GUID aleatório no diretório ao mesmo tempo em que uma nova senha está sendo persistida, seguido pelo salvamento de uma cópia local. O GUID é armazenado no atributo msLAPS-CurrentPasswordVersion. Durante cada ciclo de processamento, o guid msLAPS-CurrentPasswordVersion é consultado e comparado à cópia local. Se os dois GUIDs forem diferentes, a senha será imediatamente girada.

Esse recurso só é suportado ao fazer backup de senhas no Active Directory. Não há suporte para o Microsoft Entra ID.

Importante

A detecção e a mitigação de reversão do Windows LAPS só poderão funcionar se o computador ainda tiver uma senha de conta de computador válida e for capaz de autenticar no Active Directory. Essa condição pode ou não ser verdadeira, dependendo do estado incompatível causado pela reversão. Se a máquina não for mais capaz de autenticar, outras etapas de recuperação serão necessárias, como redefinir a senha da conta da máquina. A conta do Windows LAPS na máquina revertida ainda pode ser útil se o recurso de histórico de senhas do Windows LAPS tiver sido habilitado.

Importante

O recurso de detecção e atenuação de reversão de imagem do sistema operacional Windows LAPS é compatível com o Windows 11 24H2, Windows Server 2025 e versões posteriores. Esse recurso requer o msLAPS-CurrentPasswordVersion atributo de esquema, que só está disponível ao usar o esquema de floresta do Windows Server 2025. Esse atributo é automaticamente incluído quando você promove o primeiro controlador de domínio do Windows Server 2025 na sua floresta; Não é instalado rodando o Update-LapsADSchema cmdlet.

Veja também

Próximas etapas

Agora que você entende os conceitos básicos do design da LAPS do Windows, comece por um dos seguintes cenários:

  • Last updated on