Rotação de palavras-passe de smartcard: Active Directory

Rotação de palavras-passe de smartcard no Active Directory

A rotação de palavras-passe de smartcard no Active Directory é importante porque estas contas continuam a conservar um segredo de palavra-passe para a rede. Sem renovação automática de palavras-passe, o segredo aleatório estabelecido pelo Windows pode persistir até ser alterado explicitamente. A afirmação de que «nunca muda por predefinição» exige uma ressalva imediata: a Microsoft documenta a renovação automática como ativada nos novos domínios, enquanto os domínios existentes exigem configuração. Trate esta situação como um risco nos domínios onde a renovação está ausente ou desativada, em vez de a considerar uma propriedade universal do Active Directory moderno. A documentação da Microsoft sobre as funcionalidades do Windows Server 2016 faz essa distinção.

A opção da conta e a configuração de rotação do domínio respondem a perguntas diferentes. A primeira determina se o utilizador tem de usar um smartcard para o início de sessão interativo inicial, incluindo o Remote Desktop. A segunda controla a manutenção do segredo baseado em palavra-passe que continua a ser relevante para a autenticação de rede. Uma revisão que termina na caixa de seleção da conta deixa a segunda pergunta sem resposta. A documentação da Microsoft sobre contas descreve tanto a restrição interativa como o hash NT que permanece.

Para os administradores, o objetivo útil é, portanto, mais amplo do que «pôr a caixa de seleção a verde». Determine que identidades exigem o cartão, se o respetivo domínio suporta e ativa a renovação automática e como demonstrará uma reposição bem-sucedida numa conta representativa. Este guia segue essa sequência: inspecionar a conta e o domínio, interpretar os resultados e depois testar a correção num projeto-piloto. Os comandos abaixo são exemplos baseados na documentação; nenhum foi executado num domínio para este artigo.

O bit é um requisito de autenticação

A opção corresponde ao sinalizador cumulativo userAccountControl chamado SMARTCARD_REQUIRED, hexadecimal 0x40000, decimal 262144. Outros sinalizadores podem coexistir com ele. Ler o atributo inteiro como se tivesse de ser igual a 0x40000 faria omitir contas com opções adicionais. A referência UserAccountControl da Microsoft enumera o sinalizador e explica os valores cumulativos.

O Windows atribui um valor aleatório ao segredo da conta quando o requisito é ativado. As orientações administrativas da Microsoft descrevem uma palavra-passe aleatória inicialmente desconhecida e alertam que alguém com direitos de reposição de palavras-passe pode depois definir um valor conhecido e usar determinadas vias de acesso à rede. Exigir o cartão não elimina a importância dessas permissões de reposição. As orientações de menor privilégio da Microsoft são explícitas quanto a essa capacidade administrativa restante.

Como funcionam o segredo restante e a renovação automática

Aleatório não significa substituído regularmente

A referência de contas da Microsoft indica que, sem o comportamento adicional de renovação automática, o valor gerado permanece até ser definida uma nova palavra-passe ou até o requisito de smartcard ser desativado e novamente ativado. Um valor inicial de elevada entropia dificulta a adivinhação; manter o mesmo valor após um furto é uma preocupação diferente. É essa distinção que fundamenta esta revisão, e não a afirmação de que todas as contas com smartcard têm a palavra-passe mais antiga do domínio. O comportamento documentado das contas sustenta a persistência e o mecanismo de substituição manual.

A autenticação do Windows também tem de suportar o acesso posterior a recursos de rede. A documentação da Microsoft sobre os processos de credenciais descreve a retenção do hash NT correspondente no seu modelo de credenciais após o início de sessão com smartcard. Isto explica por que motivo o segredo importa. Não demonstra que um atacante possa extrair um hash de qualquer dispositivo, independentemente das suas proteções ou da sessão efetiva. Mantenha a existência, a exposição e o furto de uma credencial como perguntas de investigação separadas.

A configuração do domínio permite a expiração baseada na política

O atributo booleano do domínio msDS-ExpirePasswordsOnSmartCardOnlyAccounts controla a expiração das palavras-passe das contas exclusivamente com smartcard segundo a política de palavras-passe. Não é o bit de smartcard por utilizador. A definição do atributo em MS-ADA2 identifica a sua finalidade.

A funcionalidade exige um nível funcional do domínio Windows Server 2016 ou superior. A versão do sistema operativo de um controlador de domínio, por si só, não demonstra esse pré-requisito; o requisito é aqui o nível do domínio, e não um pré-requisito inventado ao nível da floresta. A página da Microsoft sobre a funcionalidade também documenta a opção do Active Directory Administrative Center para os domínios existentes. A descrição da funcionalidade de renovação automática é a referência para estes requisitos de implementação.

