Rever o prazo de contas AD: Decidir antes de prolongar

Rever o prazo de contas AD: Decidir antes da data limite

Rever o prazo de contas AD transforma as datas de fim de acesso que se aproximam em decisões com um responsável definido. Uma conta prestes a expirar pode pertencer a um prestador de serviços cujo contrato está a terminar, a um colaborador com acesso temporário ou a uma identidade de utilizador usada por uma aplicação. A primeira questão é saber se a data de fim planeada continua correta. Prolongar todas as contas que aparecem num relatório anula o propósito de atribuir uma data de fim.

Uma revisão precisa do instante de expiração, do proprietário responsável, da necessidade de negócio que se mantém e das dependências que devem ser descontinuadas ou transferidas. Deve abranger todas as populações de utilizadores relevantes. A pertença a grupos privilegiados influencia a urgência e os direitos a remover, mas não é uma condição prévia para rever uma data limite próxima.

Uma conta perto de expirar não é prova de comprometimento. A expiração da conta também é distinta da expiração da palavra-passe: são propriedades diferentes da conta e problemas operacionais diferentes. Este guia propõe um processo de revisão; não apresenta resultados de um domínio em produção nem prescreve uma política universal de renovação.

Como accountExpires representa uma data de fim

O atributo AD accountExpires armazena Windows FILETIME: intervalos de 100 nanossegundos contados desde 1 de janeiro de 1601 UTC. A Microsoft define dois valores para uma conta que nunca expira: 0 e 9223372036854775807, também escrito como 0x7FFFFFFFFFFFFFFF. Nenhum destes valores é uma data limite futura a inserir num calendário de expiração. Microsoft Learn: Atributo Account-Expires

Distinga o instante armazenado de uma instrução de negócio como «o acesso termina na sexta-feira». Pergunte se o proprietário se refere ao início desse dia, ao fim de um turno ou a um instante UTC específico. Registe o fuso horário acordado e a hora exata antes de fazer uma alteração. Uma data sem esse contexto pode terminar o acesso antes do pretendido pelo proprietário.

Existe uma sobreposição reconhecida com o nosso artigo sobre contas desativadas, expiradas e bloqueadas que permanecem em grupos privilegiados. Esse artigo aborda contas que já estão num estado inválido enquanto a pertença privilegiada se mantém. Esta revisão atua antes da expiração, em todas as populações de utilizadores, para atribuir a decisão e coordenar as alterações de acesso. Se a conta já expirou, inclua-a no processo existente de saída e revisão de pertenças, em vez de a tratar como uma data limite futura.

O guia sobre a validade dos tickets Kerberos e a contenção de ligações explica por que razão o estado da conta, os tickets emitidos e as ligações autenticadas exigem provas separadas. Use esta distinção ao planear uma data de fim de acesso. Uma revisão normal de expiração não é um achado de incidente e não justifica presumir o roubo de tickets.

Deteção: Criar um inventário de expiração

1. Definir o âmbito e usar um horizonte explícito

Comece pelo domínio, servidor de diretório, base de pesquisa e hora de referência. Registe o horizonte de revisão como uma escolha operacional local. Os exemplos seguintes exigem o módulo ActiveDirectory PowerShell e um contexto de diretório autorizado. São comandos ilustrativos adaptados da documentação, não comandos executados num ambiente AD. Substitua todos os servidores, DNs e identidades de exemplo por valores verificados.

A Microsoft documenta Search-ADAccount -AccountExpiring com -TimeSpan, para um período a partir da hora atual, ou com -DateTime, para uma data limite. -UsersOnly restringe a população de objetos a utilizadores. O exemplo seguinte escolhe um horizonte de relatório de trinta dias; esta escolha não é um requisito da Microsoft. Microsoft Learn: Search-ADAccount

$server = 'dc01.example.com'
$searchBase = 'OU=People,DC=example,DC=com'
Search-ADAccount -AccountExpiring -UsersOnly -TimeSpan '30.00:00:00' -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Numa revisão agendada, uma data limite absoluta pode ser mais fácil de reproduzir. Este exemplo separado constrói um DateTime UTC em vez de depender de uma cadeia de data interpretada segundo as definições regionais:

