Găsiți conturi de utilizator Inactive în domeniul dvs.
Active Directory este un serviciu de director care menține informații despre utilizatori, computere și obiecte conexe. Iată cum puteți găsi conturi de utilizator inactive.
este o bază de date cu informații relaționale care necesită întreținere în timp pentru a fi utile și relevante. Un director va avea conturi care nu mai sunt utilizate. Găsirea acestor conturi în Active Directory nu este atât de ușoară pe cât pare la prima vedere. Să mergem prin găsirea conturilor de utilizator inactive și automatizarea eliminării acestora.
definiți criteriile de căutare
să definim ceea ce este necesar pentru acest proces. Scopul nostru este de a localiza conturile angajaților care nu s-au conectat la rețea pentru o perioadă lungă de timp. Am folosit întotdeauna 90 sau 120 de zile ca o măsură bună pentru a interoga inactivitatea, dar acest număr poate fi la fel de scăzut 14 zile. Trebuie să decideți ce este potrivit pentru organizația dvs. 90 de zile oferă o pernă suficient de mare pentru a permite oamenilor să iasă din birou pentru vacanță, urgențe familiale sau concedii medicale extinse. Odată ce conturile ajung la 90 de zile de inactivitate, dorim să dezactivăm aceste conturi și să le mutăm într-un OU separat.
definirea a ceea ce căutăm mai întâi ne permite să construim un set de reguli simplu de urmat. Setul nostru de reguli arată astfel:
- găsiți și dezactivați conturile active care nu au activitate de conectare timp de 90 de zile.
- mutați fiecare cont dezactivat în utilizatorii dezactivați OU
- marcați fiecare utilizator dezactivat cu un comentariu că un proces automat L-a dezactivat.
Găsiți proprietăți de inactivitate a contului
fiecare cont de utilizator are mai multe atribute care conțin informații de conectare. Vrem să găsim atribute care arată ultima dată de conectare. Dacă putem găsi aceste atribute, le putem folosi pentru a interoga conturile care nu sunt autentificate de la o anumită dată. Putem folosi PowerShell pentru a afișa toate regulile și pentru a alege un atribut cu care să lucrăm.
Get-ADUser este cel mai utilizat cmdlet pentru afișarea informațiilor utilizatorului. Ai putea folosi Get-ADObject și Search-ADAccount, dar Get-ADUser este cel mai bun cmdlet pentru sarcina noastră. Pentru a afișa toate proprietățile utilizatorului, trebuie să adăugăm-properties * la sintaxa cmdlet. Dacă lăsăm această sintaxă afară, vom vedea doar proprietățile implicite, care sunt doar 10 proprietăți.
Get-ADUser Michael_Kanakos -Properties *
returnăm o listă lungă de câmpuri din interogarea noastră (peste 150!). Putem căuta atribute conțin anumite cuvinte folosind metacaractere. Acest lucru ne ajută să localizăm atribute care pot fi utile pentru sarcina noastră. Vrem să găsim informații de conectare, așa că să căutăm atribute care conțin cuvântul Logon.
odată ce îi spunem lui PowerShell să obțină toate proprietățile, ar fi util dacă am putea limita lista de proprietăți pentru a afișa numai proprietățile care se potrivesc cu logarea cuvântului. Select-Object oferă posibilitatea de a face un meci wild-card și de a limita rezultatele noastre. Caracterul | (numit” conducta”) ia rezultatele din stânga și le trece la Select-Object. Select-Object efectuează apoi potrivirea wild-card și apoi limitează rezultatele pe baza criteriilor noastre 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
rezultatele vor varia puțin în funcție de nivelul funcțional al domeniului Active Directory. Căutarea mea returnează opt atribute. Trei uite promițătoare: LastLogon, LastLogonDate și LastLogonTimeStamp. Unele dintre valori pot părea puțin ciudate dacă nu sunteți familiarizați cu modul în care Active Directory stochează informații despre dată/oră în anumite atribute. Unele informații despre dată sunt informații tradiționale despre dată și oră, iar unele sunt salvate ca „căpușe.”
valorile PowerShell și.NET Framework data-time reprezintă Datele ca număr de căpușe de la 12:00 am 1 ianuarie 0001. Căpușele sunt egale cu o zecime de milionime de secundă, ceea ce înseamnă că există 10.000 de căpușe pe milisecundă. Există cmdleturi matematice care pot converti căpușele într-un format standard de dată.
PowerShell afișează bifa reală care reprezintă data/ora. Dacă sunteți confortabil de conversie căpușe la data format, atunci poti sa te uiti la acele domenii în Active Directory utilizator și calculatoare sau Active Directory Administrative Center. În ambele aplicații, căpușele sunt reprezentate ca un format de dată-oră.
ADUser-Logon-Properties
Logon atribute explicate
căutarea noastră a găsit mai multe proprietăți care afișează informații de conectare la Dată/oră. Două proprietăți au aceeași dată și oră și una nu. Ce se întâmplă aici?
varianța în info Data-time este de proiectare și este în loc de a proteja DC de la obtinerea zdrobit cu trafic de replicare încercarea de a păstra toate informațiile de conectare în sincronizare. Proprietatea LastLogon se actualizează de fiecare dată când vă autentificați, dar datele sunt stocate pe DC împotriva cărora v-ați autentificat și nu sunt reproduse la celelalte DC. proprietățile LastLogonTimeStamp și lastlogondate sunt reproduse la toate DC, dar replicarea se întâmplă doar rar.
dacă ne uităm la date, putem vedea cum replicarea întârziată ar putea afecta interogarea noastră. Observați că LastLogonTimeStamp este de fapt cu două zile în urmă în acest exemplu. De fiecare dată când un utilizator se conectează interactiv, atinge o partajare de fișiere de rețea sau efectuează alte activități care necesită ca rețeaua să autentifice contul, stochează informațiile de conectare în Active Directory. Dacă dc-ul a replicat acele date de fiecare dată când cineva a atins ceva în rețea, DC-ul ar putea fi copleșit într-un mediu mare. Rezultatul este că unele informații de logare sunt corecte, dar nu sunt reproduse, iar unele informații de logare se reproduc, dar numai ocazional.
pentru cerințele noastre, nu avem nevoie de marcajul de timp exact de conectare. Trebuie doar să găsim conturi care nu s-au conectat de mult timp (mai mult de 90 de zile). Orice valoare poate fi utilă, chiar dacă Data este oprită cu câteva zile. Dacă folosim datele mele de conectare ca exemplu, timpul interogat ar putea fi 11/11 sau 11/13, în funcție de valoarea pe care o folosim. Fast forward trei luni și să presupunem că nu am conectat din nou. O dată ar semnala ca inactiv pentru a fi de peste 90 de zile, și un câmp nu ar fi. Dar dacă am configurat acest proces pentru a rula lunar, mi-ar prinde contul data viitoare când vom verifica. Asta e partea critică. Dacă facem acest lucru în mod regulat, putem folosi oricare câmp atâta timp cât verificăm în mod constant.
am folosit proprietatea LastLogonDate din două motive. În primul rând, este deja o valoare de dată, așa că nu trebuie să mă ocup de conversia valorii. În al doilea rând, este o valoare reprodusă și asta îmi face viața mai ușoară. Dacă aș folosi LastLogon, aș avea date care nu sunt actualizate pentru persoanele care se autentifică împotriva altor controlere de domeniu din rețeaua mea. Mi-ar trebui să interogheze DC locale pentru fiecare utilizator pentru a obține cele mai recente timestamp, și că este o mulțime de lucru pentru a face și nu foarte eficient.
pentru a obține informații pe un singur cont, codul este simplu.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
pentru a face acest lucru pentru toți utilizatorii mei necesită doar un pic mai mult cod. Trebuie să folosim un filtru pentru a interoga toate conturile de utilizator.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
acum să găsim doar conturile cu o dată de conectare mai veche de 90 de zile. Avem nevoie de data curentă salvată pentru a fi utilizată ca operator de comparație.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
acest cod preia toți utilizatorii care nu s-au conectat peste 90 de zile. Salvăm data de acum 90 de zile la o variabilă. Putem crea un filtru de anunțuri pentru a găsi logon-uri mai mici decât acea dată. Apoi, trebuie să adăugăm cerința de a interoga numai conturile active. În acest exemplu, folosesc splatting pentru a face Codul mai lizibil, deoarece sintaxa este foarte lungă. Splatting cmdlets AD poate fi dificil, așa că am arătat, de asemenea, versiunea de formă lungă a sintaxei sub exemplul 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
acest lucru ne oferă utilizatorilor noștri inactivi care sunt activați. Salvăm rezultatele într-o variabilă pentru reutilizare. Proprietatea DistinguishedName este necesară mai târziu. Odată ce găsim utilizatorii, putem lucra la următorul pas: dezactivarea conturilor. Utilizăm cmdletul Set-ADUser pentru a efectua modificări ale contului de utilizator AD.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
ne-am dezactivat conturile de utilizator. Este timpul să le mutați într-un nou OU. Pentru exemplul nostru, vom folosi OU numit utilizatori cu handicap. Numele distins pentru acest OU este „OU = Disabled-Users, DC = Contoso, DC= Com” folosim cmdletul Move-ADObject pentru a muta utilizatorii la OU țintă.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
în pasul nostru final, am folosit Move-ADObject pentru a muta utilizatorii într-un OU nou. Acum avem Codul De Bază necesar pentru a face o sarcină automată fiabilă și repetabilă. Deci, ce urmează? Aceasta depinde de cerințele dvs. individuale. Acest cod poate și ar trebui să fie configurat pentru a rula automat în același timp în fiecare lună. O modalitate ușoară de a face acest lucru este de a crea o lucrare programată pentru a rula codul lunar.
există mai multe am putea adăuga la acest cod pentru a face mai bine. Codul pentru verificarea erorilor și câmpurile suplimentare de informații despre utilizator ar fi două adăugiri utile. Majoritatea echipelor care execută aceste tipuri de activități generează un raport despre ceea ce a fost dezactivat pentru ca cineva să revizuiască, astfel încât câmpurile suplimentare vor varia. Puteți include mai multe câmpuri din Active Directory pentru a face un raport mai util. Am putea lua această sarcină un pas mai departe prin crearea unei alte sarcini pentru a șterge acei utilizatori cu handicap după 6 luni.
rezolvarea solicitărilor de automatizare provocatoare este mult mai ușoară atunci când sarcinile sunt împărțite în bucăți gestionabile. Am început cu cerințe și ne-am construit sintaxa în pași mici; confirmând că fiecare pas funcționează înainte de a încerca să adăugăm o altă variabilă. Făcând acest lucru, am făcut această sarcină ușor de înțeles și, sperăm, o experiență de învățare excelentă.