A reposição faz parte do processamento de inícios de sessão elegíveis

Durante o processamento de um PKINIT AS-REQ, o KDC solicita a reposição da palavra-passe da conta exclusivamente com smartcard nas condições definidas no procedimento de reposição de MS-PKCA. A conclusão bem-sucedida faz com que reinicie o processamento do pedido original.

O serviço que responde aplica as regras de expiração e validação da especificação normativa de reposição de MS-SAMS. Uma palavra-passe não expirada devolve sucesso sem substituição. Aqui, expiração significa a condição calculada pelo protocolo, que também considera regras de duração dos tickets; não é simplesmente o limiar de idade do domínio usado pelo coletor. Para uma palavra-passe expirada, a validação inclui o atributo do domínio ativado, um nível funcional do domínio suficiente, o bit de smartcard e a ausência de DONT_EXPIRE_PASSWD. Uma reposição bem-sucedida gera novos segredos e atualiza pwdLastSet para o momento atual.

Trata-se de processamento de início de sessão sujeito a condições de política e protocolo. Não é um temporizador em segundo plano, uma substituição garantida em cada início de sessão ou um calendário universal com um número fixo de dias. Como inferência operacional, uma conta que raramente realiza um início de sessão elegível pode conservar uma data antiga mesmo com a renovação automática ativada. Investigue a política e a utilização efetiva dessa conta antes de atribuir uma causa à data.

Medir a conta e o domínio separadamente

Use um controlador de domínio identificado para leituras comparáveis e substitua corp.example, dc01.corp.example, o nome distinto do domínio e admin-pilot por valores reais. Guarde a identidade, o momento da recolha e os resultados brutos com o registo da alteração. Os exemplos foram construídos a partir de parâmetros documentados dos cmdlets; não são apresentados como comandos exatos copiados literalmente do Learn nem como resultados de uma auditoria a um cliente.

Passo 1 — Inventariar as contas com o requisito

Get-ADUser documenta -Filter, -Properties e -Server. O modelo de objetos do Active Directory documenta SmartcardLogonRequired e a propriedade PasswordLastSet derivada de pwdLastSet.

Get-ADUser -Filter {SmartcardLogonRequired -eq $true} -Properties pwdLastSet,PasswordLastSet,PasswordNeverExpires,Enabled,adminCount -Server dc01.corp.example

Leia o estado de ativação e a exceção de expiração em conjunto com as datas. Conserve as contas desativadas no inventário se for útil, mas distinga-as da população ativada que o detetor de rotação avalia. Uma data constitui evidência sobre a manutenção da palavra-passe; não data, de forma independente, o momento em que o bit de smartcard foi ativado.

Para cada conta, registe o responsável, o fluxo esperado de início de sessão, a política aplicável e as exceções de expiração. Recolha os pormenores do fluxo e da responsabilidade separadamente; Get-ADUser não os demonstra.

Passo 2 — Identificar o domínio e o nível funcional

Get-ADDomain aceita uma identidade de domínio e um servidor e devolve informações do domínio, incluindo DomainMode e DistinguishedName.

Get-ADDomain -Identity corp.example -Server dc01.corp.example

Use a identidade do domínio devolvida para confirmar que as leituras seguintes visam o contexto de nomenclatura pretendido. Registe o nível funcional separadamente do inventário do sistema operativo do controlador de domínio. Se não conseguir obter o resultado ou se este identificar o domínio errado, resolva esse problema de medição antes de tirar conclusões sobre a disponibilidade da funcionalidade.

Passo 3 — Ler o atributo do domínio e a política de idade das palavras-passe

Get-ADObject documenta a leitura de um objeto pela identidade com propriedades LDAP adicionais. Leia o objeto raiz do domínio, não uma OU nem um utilizador individual:

Get-ADObject -Identity 'DC=corp,DC=example' -Properties msDS-ExpirePasswordsOnSmartCardOnlyAccounts,maxPwdAge -Server dc01.corp.example

Guarde o valor bruto de maxPwdAge com a configuração do domínio. A comparação de idade do coletor descrita abaixo usa um valor em dias derivado dessa política. Não o substitua por um objetivo de idade arbitrário para depois o descrever como o requisito de renovação automática da Microsoft.

Trate um atributo ausente, um valor false e uma leitura falhada como situações de investigação distintas. Confirme o controlador, a identidade do domínio, as permissões e a integridade da resposta. Uma vista vazia na consola não é evidência suficiente de que uma recolha bem-sucedida devolveu false.

Deteção: decidir a que pergunta responde a evidência

Comece por duas populações: contas ativadas que exigem o cartão e identidades administrativas que não o exigem. Na primeira população, determine se a renovação automática está ativada antes de avaliar a idade. Na segunda, confirme as responsabilidades administrativas efetivas antes de decidir onde deve aplicar o requisito. Estes são passos de revisão derivados dos critérios do detetor, não uma prova de intrusão.

