Trova account utente inattivi nel tuo dominio
Active Directory è un servizio di directory che mantiene informazioni su utenti, computer e oggetti correlati. Ecco come è possibile trovare gli account utente inattivi.
È un database di informazioni relazionali che necessita di manutenzione nel tempo per essere utile e pertinente. Una directory avrà account non più utilizzati. Trovare quegli account in Active Directory non è così facile come sembra a prima vista. Camminiamo attraverso la ricerca di account utente inattivi e automatizzando la loro rimozione.
Definire i criteri di ricerca
Definiamo ciò che è necessario per questo processo. Il nostro obiettivo è individuare gli account dei dipendenti che non hanno effettuato l’accesso alla rete per un periodo prolungato. Ho sempre usato 90 o 120 giorni come una buona misura per interrogare l’inattività, ma quel numero può essere di 14 giorni. Devi decidere cosa è giusto per la tua organizzazione. 90 giorni dà un cuscino abbastanza grande per consentire alle persone fuori ufficio per le vacanze, le emergenze familiari o le foglie mediche estese. Una volta che gli account raggiungono i 90 giorni di inattività, vogliamo disabilitare tali account e spostarli in una OU separata.
Definire ciò che stiamo cercando per primo ci permette di costruire un semplice set di regole da seguire. Il nostro set di regole è simile a questo:
- Trova e disattiva gli account attivi che non hanno attività di accesso per 90 giorni.
- Sposta ogni account disabilitato in Disabled-Users OU
- Contrassegna ogni utente disabilitato con un commento che un processo automatizzato lo ha disabilitato.
Trova le proprietà di inattività dell’account
Ogni account utente ha diversi attributi contenenti le informazioni di accesso. Vogliamo trovare gli attributi che mostrano l’ultima volta di accesso. Se riusciamo a trovare quegli attributi, possiamo usarli per interrogare gli account non registrati da una certa data. Possiamo usare PowerShell per visualizzare tutti i set di regole e scegliere un attributo con cui lavorare.
Get-ADUser è il cmdlet più utilizzato per mostrare le informazioni dell’utente. È possibile utilizzare Get-ADObject e Search-ADAccount, ma Get-ADUser è il miglior cmdlet per il nostro compito. Per mostrare tutte le proprietà dell’utente, dobbiamo aggiungere-properties * alla sintassi del cmdlet. Se lasciamo fuori quella sintassi, vedremo solo le proprietà predefinite, che sono solo 10 proprietà.
Get-ADUser Michael_Kanakos -Properties *
Restituiamo una lunga lista di campi dalla nostra query (oltre 150!). Possiamo cercare gli attributi contengono parole particolari utilizzando i caratteri jolly. Questo ci aiuta a individuare gli attributi che possono essere utili per il nostro compito. Vogliamo trovare le informazioni di accesso, quindi cerchiamo gli attributi contenenti la parola Accesso.
Una volta detto a PowerShell di ottenere tutte le proprietà, sarebbe utile limitare l’elenco delle proprietà per mostrare solo le proprietà che corrispondono all’accesso alla parola. Select-Object offre la possibilità di fare una partita wild-card e limitare i nostri risultati. Il carattere | (chiamato “la pipe”) prende i risultati a sinistra e li passa a Select-Object. Select-Object esegue quindi la corrispondenza wild-card e quindi limita i risultati in base ai nostri criteri wild-card.
Get-ADUser username -Properties * | Select-Object *logon*
BadLogonCount : 0
lastLogon : 132181280348543735
LastLogonDate : 11/11/2019 9:08:45 PM
lastLogonTimestamp : 132179981259860013
logonCount : 328
LogonWorkstations :
MNSLogonAccount : False
SmartcardLogonRequired : False
I risultati varieranno leggermente in base al livello funzionale del dominio di Active Directory. La mia ricerca restituisce otto attributi. Tre sembrano promettenti: LastLogon, LastLogonDate e LastLogonTimeStamp. Alcuni dei valori possono sembrare un po ‘ strani se non si ha familiarità con il modo in cui Active Directory memorizza le informazioni su data/ora in determinati attributi. Alcune informazioni data è tradizionale informazioni data-ora, e alcuni vengono salvati come ” zecche.”
I valori data-ora di PowerShell e.NET Framework rappresentano le date come numero di tick dalle 12:00 del 1 gennaio 0001. Le zecche sono pari a un dieci milionesimo di secondo, il che significa che ci sono 10.000 zecche per millisecondo. Esistono cmdlet matematici che possono convertire le zecche in un formato di data standard.
PowerShell mostra il segno di spunta effettivo che rappresenta la data / ora. Se hai dimestichezza con la conversione delle zecche in formato data, puoi guardare quei campi in Active Directory User and Computers o Active Directory Administrative Center. In entrambe le app, i tick sono rappresentati come formato data-ora.
ADUser-Logon-Properties
Attributi di accesso Explained
La nostra ricerca ha trovato più proprietà che mostrano le informazioni di accesso data/ora. Due proprietà hanno la stessa data e ora e una no. Che succede qui?
La varianza nelle informazioni data-ora è di progettazione ed è in atto per proteggere i DC da essere schiacciati dal traffico di replica cercando di mantenere tutte le informazioni di accesso sincronizzate. La proprietà LastLogon si aggiorna ogni volta che si esegue l’autenticazione, ma i dati vengono memorizzati sul DC autenticato e non replicati sugli altri DC. Le proprietà LastLogonTimeStamp e LastLogonDate vengono replicate su tutti i DC ma la replica avviene solo raramente.
Se guardiamo le date, possiamo vedere come la replica ritardata potrebbe influire sulla nostra query. Si noti che LastLogonTimeStamp è in realtà indietro di due giorni in questo esempio. Ogni volta che un utente accede in modo interattivo, tocca una condivisione di file di rete o esegue altre attività che richiedono alla rete di autenticare l’account, memorizza le informazioni di accesso in Active Directory. Se la DC replicasse quei dati OGNI VOLTA che qualcuno toccasse qualcosa sulla rete, la DC potrebbe essere sopraffatta in un ambiente di grandi dimensioni. Il risultato è che alcune informazioni di accesso sono accurate ma non replicate e alcune informazioni di accesso vengono replicate, ma solo occasionalmente.
Per i nostri requisiti, non abbiamo bisogno del timestamp di accesso ESATTO. Abbiamo solo bisogno di trovare gli account che non hanno effettuato l’accesso da molto tempo (superiore a 90 giorni). Qualsiasi valore può essere utile, anche se la data è disattivata di alcuni giorni. Se usiamo le mie date di accesso come esempio, l’ora interrogata potrebbe essere 11/11 o 11/13, a seconda del valore che usiamo. Avanti veloce di tre mesi e presumo che non abbia mai più effettuato l’accesso. Una data sarebbe contrassegnata come inattiva per avere più di 90 giorni e un campo no. Ma se ho impostato questo processo per eseguire mensilmente, vorrei prendere l’account la prossima volta che controlliamo. Questa è la parte critica. Se lo facciamo regolarmente, possiamo usare entrambi i campi finché controlliamo costantemente.
Ho usato la proprietà LastLogonDate per due motivi. Innanzitutto, è già un valore di data, quindi non ho a che fare con la conversione del valore. Secondo, è un valore replicato, e questo mi rende la vita più facile. Se avessi usato LastLogon, avrei date che non sono aggiornate per le persone che si autenticano contro altri controller di dominio nella mia rete. Dovrei interrogare il DC locale per ogni utente per ottenere l’ultimo timestamp, e questo è molto lavoro da fare e non molto efficiente.
Per ottenere le informazioni su un singolo account, il codice è semplice.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
Per fare questo per tutti i miei utenti richiede solo un po ‘ più di codice. Dobbiamo usare un filtro per interrogare tutti gli account utente.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
Ora troviamo solo gli account con una data di accesso superiore a 90 giorni. Abbiamo bisogno della data corrente salvata da utilizzare come operatore di confronto.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
Questo codice recupera tutti gli utenti che non hanno effettuato l’accesso per più di 90 giorni. Salviamo la data 90 giorni fa in una variabile. Possiamo creare un filtro ANNUNCI per trovare accessi inferiori a tale data. Successivamente, dobbiamo aggiungere il requisito di interrogare solo gli account attivi. In questo esempio, sto usando splatting per rendere il codice più leggibile perché la sintassi è molto lunga. I cmdlet di ANNUNCI splatting possono essere complicati, quindi ho anche mostrato la versione a forma lunga della sintassi sotto l’esempio di splatting.
$date = (get-date).AddDays(-90)
$paramhash = @{
Filter = "LastLogonDate -lt $date -and Enabled -eq $true"
Properties = 'LastLogonDate'
}
$SelectProps = 'Name','LastLogonDate','Enabled','DistinguishedName'
$InactiveUsers = Get-Aduser @paramhash | Select-Object $SelectProps
$InactiveUsers = Get-ADUser -Filter {LastLogonDate -lt $date -and Enabled -eq $true} -properties LastLogonDate, DistinguishedName | Select-Object Name, LastLogonDate, Enabled, DistinguishedName
Questo ci dà i nostri utenti inattivi che sono abilitati. Salviamo i risultati in una variabile per il riutilizzo. La proprietà DistinguishedName è necessaria in seguito. Una volta trovati gli utenti, possiamo lavorare sul nostro prossimo passo: disabilitare gli account. Utilizziamo il cmdlet Set-ADUser per apportare modifiche all’account utente dell’annuncio.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
Abbiamo disabilitato i nostri account utente. È tempo di spostarli in un nuovo OU. Per il nostro esempio, useremo la OU denominata Disabled-Users. Il nome distinto per questa OU è “OU=Disabled-Users, DC=Contoso,DC = Com” Usiamo il cmdlet Move-ADObject per spostare gli utenti nell’OU di destinazione.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
Nel nostro passaggio finale, abbiamo usato Move-ADObject per spostare gli utenti in una nuova OU. Ora abbiamo il codice di base necessario per fare un affidabile, attività automatizzata ripetibile. E ora che facciamo? Questo dipende dalle vostre esigenze individuali. Questo codice può e deve essere impostato per essere eseguito automaticamente alla stessa ora ogni mese. Un modo semplice per farlo è creare un lavoro pianificato per eseguire il codice su base mensile.
C’è altro che potremmo aggiungere a questo codice per renderlo migliore. Il codice per il controllo degli errori e ulteriori campi di informazioni utente sarebbero due aggiunte utili. La maggior parte dei team che eseguono questi tipi di attività genera un report di ciò che è stato disabilitato per qualcuno da rivedere, quindi i campi aggiuntivi vareranno. È possibile includere più campi da Active Directory per rendere più utile un report. Potremmo prendere questo compito un ulteriore passo avanti con la creazione di un altro compito per eliminare gli utenti disabili dopo 6 mesi.
Risolvere le richieste di automazione impegnative è molto più semplice quando le attività sono divise in pezzi gestibili. Abbiamo iniziato con i requisiti e costruito la nostra sintassi a piccoli passi; confermando che ogni passaggio funziona prima di provare ad aggiungere un’altra variabile. In questo modo, abbiamo reso questo compito facile da capire e, auspicabilmente, una grande esperienza di apprendimento.