$deadlineUtc = [datetime]::new(2026, 11, 3, 18, 0, 0, [DateTimeKind]::Utc)
Search-ADAccount -AccountExpiring -UsersOnly -DateTime $deadlineUtc -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Use uma única forma de horizonte por consulta. Preserve a hora da consulta, além da respetiva data limite: uma consulta relativa executada mais tarde tem uma janela diferente. Estas pesquisas com cmdlets são dados de entrada para a investigação, não uma alegada reprodução das comparações estritas de limites da EtcSec. Examine as datas devolvidas e o estado de ativação antes de atribuir uma ação.

2. Ler o atributo em bruto e normalizar as datas

Obtenha accountExpires explicitamente com Get-ADUser -Properties. A Microsoft documenta atributos LDAP adicionais através deste parâmetro, juntamente com -SearchBase e -Server para selecionar o contexto de diretório. Microsoft Learn: Get-ADUser

Este inventário ilustrativo preserva o valor em bruto e apresenta o estado da conversão. Distingue deliberadamente um valor indisponível ou inválido de um valor sentinela documentado que significa que a conta nunca expira:

Get-ADUser -Filter * -Server $server -SearchBase $searchBase -Properties accountExpires,manager,description |
    ForEach-Object {
        $raw = $_.accountExpires
        $expiryUtc = $null
        $state = 'Missing or invalid'
        if ($null -ne $raw -and [string]$raw -ne '') {
            try {
                $value = [long]$raw
                if ($value -eq 0 -or $value -eq [long]::MaxValue) {
                    $state = 'Never expires'
                } else {
                    $expiryUtc = [datetime]::FromFileTimeUtc($value)
                    $state = 'Dated'
                }
            } catch {
                $state = 'Missing or invalid'
            }
        }
        [pscustomobject]@{
            DistinguishedName = $_.DistinguishedName
            Enabled = $_.Enabled
            RawAccountExpires = $raw
            ExpirationUtc = $expiryUtc
            DateState = $state
            Manager = $_.Manager
            Description = $_.Description
        }
    }

FromFileTimeUtc converte uma hora de ficheiro num DateTime UTC e rejeita valores fora do intervalo permitido. Os dois valores sentinela de contas que nunca expiram são tratados antes da conversão. As etiquetas de erro deste exemplo são etiquetas propostas para a revisão, não resultados do parser do coletor. Microsoft Learn: DateTime.FromFileTimeUtc

Os campos manager e description do diretório são pistas para encontrar um proprietário, não prova de que a pessoa indicada autorizou o acesso. Confirme o proprietário responsável através do contrato atual, do pedido de acesso ou do registo de serviço. Mantenha visível a responsabilidade por resolver, em vez de usar um campo vazio como autorização para renovar.

3. Transformar datas num registo com ações concretas

Para cada identidade no âmbito, preserve o identificador estável, o atributo em bruto, a expiração normalizada, o estado de ativação, a data e hora da revisão e a origem no diretório. Acrescente a data de fim de negócio, o proprietário, as dependências, a decisão e a referência da alteração. Mantenha as contas já expiradas, as que nunca expiram e as datas ilegíveis distinguíveis da fila de datas limite próximas.

Uma dependência de aplicação deve tornar-se uma tarefa para o responsável pelo serviço. Não deve transformar silenciosamente uma identidade temporária numa permanente. Decida como o trabalho irá continuar, quem assume a substituição ou a transição e que prova permite encerrar essa tarefa.

Correção: Confirmar a data de fim ou autorizar um prolongamento limitado (Remediation)

1. Decidir antes de editar a conta

Confirme primeiro a data de referência e a população e, em seguida, envie cada data limite ao respetivo proprietário. Pergunte se a data de fim original continua válida e se o utilizador ainda precisa do mesmo acesso. Registe a resposta com a sua fonte de aprovação. A falta de resposta é uma revisão por resolver, não uma autorização para prolongar.

Quando o acesso deve terminar como planeado, coordene a remoção de direitos, a revisão de pertenças e a passagem das aplicações com as equipas responsáveis. Quando o trabalho continua, exija uma nova data de fim delimitada e um motivo autorizado. Separe estes dois resultados no registo para que uma renovação em massa não possa ser confundida com uma correção concluída.

2. Aplicar apenas a data aprovada

A Microsoft documenta Set-ADAccountExpiration para definir uma hora exata de expiração. O parâmetro -DateTime assume a hora local salvo indicação em contrário; omitir a hora significa meia-noite local. Use o instante exato aprovado e registe-o explicitamente. Microsoft Learn: Set-ADAccountExpiration