A tabela resume smartcard-rotation.go:48 e admin-no-smartcard.go:24, examinados integralmente para este artigo. A sua implementação é detalhada em «Como a EtcSec deteta esta situação».

Um registo útil de evidências separa a observação da configuração, a observação da idade da conta e a causa confirmada. Por exemplo, uma data antiga com renovação automática ativada é motivo para investigar; não prova que o atributo do domínio tenha de estar secretamente desativado. Evite descrever o nome do detetor como o diagnóstico de todas as contas que devolve.

Por que motivo a consequência de ataque continua condicionada

Se um segredo NT ainda válido for efetivamente furtado, a sua utilização depende dos protocolos de autenticação e dos direitos disponíveis ao longo do percurso até ao alvo. O nosso guia de Pass-the-Hash explica essa reutilização condicionada através de NTLM. Também distingue Overpass-the-Hash, que obtém material de autenticação Kerberos nas condições relevantes, de Pass-the-Ticket, que reutiliza um ticket. Não deduza que possuir o hash NT de um utilizador proporciona todos os tickets num domínio baseado em AES.

Mantenha o objetivo de reforço de segurança preciso: reduzir a persistência de um segredo de palavra-passe reutilizável. Não descreva uma reposição bem-sucedida de palavra-passe como revogação universal de tickets já emitidos, sessões de rede existentes ou certificados. Estes exigem decisões próprias de resposta a incidentes.

Correção: ativar a renovação automática através de um projeto-piloto controlado (Remediation)

Passo 1 — Estabelecer pré-requisitos e responsabilidade

Antes de alterar o domínio, identifique o administrador responsável, selecione uma conta-piloto representativa e confirme o nível funcional do domínio. Reveja a política efetiva de palavras-passe da conta-piloto e as suas exceções de expiração. Prepare uma forma de testar o início de sessão com smartcard e o acesso à rede necessário, com um procedimento de recuperação acordado.

Este é um plano de alteração recomendado, não um resultado de laboratório. A sua finalidade é expor dependências antes de alargar a alteração. Não use uma operação de escrita bem-sucedida como único critério de aceitação. Decida antecipadamente que leituras e testes de autenticação o responsável pela alteração conservará como evidência.

As identidades selecionadas também têm de corresponder à utilização pretendida. A referência de contas da Microsoft indica que as contas com requisito de smartcard não podem ser usadas para iniciar serviços nem para executar tarefas agendadas. Reveja essas dependências antes de alterar o requisito de uma conta. As orientações da Microsoft sobre contas estabelecem esse limite.

Passo 2 — Ativar a renovação automática do domínio

Depois de validar o nível funcional e planear o projeto-piloto, adapte o exemplo 6 de Set-ADDomain:

Set-ADDomain -Identity corp.example -PublicKeyRequiredPasswordRolling $true -Server dc01.corp.example

O parâmetro documentado define msDS-ExpirePasswordsOnSmartCardOnlyAccounts como true. É uma alteração do domínio, mesmo que a validação comece com uma única conta. Inventarie as identidades afetadas e os respetivos responsáveis antes de a aplicar.

Repita imediatamente a leitura anterior do objeto do domínio no controlador escolhido. Em seguida, organize um início de sessão elegível da conta-piloto e repita a leitura do utilizador. Registe o que efetivamente aconteceu em vez de inserir resultados esperados no registo da alteração. Se a data não mudar, investigue a elegibilidade e a política antes de repetir alterações às cegas. Este exemplo não promete qualquer atraso de replicação nem resultado de reposição.

Passo 3 — Usar a substituição manual apenas como procedimento controlado

Quando ainda não é possível usar a renovação automática, a referência de contas da Microsoft documenta a substituição por desativação e reativação do requisito. Set-ADUser documenta o parâmetro booleano -SmartcardLogonRequired. As ações seguintes são duas operações separadas numa conta-piloto.

Primeiro remova o requisito:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $false -Server dc01.corp.example

Depois restaure-o:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $true -Server dc01.corp.example

Leia novamente a conta, verifique que o requisito foi restaurado, teste o fluxo pretendido de início de sessão e rede e confirme o estado replicado relevante. Não afirme que este procedimento manual atualiza sempre pwdLastSet de forma idêntica à reposição automática normativa. Meça o resultado.

Se um nível funcional inferior impedir a renovação automática, documente o procedimento manual, a responsabilidade e o calendário organizacional. Escolha esse calendário através do seu processo de risco e operação; não classifique um intervalo escolhido como requisito da Microsoft para esta funcionalidade.

Passo 4 — Rever o perímetro administrativo real

