Scadenza account AD: revisione prima della proroga

Revisione della scadenza account AD: decidere prima del termine

Una revisione della scadenza account AD trasforma le prossime date di fine accesso in decisioni assegnate a un responsabile. Un account prossimo alla scadenza può appartenere a un collaboratore il cui incarico sta terminando, a un dipendente con accesso temporaneo o a un'identità utente utilizzata da un'applicazione. La prima domanda è se la data di fine prevista sia ancora corretta. Prorogare tutti gli account che compaiono in un report annulla lo scopo di assegnare una data di fine.

La revisione richiede l'istante di scadenza, il responsabile, l'esigenza aziendale che continua e le dipendenze da dismettere o trasferire. Deve coprire tutte le popolazioni di utenti pertinenti. L'appartenenza a gruppi privilegiati influisce sull'urgenza e sui diritti da rimuovere, ma non è un prerequisito per esaminare una scadenza imminente.

Un account prossimo alla scadenza non costituisce una prova di compromissione. La scadenza dell'account è inoltre distinta dalla scadenza della password: sono proprietà diverse dell'account e problemi operativi differenti. Questa guida propone un processo di revisione; non riporta risultati provenienti da un dominio reale né prescrive una politica universale di rinnovo.

Come accountExpires rappresenta una data di fine

L'attributo AD accountExpires memorizza Windows FILETIME: intervalli di 100 nanosecondi conteggiati dal 1° gennaio 1601 UTC. Microsoft definisce due valori per un account che non scade mai: 0 e 9223372036854775807, scritto anche 0x7FFFFFFFFFFFFFFF. Nessuno dei due è una scadenza futura da inserire in un calendario delle scadenze. Microsoft Learn: attributo Account-Expires

Distinguete l'istante memorizzato da un'indicazione aziendale come «l'accesso termina venerdì». Chiedete se il responsabile intende l'inizio di quel giorno, la fine di un turno o un preciso istante UTC. Registrate il fuso orario concordato e l'ora esatta prima di apportare una modifica. Una data priva di questo contesto può terminare l'accesso prima di quanto previsto dal responsabile.

Questo argomento si sovrappone al nostro articolo sugli account disabilitati, scaduti e bloccati che restano nei gruppi privilegiati. Quell'articolo riguarda account già in uno stato non valido la cui appartenenza privilegiata persiste. Questa revisione interviene prima della scadenza, per tutte le popolazioni di utenti, per assegnare la decisione e coordinare le modifiche di accesso. Se l'account è già scaduto, inseritelo nel processo esistente di cessazione dell'accesso e revisione delle appartenenze anziché trattarlo come una scadenza futura.

La guida sulla durata dei ticket Kerberos e sul contenimento delle connessioni spiega perché lo stato dell'account, i ticket emessi e le connessioni autenticate richiedono evidenze separate. Usate questa distinzione per pianificare una data di fine accesso. Una normale revisione delle scadenze non è un rilievo di incidente e non giustifica l'ipotesi di un furto di ticket.

Rilevamento: costruire un inventario delle scadenze

1. Definire l'ambito e un orizzonte esplicito

Partite dal dominio, dal server di directory, dalla base di ricerca e dall'istante di riferimento. Registrate l'orizzonte di revisione come una scelta operativa locale. Gli esempi seguenti richiedono il modulo PowerShell ActiveDirectory e un contesto di directory autorizzato. Sono comandi illustrativi adattati dalla documentazione, non comandi eseguiti in un ambiente AD. Sostituite ogni server, DN e identità di esempio con valori verificati.

Microsoft documenta Search-ADAccount -AccountExpiring con -TimeSpan per un periodo dall'istante corrente oppure con -DateTime per una scadenza. -UsersOnly limita la popolazione degli oggetti agli utenti. L'esempio seguente sceglie un orizzonte di report di trenta giorni; questa scelta non è un requisito 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