O seguinte prolongamento específico ilustrativo usa uma identidade fictícia e uma data limite UTC. Execute primeiro a pré-visualização num ambiente autorizado. Aplique a escrita separada apenas depois de verificar que a identidade e a data correspondem à aprovação registada. Estes comandos não foram executados aqui.

$identity = 'CN=Example User,OU=People,DC=example,DC=com'
$approvedExpiryUtc = [datetime]::new(2026, 12, 1, 18, 0, 0, [DateTimeKind]::Utc)
Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server -WhatIf

Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server

Não envie o relatório inteiro de expiração para esta operação de escrita. Um resultado de consulta estabelece uma condição de data; não fornece aprovação para manter o acesso. Da mesma forma, remover a expiração é uma decisão de política separada, não uma correção de rotina para um achado de expiração próxima.

3. Voltar a ler e conservar a decisão

Leia a mesma conta a partir do servidor escolhido depois da alteração. Preserve os valores em bruto antigos e novos, as datas normalizadas, o servidor, a data e hora, a aprovação e a referência da alteração:

Get-ADUser -Identity $identity -Server $server -Properties accountExpires,AccountExpirationDate |
    Select-Object DistinguishedName, Enabled, accountExpires, AccountExpirationDate

Normalize o valor em bruto com o método do inventário e compare-o com o instante UTC aprovado. Esta releitura verifica o valor do servidor selecionado; quando o processo depende de outros controladores de domínio, organize a verificação destes através do processo da equipa de diretório. Uma aprovação guardada sem releitura não estabelece que o atributo foi alterado como pretendido.

Para saídas planeadas, conserve provas de que as tarefas atribuídas de remoção de direitos e transição de serviços foram concluídas. Para prolongamentos, agende a próxima revisão em torno da nova data limite. Nos dois casos, distinga o atributo da conta dos tickets, das ligações e do acesso às aplicações. O registo deve indicar o que foi verificado e o que permanece sob a responsabilidade de outro proprietário.

Como a EtcSec deteta esta situação

O etc-collector da EtcSec implementa ACCOUNT_EXPIRE_SOON em public/internal/audit/detectors/ad/accounts/status/account-expire-soon.go. A inspeção estática de Detect() mostra a lógica seguinte; não foi executada nenhuma auditoria de cliente para este artigo:

1. Obter a hora de referência a partir de data.Now.
2. Calcular o limite superior com now.AddDate(0, 0, 30).
3. Ignorar qualquer utilizador cuja flag Disabled seja verdadeira.
4. Ignorar qualquer utilizador cujo AccountExpires interpretado seja a hora zero.
5. Selecionar apenas datas estritamente posteriores à hora de referência e estritamente anteriores ao limite superior.

Os limites inferior e superior são ambos excluídos. As contas já expiradas são excluídas, tal como uma expiração exatamente igual à hora de referência da auditoria. Count é o número de utilizadores selecionados, não o número de domínios, aprovações ou tarefas de saída em falta. O detetor devolve um achado de gravidade Medium com essa contagem; só acrescenta detalhes dos utilizadores afetados quando IncludeDetails está ativado e a contagem é positiva.

Esta verificação não tem nenhuma condição relativa a grupos privilegiados, contas de serviço ou segredos. Abrange todos os utilizadores recolhidos que cumprem as condições de data e estado de ativação. A janela de trinta dias é uma escolha de produto declarada, não um requisito da Microsoft, ANSSI ou CIS. A implementação usa a adição de dias de calendário; preserve a referência e os limites da auditoria ao explicar um resultado específico.

O parser LDAP preenche AccountExpires através de parseFileTime em public/internal/providers/ldap/parser.go. Uma entrada vazia, 0, o valor sentinela máximo de 64 bits com sinal e os erros de interpretação de inteiros tornam-se hora zero, sem diagnóstico por valor nessa função auxiliar. Os valores anteriores ao limite de conversão da época Unix também se tornam zero. Consequentemente, uma data interpretada como zero pode representar tanto dados de contas que nunca expiram como entradas indisponíveis ou inutilizáveis. O detetor ignora ambos.

Use ACCOUNT_EXPIRE_SOON para iniciar a revisão do proprietário e da data limite. Uma contagem positiva não estabelece um ataque, a expiração da palavra-passe, um prolongamento não autorizado ou a necessidade de renovar. Encerre a revisão com uma decisão documentada sobre a data de fim, o estado verificado do atributo e tarefas de remoção de acesso ou de dependências com responsáveis separados.