Use a seleção do detetor complementar como lista inicial. A sintaxe abaixo usa parâmetros documentados de Get-ADUser; os critérios de seleção provêm de admin-no-smartcard.go:24.

Get-ADUser -Filter {Enabled -eq $true -and adminCount -eq 1 -and SmartcardLogonRequired -eq $false} -Properties adminCount,userAccountControl -Server dc01.corp.example

Concilie essa lista com as pertenças atuais a grupos, a administração delegada, a autoridade sobre aplicações e as identidades de recuperação. O detetor lê um marcador administrativo; não calcula todas as formas de privilégio efetivo. As orientações de menor privilégio da Microsoft abordam privilégios nos grupos do diretório, sistemas membros e aplicações, razão pela qual a revisão tem de ir além da população da consulta. Reveja os privilégios administrativos e os direitos de reposição de palavras-passe antes de aplicar restrições às contas.

Validar a alteração sem exagerar o resultado

Construa o registo de validação em torno de observações que um revisor possa reproduzir: domínio e controlador consultados, nível funcional, atributo bruto de renovação automática, requisito da conta, política revista e resultado de autenticação da conta-piloto. Inclua os momentos de recolha e conserve quaisquer erros. Este é um formato de evidência recomendado, não a afirmação de que um único comando fornece todos os elementos.

Distinga «a configuração está ativada» de «a reposição de uma conta elegível foi concluída». Se a conta-piloto ainda não tiver de expirar, uma data inalterada pode ser compatível com o fluxo documentado. Se a reposição for bem-sucedida, compare a nova observação do utilizador com a recolha anterior. Para contas raramente usadas, decida como organizar a validação futura em vez de presumir que uma alteração do domínio renova imediatamente todos os segredos.

Por fim, execute novamente a avaliação da configuração e examine outra vez ambas as populações. Um resultado restante merece investigação; uma contagem zero precisa do contexto da recolha. Mantenha disponível o plano de recuperação administrativa enquanto a alteração é alargada. O encerramento deve descrever exatamente o que foi verificado e o que continua a depender de futuros inícios de sessão ou de controlos separados.

Como a EtcSec deteta esta situação

SMARTCARD_PASSWORD_ROTATION_DISABLED

A implementação em ad/advanced/other/smartcard-rotation.go:48 começa por tratar a ausência de informações do domínio, devolvendo um resultado com Count: 0. Depois seleciona os utilizadores ativados cujo userAccountControl contém 0x40000.

Tem dois ramos efetivos:

• Configuração do domínio false: todos os utilizadores dessa população ativada com requisito de smartcard são selecionados, independentemente de PasswordLastSet. Uma alteração recente de palavra-passe não elimina o resultado de configuração.
• Configuração do domínio true: a idade só é avaliada quando MaxPasswordAge > 0. A conta é selecionada se PasswordLastSet for zero ou estritamente anterior a Now.AddDate(0, 0, -MaxPasswordAge). A igualdade não é selecionada. Com idade máxima zero, este ramo não infere um resultado de idade.

Estes ramos estão em smartcard-rotation.go:79–87; o limiar da política está em 62–66. A verificação não usa um limiar com um número fixo de dias nem prova que tenha ocorrido uma reposição durante um determinado início de sessão.

ADMIN_NO_SMARTCARD

A implementação complementar em ad/accounts/advanced/admin-no-smartcard.go:24 seleciona utilizadores ativados com AdminCount=true e sem o bit de smartcard, através das condições em 29–41. Não examina a idade da palavra-passe nem o atributo de renovação automática do domínio.

As duas verificações avaliam populações de contas diferentes. Uma revê a manutenção do segredo subjacente a um smartcard obrigatório; a outra identifica contas da sua seleção administrativa sem esse requisito. Nenhuma deve ser apresentada como eliminando todos os ataques baseados em palavras-passe.

O que estes resultados não medem

Nenhuma das funções Detect() valida o nível funcional do domínio, calcula a política efetiva de palavras-passe granular de cada utilizador, verifica DONT_EXPIRE_PASSWD, comprova um início de sessão ou uma reposição bem-sucedidos, ou inventaria administradores fora de adminCount. A recolha LDAP converte um atributo de renovação automática true num valor booleano e converte ausente ou false em false; deriva a idade máxima da palavra-passe de maxPwdAge (providers/ldap/client.go:636,662–669). Esse limite da recolha importa ao interpretar o primeiro ramo.

Uma contagem zero pode, portanto, significar ausência de utilizadores selecionados, uma comparação de idade sem limiar positivo ou informações do domínio indisponíveis. Não é, por si só, prova de uma recolha completa ou de uma rotação funcional. Use os resultados para orientar as medições da conta e do domínio acima e conserve as evidências do projeto-piloto que demonstram o comportamento efetivamente verificado.