Revisione AD logonCount per DC: qualificare i totali prima del ritiro dell’account

Cosa stabilisce una revisione AD logonCount per DC

Una revisione AD logonCount per DC esamina la provenienza di un contatore della directory prima di usarlo per ritirare un account amministrativo. Un valore basso su un controller di dominio può avviare una revisione. Non stabilisce l’attività dell’account nell’intero dominio, le sue autorizzazioni attuali o se il proprietario ne abbia ancora bisogno.

Il risultato utile è un registro della revisione: l’identità dell’account, ogni DC nell’ambito definito, ciascun valore restituito, le letture non risolte, gli accessi attuali e la decisione del proprietario. Conservate insieme queste osservazioni affinché un amministratore possa spiegare perché un account è stato mantenuto, sottoposto a ulteriori indagini o inserito in un processo di ritiro approvato.

Questa guida propone una procedura di raccolta in sola lettura e di decisione. Gli esempi PowerShell adattano parametri documentati in Microsoft Learn a identità e server illustrativi; non sono stati eseguiti nel dominio di un cliente. Sostituite i valori di esempio con valori verificati e usate il modulo ActiveDirectory con un’identità autorizzata a leggere la directory.

Come funziona il contatore

La documentazione dell’attributo Logon-Count di Microsoft descrive un contatore degli accessi riusciti mantenuto indipendentemente su ogni DC, senza replica. Raccomanda di interrogare tutti i DC e sommare i loro valori. Zero significa sconosciuto. I DC ritirati possono lasciare lacune nella cronologia, e il limite documentato di 65535 rende un contatore saturo inadatto a monitorare l’attività su quel DC.

Trattate l’attributo come un conteggio cumulativo con limiti di copertura e cronologia, anziché come un riferimento temporale. Un conteggio di 1–4 non contiene alcuna data da cui calcolare un’inattività recente. Anche un insieme completo di letture attuali non può ricostruire i contributi dei controller ritirati. Registrate questi limiti accanto a qualsiasi subtotale invece di descriverlo come la cronologia dell’intera vita dell’account.

Non sostituite logonCount con badPwdCount quando il primo non è disponibile. La procedura correlata di triage badPwdCount qualifica i contatori degli errori prima di un verdetto di attacco. La sua disciplina di conservare server, orario e qualità della raccolta si applica anche qui, ma un contatore degli errori non risponde alla domanda sugli accessi riusciti.

Rilevamento: costruire una matrice di evidenze account/DC

Passaggio 1 — Fissare l’identità e l’ambito

Partite dal rilievo originale e conservate l’identificativo dell’account, l’endpoint del collector, l’orario di raccolta, la revisione del collector e gli errori. Confermate il dominio dell’account e l’inventario dei DC con il team operativo della directory. I due nomi host riportati sotto illustrano letture separate; non sono un elenco completo dei DC di un dominio reale.

Scegliete un identificativo stabile dell’account e verificatelo rispetto al rilievo prima di ripetere la lettura. Conservate il DN o GUID insieme al nome visualizzato nel registro della revisione. Se l’account non può essere risolto su un server, conservate l’errore di ricerca e indagate su identità, ambito o disponibilità della directory. Non create una voce numerica per un oggetto che non è stato restituito.

Microsoft documenta la selezione dell’identità, la selezione esplicita del server e gli attributi aggiuntivi in Get-ADUser. Questi adattamenti richiedono esplicitamente logonCount da un DC identificato per nome, anziché affidarsi alla selezione predefinita del server:

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc02.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Eseguite separatamente la stessa lettura documentata su ogni DC verificato nell’ambito definito. Salvate l’oggetto restituito e qualsiasi errore insieme all’endpoint selezionato e all’orario di lettura. Una connessione riuscita, da sola, non stabilisce che l’attributo richiesto sia stato restituito. Esaminate la proprietà invece di consentire a una successiva conversione numerica di trasformare un valore vuoto in zero.

Passaggio 2 — Conservare le osservazioni grezze

Usate una riga per account e DC. La matrice seguente è una struttura di evidenze raccomandata, non un esempio di output da un ambiente cliente né campi forniti automaticamente dal rilevatore.

Per uno zero restituito, mantenete lo zero letterale e contrassegnate il valore di attività come sconosciuto. Per un attributo assente, conservate l’assenza. Per un valore non valido, mantenete la rappresentazione originale e classificate l’interpretazione come non risolta. Per una lettura fallita, conservate l’errore e lasciate il conteggio non impostato. Questi stati possono richiedere interventi successivi diversi, anche se nessuno fornisce un conteggio di attività noto.

Se un server non è disponibile, mantenete la sua riga nell’ambito dichiarato. Assegnate il nuovo tentativo o l’indagine a un responsabile. Un nuovo tentativo riuscito diventa una nuova osservazione con il proprio orario; non deve cancellare il fallimento della raccolta originale. Allo stesso modo, conservate osservazioni diverse se la raccolta viene ripetuta, anziché scegliere il valore che fa apparire completa la revisione.

Passaggio 3 — Riepilogare senza cancellare l’incertezza

Sommate i valori positivi noti mantenendo la matrice completa. Presentate il risultato come subtotale noto ogni volta che un DC ha un valore sconosciuto o non è stato letto correttamente. Accanto a esso, elencate quali DC hanno contribuito, quali no, l’intervallo di raccolta e qualsiasi contatore saturo o contributo storico mancante.

