Find inaktive brugerkonti i dit domæne
Active Directory er en katalogtjeneste, der vedligeholder oplysninger om brugere, computere og relaterede objekter. Sådan finder du inaktive brugerkonti.
det er en database med relationelle oplysninger, der skal vedligeholdes over tid for at være nyttige og relevante. En mappe vil have konti, der ikke længere bruges. At finde disse konti i Active Directory er ikke så let som det lyder ved første øjekast. Lad os gå gennem at finde inaktive brugerkonti og automatisere at fjerne dem.
Definer søgekriterier
lad os definere, hvad der er nødvendigt for denne proces. Vores mål er at finde medarbejderkonti, der ikke har logget ind på netværket i en længere periode. Jeg har altid brugt 90 eller 120 dage som et godt mål for at forespørge inaktivitet ved, men det tal kan være så lavt 14 dage. Du skal beslutte, hvad der er rigtigt for din organisation. 90 dage giver en stor nok pude til at give folk ud af kontoret til ferie, familie nødsituationer eller udvidede medicinske blade. Når kontiene når 90 dages inaktivitet, vil vi deaktivere disse konti og flytte dem til en separat OU.
at definere det, vi leder efter først, giver os mulighed for at opbygge et simpelt regelsæt, der skal følges. Vores regelsæt ser sådan ud:
- Find og deaktiver aktive konti, der ikke har nogen logonaktivitet i 90 dage.
- Flyt hver deaktiveret konto til handicappede brugere OU
- marker hver deaktiveret bruger med en kommentar om, at en automatiseret proces deaktiverede den.
find egenskaber for Kontoinaktivitet
hver brugerkonto har flere attributter, der indeholder loginoplysninger. Vi ønsker at finde attributter, der viser sidste login tid. Hvis vi kan finde disse attributter, kan vi bruge dem til at forespørge efter konti, der ikke er logget ind siden en bestemt dato. Vi kan bruge Strømshell til at vise alle regelsættet og vælge en attribut til at arbejde med.
Get-Aduser er den mest anvendte cmdlet til at vise brugeroplysninger. Du kan bruge Get-ADObject og Search-ADAccount, men Get-ADUser er den bedste cmdlet til vores opgave. For at vise alle brugeregenskaber skal vi tilføje-egenskaber * til cmdlet-syntaksen. Hvis vi udelader denne syntaks, vil vi kun se standardegenskaberne, som kun er 10 egenskaber.
Get-ADUser Michael_Kanakos -Properties *
vi returnerer en lang liste med felter fra vores forespørgsel (over 150!). Vi kan søge efter attributter indeholder bestemte ord ved hjælp af jokertegn. Dette hjælper os med at finde attributter, der kan være nyttige til vores opgave. Vi vil finde logonoplysninger, så lad os søge efter attributter, der indeholder ordet Logon.
når vi først har bedt os om at få alle egenskaber, ville det være nyttigt, hvis vi kunne begrænse listen over egenskaber til kun at vise egenskaber, der matcher ordlogon. Select-Object giver mulighed for at lave en vildkortkamp og begrænse vores resultater. Den / tegn (kaldet” The pipe”) tager resultaterne til venstre og sender dem til Select-Object. Select-Object udfører derefter matchningen af jokerkortet og begrænser derefter resultaterne baseret på vores jokerkortkriterier.
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
resultaterne vil variere lidt baseret på, hvad domænefunktionsniveauet for Active Directory er. Min søgning returnerer otte attributter. Tre ser lovende ud: LastLogon, LastLogonDate og LastLogonTimeStamp. Nogle af værdierne kan se lidt underlige ud, hvis du ikke er bekendt med, hvordan Active Directory gemmer dato/klokkeslætsoplysninger i visse attributter. Nogle Dato info er traditionel dato-tid info, og nogle gemmes som “flåter.”
Effektskal og.net-rammedatotidsværdier repræsenterer datoer som antallet af flåter siden 12:00 1. januar 0001. Flåter er lig med en ti milliontedel af et sekund, hvilket betyder, at der er 10.000 flåter pr. Der er matematiske cmdlets, der kan konvertere flåter til et standarddatoformat.
Effektskal viser det faktiske kryds, der repræsenterer dato / klokkeslæt. Hvis du har det godt med at konvertere flåter til datoformat, kan du se på disse felter i Active Directory-bruger og computere eller Active Directory Administrative Center. I begge apps, flåterne er repræsenteret som et tidsdatoformat.
aduser-Logon-Properties
Logon attributter forklaret
vores søgning fundet flere egenskaber, der viser dato/tid logon oplysninger. To ejendomme har samme dato og klokkeslæt, og en gør det ikke. Hvad foregår der her?
variansen i dato-tid info Er ved design og er på plads for at beskytte DC ‘ er fra at blive knust med replikering trafik forsøger at holde alle logon info i sync. LastLogon-egenskaben opdateres hver gang du godkender, men dataene gemmes på den DC, du godkendte mod og ikke replikeres til de andre DC ‘er. LastLogonTimeStamp og LastLogonDate-egenskaberne replikeres til alle DC’ er, men replikationen sker kun sjældent.
hvis vi ser på datoerne, kan vi se, hvordan den forsinkede replikation kan påvirke vores forespørgsel. Bemærk, at LastLogonTimeStamp faktisk er to dage bagud i dette eksempel. Hver gang en bruger interaktivt logger ind, berører en netværksfildeling eller udfører andre aktiviteter, der kræver, at netværket godkender kontoen, gemmer den logonoplysninger i Active Directory. Hvis dc ‘erne replikerede disse data hver gang nogen rørte ved noget på netværket, kunne DC’ erne blive overvældet i et stort miljø. Resultatet er, at nogle logonoplysninger er nøjagtige, men ikke replikeres, og nogle logonoplysninger replikeres, men kun lejlighedsvis.
for vores krav har vi ikke brug for den nøjagtige logon tidsstempel. Vi behøver kun at finde konti, der ikke har logget på i lang tid (større end 90 dage). Enhver værdi kan være nyttig, selvom datoen er slukket med et par dage. Hvis vi bruger mine logondatoer som et eksempel, kan den forespurgte tid være 11/11 eller 11/13, afhængigt af den værdi, vi bruger. Spol frem tre måneder og antager, at jeg aldrig er logget på igen. En dato ville markere som inaktiv for at være forbi 90 dage, og et felt ville ikke. Men hvis jeg konfigurerede denne proces til at køre månedligt, ville jeg fange kontoen næste gang vi tjekker. Det er den kritiske del. Hvis vi gør dette regelmæssigt, kan vi bruge begge felter, så længe vi konsekvent kontrollerer.
jeg brugte LastLogonDate-ejendommen af to grunde. For det første er det allerede en datoværdi, så jeg behøver ikke at beskæftige mig med at konvertere værdien. For det andet er det en replikeret værdi, og det gør mit liv lettere. Hvis jeg brugte LastLogon, jeg ville have datoer, der ikke er opdaterede for folk, der godkender mod andre domænecontrollere i mit netværk. Jeg bliver nødt til at forespørge den lokale DC for hver bruger for at få den nyeste tidsstempel, og det er meget arbejde at gøre og ikke særlig effektivt.
for at få info om en enkelt konto, koden er enkel.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
for at gøre dette for alle mine brugere kræver kun lidt mere kode. Vi skal bruge et filter til at forespørge på alle brugerkonti.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
lad os nu kun finde konti med en logondato ældre end 90 dage. Vi har brug for den aktuelle dato gemt til brug som sammenligningsoperatør.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
denne kode henter alle brugere, der ikke har logget ind over 90 dage. Vi gemmer datoen for 90 dage siden til en variabel. Vi kan oprette et ANNONCEFILTER for at finde logoner mindre end den dato. Dernæst skal vi tilføje kravet om kun at forespørge aktive konti. I dette eksempel bruger jeg splatting for at gøre koden mere læsbar, fordi syntaksen er meget lang. Splatting AD cmdlets kan være vanskelig, så jeg har også vist den lange formversion af syntaksen under splatting-eksemplet.
$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
dette giver os vores inaktive brugere, der er aktiveret. Vi gemmer resultaterne til en variabel til genbrug. Egenskaben DistinguishedName er nødvendig senere. Når vi har fundet brugerne, kan vi arbejde på vores næste trin: deaktivering af konti. Vi bruger set-ADUser cmdlet til at foretage ændringer i ANNONCEBRUGERKONTOEN.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
vi har deaktiveret vores brugerkonti. Det er på tide at flytte dem til en ny OU. For vores eksempel bruger vi den OU, der hedder handicappede brugere. Det fremtrædende navn for denne OU er “OU=Disabled-Users,DC=Contoso,DC=Com” vi bruger Move-ADObject cmdlet til at flytte brugere til målet OU.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
i vores sidste trin brugte vi Move-ADObject til at flytte brugere til en ny OU. Vi har nu den kernekode, der er nødvendig for at gøre en pålidelig, gentagelig automatiseret opgave. Så hvad er det næste? Det afhænger af dine individuelle behov. Denne kode kan og bør indstilles til at køre automatisk på samme tid hver måned. En nem måde at gøre det på er at oprette et planlagt Job for at køre koden månedligt.
der er mere, vi kunne tilføje til denne kode for at gøre det bedre. Kode til fejlkontrol og yderligere brugerinformationsfelter ville være to nyttige tilføjelser. De fleste hold, der kører disse typer opgaver, genererer en rapport om, hvad der blev deaktiveret for nogen at gennemgå, så de ekstra felter vil var. Du kan medtage flere felter fra Active Directory for at gøre en rapport mere nyttig. Vi kunne tage denne opgave et skridt videre ved at oprette en anden opgave for at slette de handicappede brugere efter 6 måneder.
det er meget lettere at løse udfordrende automatiseringsanmodninger, når opgaverne er opdelt i håndterbare stykker. Vi startede med krav og opbyggede vores syntaks i små trin; bekræfter, at hvert trin fungerer, før vi prøver at tilføje en anden variabel. Ved at gøre dette gjorde vi denne opgave let at forstå og forhåbentlig en god læringsoplevelse.