hitta inaktiva användarkonton i din domän
Active Directory är en katalogtjänst som upprätthåller information om användare, datorer och relaterade objekt. Så här hittar du inaktiva användarkonton.
det är en databas med relationell information som behöver underhåll över tid för att vara användbar och relevant. En katalog kommer att ha konton som inte längre används. Att hitta dessa konton i Active Directory är inte så lätt som det låter vid första anblicken. Låt oss gå igenom att hitta inaktiva användarkonton och automatisera att ta bort dem.
definiera sökkriterier
Låt oss definiera vad som behövs för denna process. Vårt mål är att hitta medarbetarkonton som inte har loggat in i nätverket under en längre period. Jag har alltid använt 90 eller 120 dagar som ett bra mått för att fråga inaktivitet av, men det numret kan vara så lågt 14 dagar. Du måste bestämma vad som är rätt för din organisation. 90 dagar ger en tillräckligt stor kudde för att tillåta personer utanför kontoret för semester, familjesituationer eller utökade medicinska löv. När kontona når 90 dagars inaktivitet vill vi inaktivera dessa konton och flytta dem till en separat OU.
genom att definiera vad vi letar efter först kan vi bygga en enkel regeluppsättning att följa. Vår regeluppsättning ser ut så här:
- hitta och inaktivera aktiva konton som inte har någon inloggningsaktivitet på 90 dagar.
- flytta varje inaktiverat konto till Disabled-Users ou
- markera varje inaktiverad användare med en kommentar om att en automatiserad process inaktiverade den.
hitta Inaktivitetsegenskaper för konto
varje användarkonto har flera attribut som innehåller inloggningsinformation. Vi vill hitta attribut som visar Senaste inloggningstiden. Om vi kan hitta dessa attribut kan vi använda dem för att söka efter konton som inte är inloggade sedan ett visst datum. Vi kan använda PowerShell för att visa alla regeluppsättningar och välja ett attribut att arbeta med.
Get-ADUser är den mest använda cmdlet för att visa användarinformation. Du kan använda Get-ADObject och Search-ADAccount, men Get-ADUser är den bästa cmdlet för vår uppgift. För att visa alla användaregenskaper måste vi lägga till-Egenskaper * i cmdlet-syntaxen. Om vi lämnar den syntaxen ute ser vi bara standardegenskaperna, som bara är 10 egenskaper.
Get-ADUser Michael_Kanakos -Properties *
vi returnerar en lång lista med fält från vår fråga (över 150!). Vi kan söka efter attribut som innehåller särskilda ord med hjälp av jokertecken. Detta hjälper oss att hitta attribut som kan vara användbara för vår uppgift. Vi vill hitta inloggningsinformation, så låt oss söka efter attribut som innehåller ordet inloggning.
när vi berättar PowerShell att få alla egenskaper, skulle det vara till hjälp om vi kunde begränsa listan över egenskaper för att bara visa egenskaper som matchar ordet inloggning. Select-Object ger möjlighet att göra en wild-card match och begränsa våra resultat. Tecknet / (kallat ”röret”) tar resultaten till vänster och skickar dem till Select-Object. Select-Object utför sedan wild-card-matchningen och begränsar sedan resultaten baserat på våra wild-card-kriterier.
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
resultaten kommer att variera lite beroende på vilken domänfunktionsnivå i Active Directory är. Min sökning returnerar Åtta Attribut. Tre ser lovande ut: LastLogon, LastLogonDate och LastLogonTimeStamp. Några av värdena kan se lite konstiga ut om du inte känner till hur Active Directory lagrar datum/tidinformation i vissa attribut. Vissa datum info är traditionell datum-tid info, och vissa sparas som ”fästingar.”
PowerShell och. NET Framework datum-tid värden representerar datum som antalet fästingar sedan 12:00 1 januari 0001. Fästingar är lika med en tio miljoner sekund, vilket innebär att det finns 10 000 fästingar per millisekund. Det finns matematiska cmdlets som kan konvertera fästingar till ett standarddatumformat.
PowerShell visar den faktiska bocken som representerar datum / tid. Om du är bekväm att konvertera fästingar till datumformat kan du titta på dessa fält i Active Directory-användare och datorer eller Active Directory Administrationscenter. I båda apparna representeras fästingarna som ett tidsdatumformat.
Aduser-Logon-Properties
Inloggningsattribut förklarade
vår sökning hittade flera egenskaper som visar datum/tid inloggningsinformation. Två fastigheter har samma datum och tid och en gör det inte. Vad händer här?
variansen i datum-tid info är av design och är på plats för att skydda DC från att bli krossad med replikering trafik försöker hålla alla inloggningsinformation i synk. Egenskapen LastLogon uppdateras varje gång du autentiserar, men data lagras på den DC du autentiserade mot och inte replikeras till de andra DC: erna. egenskaperna LastLogonTimeStamp och LastLogonDate replikeras till alla DC: er men replikationen sker bara sällan.
om vi tittar på datumen kan vi se hur den försenade replikationen kan påverka vår fråga. Lägg märke till att LastLogonTimeStamp är faktiskt två dagar efter i detta exempel. Varje gång en användare interaktivt loggar in, berör en nätverksresurs eller utför andra aktiviteter som kräver att nätverket autentiserar kontot, lagras inloggningsinformation i Active Directory. Om dc: s replikerade den data varje gång någon rörde något på nätverket, kunde DC: erna bli överväldigade i en stor miljö. Resultatet är att viss inloggningsinformation är korrekt men inte replikerad, och viss inloggningsinformation replikeras, men bara ibland.
för våra krav behöver vi inte den exakta inloggningstidsstämpeln. Vi behöver bara hitta konton som inte har loggat in på länge (mer än 90 dagar). Vilket värde som helst kan vara användbart, även om datumet är avstängt med några dagar. Om vi använder mina inloggningsdatum som ett exempel kan tiden som frågas vara 11/11 eller 11/13, beroende på vilket värde vi använder. Spola framåt tre månader och antar att jag aldrig loggat in igen. Ett datum skulle flagga som inaktivt för att vara över 90 dagar, och ett fält skulle inte. Men om jag ställer in denna process för att köra varje månad, skulle jag fånga kontot nästa gång vi kontrollerar. Det är den kritiska delen. Om vi gör det regelbundet kan vi använda båda fälten så länge vi konsekvent kontrollerar.
jag använde egenskapen LastLogonDate av två skäl. För det första är det redan ett datumvärde, så jag behöver inte ta itu med att konvertera värdet. För det andra är det ett replikerat värde, och det gör mitt liv enklare. Om jag använde LastLogon skulle jag ha datum som inte är uppdaterade för personer som autentiserar mot andra domänkontrollanter i mitt nätverk. Jag skulle behöva fråga den lokala DC för varje användare för att få den senaste tidsstämpeln, och det är mycket arbete att göra och inte särskilt effektivt.
för att få informationen på ett enda konto är koden enkel.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
för att göra detta för alla mina användare kräver bara lite mer kod. Vi måste använda ett filter för att fråga alla användarkonton.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
låt oss nu bara hitta kontona med ett inloggningsdatum som är äldre än 90 dagar. Vi behöver det aktuella datumet som sparats för att användas som jämförelseoperatör.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
den här koden hämtar alla användare som inte har loggat in under 90 dagar. Vi sparar datumet för 90 dagar sedan till en variabel. Vi kan skapa ett ANNONSFILTER för att hitta inloggningar mindre än det datumet. Därefter måste vi lägga till kravet att bara fråga aktiva konton. I det här exemplet använder jag splatting för att göra koden mer läsbar eftersom syntaxen är väldigt lång. Splatting AD cmdlets kan vara knepigt, så jag har också visat den långformade versionen av syntaxen under splatting-exemplet.
$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
detta ger oss våra inaktiva användare som är aktiverade. Vi sparar resultaten till en variabel för återanvändning. Egenskapen DistinguishedName behövs senare. När vi väl har hittat användarna kan vi arbeta med vårt nästa steg: inaktivera kontona. Vi använder cmdlet Set-ADUser för att göra ändringar i användarkontot för annonser.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
vi har inaktiverat våra användarkonton. Det är dags att flytta dem till en ny OU. I vårt exempel använder vi OU som heter Disabled-Users. Det utmärkta namnet för denna OU är” OU=Disabled-Users,DC=Contoso,DC=Com ” vi använder Move-ADObject cmdlet för att flytta användare till målet OU.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
i vårt sista steg använde vi Move-ADObject för att flytta användare till en ny OU. Vi har nu kärnkoden som behövs för att göra en pålitlig, repeterbar automatiserad uppgift. Så vad är nästa? Det beror på dina individuella krav. Denna kod kan och bör ställas in för att köras automatiskt vid samma tidpunkt varje månad. Ett enkelt sätt att göra det är att skapa ett schemalagt jobb för att köra koden varje månad.
det finns mer vi kan lägga till denna kod för att göra det bättre. Kod för felkontroll och ytterligare användarinformationsfält skulle vara två användbara tillägg. De flesta lag som kör dessa typer av uppgifter genererar en rapport om vad som var inaktiverat för någon att granska, så de ytterligare fälten kommer att var. Du kan inkludera fler fält från Active Directory För att göra en rapport mer användbar. Vi kan ta denna uppgift ett steg längre genom att skapa en annan uppgift att ta bort de funktionshindrade användare efter 6 månader.
att lösa utmanande automatiseringsförfrågningar är mycket lättare när uppgifterna är indelade i hanterbara bitar. Vi började med krav och byggde upp vår syntax i små steg; bekräftar att varje steg fungerar innan vi försöker lägga till en annan variabel. Genom att göra detta gjorde vi denna uppgift lätt att förstå och förhoppningsvis en bra inlärningsupplevelse.