Non eliminate silenziosamente dall’ambito i server non disponibili e non riempite le loro celle con zero. Un foglio di calcolo con un valore numerico in ogni riga può comunque contenere evidenze non risolte. Il riepilogo deve renderlo visibile alla persona che decide se sia necessaria un’ulteriore raccolta.

Usate la stessa regola quando confrontate le revisioni. Mantenete coerenti l’identità dell’account e la copertura dei DC, descrivete le modifiche all’inventario e conservate la matrice precedente. Un subtotale diverso può riflettere una copertura diversa; non fornisce automaticamente un intervallo di attività recente. Se la decisione richiede una cronologia, ottenete evidenze di attività qualificate separatamente per un periodo dichiarato e documentatene la copertura.

Correzione: rivedere gli accessi e il proprietario prima del ritiro (Remediation)

Passaggio 4 — Chiarire il marcatore amministrativo

Il rilevatore usa adminCount=1 per selezionare i candidati. Prima di definire amministrativo l’account, accertatene gli accessi attuali. La procedura di pulizia di adminCount obsoleto spiega perché il marcatore può persistere dopo la fine di un’appartenenza privilegiata. Seguite la sua revisione delle appartenenze e delle autorizzazioni anziché presumere che l’indicatore sia un inventario dei diritti attuali.

Per la decisione di ritiro, richiedete una revisione dei gruppi diretti e annidati, del gruppo primario, delle autorizzazioni delegate pertinenti e delle risorse che l’account può amministrare. Conservate nel caso il revisore, l’ambito e i percorsi non risolti. Un elenco di gruppi diretti dall’aspetto ordinario non chiude la questione più ampia degli accessi.

Questo può produrre esiti distinti: un account con accessi attuali giustificati; un ex account privilegiato con stato residuo; autorizzazioni ingiustificate che richiedono una modifica mirata; oppure accessi che rimangono non verificati. Registrate le evidenze effettive per la classificazione. Non cancellate adminCount semplicemente per eliminare questo rilievo e non trattate la pulizia dell’indicatore come il ritiro dell’account.

Passaggio 5 — Ottenere la decisione del proprietario

Identificate il proprietario responsabile e chiedete quali processi dipendono dall’account. Confrontate lo scopo dichiarato con le evidenze operative e le dipendenze disponibili. Includete gli usi pianificati, poco frequenti, di ripristino e di emergenza quando si applicano all’account; la loro rilevanza deve provenire dal proprietario e dall’ambiente, non da una spiegazione presunta per un contatore basso.

Il processo proposto separa la revisione del contatore dall’autorizzazione a modificare gli accessi. Se il ritiro è approvato, usate la procedura dell’organizzazione per il ciclo di vita degli account sull’identità verificata. Scegliete la modifica e il metodo di ripristino da quel piano approvato. Questa guida non prescrive una disabilitazione o eliminazione in massa basata sulla soglia del rilevatore.

Passaggio 6 — Validare l’esito registrato

Dopo una modifica approvata, rileggete lo stesso account sui server documentati e conservate separatamente i nuovi risultati. I parametri di identità, server e proprietà di Get-ADUser documentati sopra supportano anche questa lettura ripetibile:

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Ripetete la revisione degli accessi pertinente alla modifica e fate confermare al proprietario i processi interessati. Registrate lo stato effettivo dell’account, le autorizzazioni, le dipendenze rimanenti, gli errori e gli interventi successivi. La sola scomparsa dal rilievo non stabilisce che le autorizzazioni o le dipendenze aziendali siano state gestite correttamente.

Come EtcSec rileva questo caso

Il controllo di etc-collector esaminato è ADMIN_LOGON_COUNT_LOW, in Accounts, con gravità Info. Alla revisione del collector afca1b9f7bba6f076d6a6493371486071001452b, admin-logon-count-low.go:36 seleziona gli utenti abilitati con AdminCount=true, esclude LogonCount=0 e mantiene un conteggio diverso da zero inferiore a 5. Non applica alcun periodo di inattività. La soglia è un predicato del prodotto, non una regola per ritirare gli account.

Count è il numero di utenti corrispondenti, non una somma degli accessi. Il rilevatore restituisce il rilievo anche quando quel numero è zero; i dettagli degli utenti interessati vengono allegati quando sono richiesti ed esistono corrispondenze. Una corrispondenza è una pista d’indagine proveniente dalla vista raccolta.

Il provider LDAP limita quella vista. client.go:460 recupera gli utenti tramite la connessione selezionata senza aggregare i contatori dei DC. parser.go:41 richiede logonCount; il parser degli utenti lo legge tramite getIntAttr, la cui gestione dei valori assenti e degli interi non validi può produrre zero. Il rilevatore quindi non può distinguere tutti gli stati di raccolta che la matrice indipendente conserva. Escludere zero impedisce che un conteggio sconosciuto diventi un rilievo positivo, ma non verifica l’uso nell’intero dominio.

Il controllo non calcola alcun totale di dominio e non stabilisce diritti effettivi, proprietario, dipendenze o una cronologia di attività recente. adminCount è il suo marcatore di selezione, non una prova di privilegi attuali. Usate ADMIN_LOGON_COUNT_LOW per avviare la revisione, poi qualificate ogni osservazione dei DC e gli accessi dell’account prima di deciderne il futuro.