Per una revisione programmata, una scadenza assoluta può essere più facile da riprodurre. Questo esempio separato costruisce un DateTime UTC anziché dipendere da una stringa di data legata alle impostazioni locali:

$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

Usate una sola forma di orizzonte per query. Conservate l'ora della query e la sua scadenza: una query relativa eseguita più tardi ha una finestra diversa. Queste ricerche tramite cmdlet alimentano l'indagine; non sono una riproduzione dichiarata dei confronti rigorosi delle soglie di EtcSec. Esaminate le date restituite e lo stato di abilitazione prima di assegnare un'azione.

2. Leggere l'attributo grezzo e normalizzare le date

Recuperate esplicitamente accountExpires con Get-ADUser -Properties. Microsoft documenta l'accesso agli attributi LDAP aggiuntivi tramite questo parametro, insieme a -SearchBase e -Server per selezionare il contesto di directory. Microsoft Learn: Get-ADUser

Questo inventario illustrativo conserva il valore grezzo e indica lo stato della conversione. Distingue deliberatamente un valore non disponibile o non valido da un valore sentinella documentato che indica l'assenza di scadenza:

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 un tempo di file in un DateTime UTC e rifiuta gli input fuori intervallo. I due valori sentinella per gli account che non scadono vengono gestiti prima della conversione. Le etichette di errore di questo esempio sono etichette proposte per la revisione, non output del parser del collector. Microsoft Learn: DateTime.FromFileTimeUtc

I campi manager e description della directory sono indizi per individuare un responsabile, non una prova che la persona indicata abbia autorizzato l'accesso. Confermate il responsabile tramite il contratto attuale, la richiesta di accesso o il registro del servizio. Lasciate visibili le responsabilità non risolte anziché usare un campo vuoto come permesso di rinnovo.

3. Trasformare le date in un registro di azioni

Per ogni identità nell'ambito, conservate l'identificatore stabile, l'attributo grezzo, la scadenza normalizzata, lo stato di abilitazione, il timestamp della revisione e la fonte di directory. Aggiungete la data di fine aziendale, il responsabile, le dipendenze, la decisione e il riferimento della modifica. Distinguete gli account già scaduti, quelli che non scadono mai e le date illeggibili dalla coda delle scadenze imminenti.

Una dipendenza applicativa deve diventare un'attività per il proprietario del servizio. Non deve trasformare silenziosamente un'identità con durata limitata in una permanente. Decidete come proseguirà il lavoro, chi sarà responsabile della sostituzione o della transizione e quale evidenza chiuderà quell'attività.

Correzione: confermare la data di fine o autorizzare una proroga delimitata (Remediation)

1. Decidere prima di modificare l'account

Confermate prima la data di riferimento e la popolazione, poi inviate ogni scadenza al suo responsabile. Chiedete se la data di fine originale sia ancora valida e se l'utente necessiti ancora dello stesso accesso. Registrate la risposta insieme alla fonte dell'approvazione. Una risposta mancante lascia la revisione irrisolta; non autorizza una proroga.

Quando l'accesso deve terminare come previsto, coordinate la rimozione dei diritti, la revisione delle appartenenze e il passaggio delle applicazioni con i team responsabili. Quando il lavoro continua, richiedete una nuova data di fine delimitata e un motivo autorizzato. Separate questi due esiti nel registro affinché un rinnovo massivo non venga scambiato per una correzione completata.

2. Applicare soltanto la data approvata

Microsoft documenta Set-ADAccountExpiration per impostare un'ora di scadenza esatta. Il parametro -DateTime assume l'ora locale se non diversamente specificato; omettere l'ora significa mezzanotte locale. Usate l'istante esatto approvato e registratelo esplicitamente. Microsoft Learn: Set-ADAccountExpiration

La seguente proroga mirata illustrativa usa un'identità di esempio e una scadenza UTC. Eseguite prima l'anteprima in un ambiente autorizzato. Applicate la scrittura separata soltanto dopo aver verificato che l'identità e la data corrispondano all'approvazione registrata. Questi comandi non sono stati eseguiti qui.

$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

Non inviate l'intero report delle scadenze a questa scrittura. Un risultato di query stabilisce una condizione sulla data; non fornisce alcuna approvazione a proseguire l'accesso. Allo stesso modo, eliminare la scadenza è una decisione di politica separata, non una correzione ordinaria per un rilievo di scadenza imminente.

3. Rileggere e conservare la decisione

Dopo la modifica, leggete lo stesso account dal server scelto. Conservate i vecchi e nuovi valori grezzi, le date normalizzate, il server, il timestamp, l'approvazione e il riferimento della modifica:

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

Normalizzate il valore grezzo con il metodo dell'inventario e confrontatelo con l'istante UTC approvato. Questa rilettura verifica il valore del server selezionato; quando il processo dipende da altri controller di dominio, organizzate la loro verifica secondo il processo del team di directory. Un'approvazione salvata senza rilettura non dimostra che l'attributo sia cambiato come previsto.

Per le cessazioni pianificate, conservate la prova che le attività assegnate di rimozione dei diritti e transizione dei servizi siano state completate. Per le proroghe, programmate la revisione successiva intorno alla nuova scadenza. In entrambi i casi, distinguete l'attributo dell'account dai ticket, dalle connessioni e dagli accessi applicativi. Il registro deve indicare cosa è stato verificato e cosa resta affidato a un altro responsabile.

Come EtcSec rileva questa situazione

L'etc-collector di EtcSec implementa ACCOUNT_EXPIRE_SOON in public/internal/audit/detectors/ad/accounts/status/account-expire-soon.go. L'ispezione statica di Detect() mostra la logica seguente; per questo articolo non è stato eseguito alcun audit cliente:

1. Prendere l'istante di riferimento da data.Now.
2. Calcolare la soglia superiore con now.AddDate(0, 0, 30).
3. Escludere ogni utente il cui flag Disabled è true.
4. Escludere ogni utente il cui AccountExpires analizzato è il tempo zero.
5. Selezionare soltanto date strettamente successive all'istante di riferimento e strettamente precedenti alla soglia superiore.

Le soglie inferiore e superiore sono entrambe escluse. Gli account già scaduti sono esclusi, così come una scadenza esattamente uguale all'istante di riferimento dell'audit. Count è il numero di utenti selezionati, non il numero di domini, approvazioni o attività di cessazione mancanti. Il detector restituisce un rilievo Medium con tale conteggio; allega dettagli sugli utenti interessati solo quando IncludeDetails è abilitato e il conteggio è positivo.

Questo controllo non contiene condizioni relative a gruppi privilegiati, account di servizio o segreti. Copre tutti gli utenti raccolti che soddisfano le condizioni sulla data e sullo stato di abilitazione. La finestra di trenta giorni è una scelta di prodotto dichiarata, non un requisito Microsoft, ANSSI o CIS. L'implementazione usa l'aggiunta di date di calendario; conservate il riferimento e le soglie dell'audit quando spiegate un risultato specifico.

Il parser LDAP popola AccountExpires tramite parseFileTime in public/internal/providers/ldap/parser.go. Un input vuoto, 0, il valore sentinella massimo con segno a 64 bit e gli errori di conversione in intero diventano tempo zero senza un messaggio diagnostico per valore in questa funzione ausiliaria. Anche i valori precedenti alla soglia di conversione dell'epoca Unix diventano zero. Di conseguenza, una data analizzata come zero può rappresentare dati senza scadenza oppure un input non disponibile o inutilizzabile. Il detector esclude entrambi.

Usate ACCOUNT_EXPIRE_SOON per avviare la revisione dei responsabili e delle scadenze. Un conteggio positivo non dimostra un attacco, la scadenza di una password, una proroga non autorizzata o la necessità di rinnovo. Chiudete la revisione con una decisione documentata sulla data di fine, uno stato dell'attributo verificato e attività di rimozione degli accessi o gestione delle dipendenze assegnate separatamente.