Finn Inaktive Brukerkontoer I Domenet
Active Directory Er en katalogtjeneste som vedlikeholder informasjon om brukere, datamaskiner og relaterte objekter. Her er hvordan du kan finne inaktive brukerkontoer.
det er en database med relasjonell informasjon som trenger vedlikehold over tid for å være nyttig og relevant. En katalog vil ha kontoer som ikke lenger brukes. Å finne disse kontoene I Active Directory er ikke så enkelt som det høres ut ved første øyekast. La oss gå gjennom å finne inaktive brukerkontoer og automatisere å fjerne dem.
Definer Søkekriterier
la oss definere hva som trengs for denne prosessen. Vårt mål er å finne ansattes kontoer som ikke har logget inn i nettverket i en lengre periode. Jeg har alltid brukt 90 eller 120 dager som et godt mål for å spørre inaktivitet etter, men det tallet kan være så lavt 14 dager. Du må bestemme hva som er riktig for din organisasjon. 90 dager gir en stor nok pute for å tillate folk ut av kontoret for ferie, familie nødhjelp, eller utvidet medisinske blader. Når kontoene når 90 dager med inaktivitet, vil vi deaktivere disse kontoene og flytte dem til en egen OU.
Definere hva vi leter etter først tillater oss å bygge en enkel regelsett å følge. Vår regelsett ser slik ut:
- Finn og deaktiver aktive kontoer som ikke har påloggingsaktivitet i 90 dager.
- Flytt hver deaktivert konto TIL Deaktiverte Brukere OU
- Merk hver deaktivert bruker med en kommentar om at en automatisert prosess deaktiverte den.
Finn Egenskaper For Inaktivitet For Konto
hver brukerkonto har flere attributter som inneholder påloggingsinformasjon. Vi ønsker å finne attributter som viser siste påloggingstid. Hvis vi kan finne disse attributtene, kan vi bruke dem til å spørre etter kontoer som ikke er logget inn siden en bestemt dato. Vi kan bruke PowerShell til å vise alle reglene og velge et attributt å jobbe med.
Get-ADUser Er den mest brukte cmdleten for å vise brukerinformasjon. Du kan bruke Get-ADObject Og Search-ADAccount, Men Get-ADUser er den beste cmdleten for vår oppgave. For å vise alle brukeregenskapene må vi legge til-egenskaper * i cmdlets syntaks. Hvis vi forlater den syntaksen, ser vi bare standardegenskapene, som bare er 10 egenskaper.
Get-ADUser Michael_Kanakos -Properties *
vi returnerer en lang liste med felt fra vår spørring (over 150!). Vi kan søke etter attributter inneholder bestemte ord ved hjelp av jokertegn. Dette hjelper oss med å finne attributter som kan være nyttige for vår oppgave. Vi ønsker å finne påloggingsinformasjon, så la oss søke etter attributter som inneholder ordet Pålogging.
Når Vi forteller PowerShell å få alle egenskaper, ville det være nyttig hvis vi kunne begrense listen over egenskaper for å bare vise egenskaper som samsvarer med word-Pålogging. Velg-Objekt gir muligheten til å gjøre en wild-card kamp og begrense våre resultater. Tegnet / (kalt «the pipe») tar resultatene til venstre og sender dem Til Select-Object. Velg-Objekt deretter utfører wild-card matching og deretter begrenser resultatene basert på våre 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
resultatene vil variere litt basert på hva domenefunksjonsnivået For Active Directory er. Søket mitt returnerer åtte attributter. Tre ser lovende Ut: LastLogon, LastLogonDate og LastLogonTimeStamp. Noen av verdiene kan se litt rart ut hvis Du ikke er kjent med Hvordan Active Directory lagrer dato / klokkeslett i visse attributter. Noen dato info er tradisjonell dato-tid info, og noen er lagret som » flått.»
PowerShell og. NET Framework dato-tid verdier representerer datoer som antall flått siden 12: 00 AM januar 1, 0001. Ticks er lik en ti milliondel av et sekund, noe som betyr at det er 10.000 flått per millisekund. Det er matte cmdlets som kan konvertere flått til et standard datoformat.
PowerShell viser den faktiske avmerkingen som representerer dato / klokkeslett. Hvis du er komfortabel med å konvertere flått til datoformat, kan du se på disse feltene I Active Directory-Bruker Og Datamaskiner eller Active Directory Administrative Center. I begge appene er flåttene representert som et tids-datoformat.
ADUser-Logon-Properties
Påloggingsattributter Forklart
vårt søk fant flere egenskaper som viser dato/klokkeslett påloggingsinformasjon. To eiendommer har samme dato og klokkeslett, og en har ikke. Hva skjer her?
variansen i dato-tid info er av design og er på plass for å beskytte DC – er fra å bli knust med replikering trafikk prøver å holde all påloggingsinformasjon synkronisert. LastLogon-egenskapen oppdateres hver gang du autentiserer, men dataene lagres PÅ DC du autentiserte mot og ikke replikert til de andre DC-ene. lastlogontimestamp og LastLogonDate-egenskapene blir replikert til alle DC-er, men replikeringen skjer bare sjelden.
hvis vi ser på datoene, kan vi se hvordan forsinket replikering kan påvirke spørringen vår. Legg merke Til At LastLogonTimeStamp er faktisk to dager bak i dette eksemplet. Hver gang en bruker interaktivt logger på, berører en nettverksfildeling eller utfører andre aktiviteter som krever at nettverket godkjenner kontoen, lagrer den påloggingsinformasjon i Active Directory. Hvis dc replikerte dataene HVER gang noen rørte noe på nettverket, KUNNE DC-ene bli overveldet i et stort miljø. Resultatet er at noen påloggingsinformasjon er nøyaktig, men ikke replikert, og noen påloggingsinformasjon replikerer, men bare av og til.
for våre krav trenger vi IKKE DET NØYAKTIGE påloggingstidsstempelet. Vi trenger bare å finne kontoer som ikke har logget på i lang tid (større enn 90 dager). Enhver verdi kan være nyttig, selv om datoen er av med noen dager. Hvis vi bruker påloggingsdatoene mine som et eksempel, kan tiden som spørres være 11/11 eller 11/13, avhengig av verdien vi bruker. Spol frem tre måneder og antar at jeg aldri logget på igjen. En dato ville flagge som inaktiv for å være over 90 dager, og ett felt ville ikke. Men hvis jeg satte opp denne prosessen for å kjøre månedlig, ville jeg ta kontoen neste gang vi sjekker. Det er den kritiske delen. Hvis vi gjor dette regelmessig, kan vi bruke begge felt sa lenge vi konsekvent sjekker.
jeg brukte LastLogonDate-egenskapen av to grunner. Først er det allerede en datoverdi, så jeg trenger ikke å håndtere å konvertere verdien. For det andre er det en replikert verdi, og det gjør livet mitt enklere. Hvis Jeg brukte LastLogon, ville jeg ha datoer som ikke er oppdatert for folk som autentiserer mot andre domenekontrollere i nettverket mitt. Jeg må spørre den lokale DC for hver bruker for å få det nyeste tidsstempelet, og det er mye arbeid å gjøre og ikke veldig effektivt.
for å få informasjon om en enkelt konto, er koden enkel.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
for å gjøre dette for alle mine brukere krever bare litt mer kode. Vi må bruke et filter for å spørre alle brukerkontoer.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
la Oss nå bare finne kontoene med en påloggingsdato eldre enn 90 dager. Vi trenger gjeldende dato lagret for å bruke som sammenligningsoperatør.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
denne koden henter alle brukere som ikke har logget inn over 90 dager. Vi lagrer datoen 90 dager siden til en variabel. VI kan opprette ET ANNONSEFILTER for å finne pålogginger mindre enn denne datoen. Deretter må vi legge til kravet om å spørre bare aktive kontoer. I dette eksemplet bruker jeg splatting for å gjøre koden mer lesbar fordi syntaksen er veldig lang. Splatting AD cmdlets kan være vanskelig, så jeg har også vist den lange versjonen av 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 gir oss våre inaktive brukere som er aktivert. Vi lagrer resultatene til en variabel for gjenbruk. Egenskapen DistinguishedName er nødvendig senere. Når vi finner brukerne, kan vi jobbe med vårt neste trinn: deaktivere kontoene. Vi bruker Cmdleten Set-ADUser for Å gjøre ENDRINGER I AD-brukerkontoen.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
vi har deaktivert brukerkontoene våre. Det er på tide å flytte dem til en ny OU. For vårt eksempel bruker VI Ou-navngitte Deaktiverte Brukere. Det Unike Navnet for DENNE OU er «OU=Disabled-Users, DC=Contoso, DC=Com» Vi bruker Cmdleten Move-ADObject til å flytte brukere til MÅLET OU.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
i vårt siste trinn brukte Vi Move-ADObject til å flytte brukere til en ny OU. Vi har nå kjernekoden som trengs for å lage en pålitelig, repeterbar automatisert oppgave. Så hva blir det neste? Det avhenger av dine individuelle krav. Denne koden kan og bør settes opp til å kjøre automatisk på samme tid hver måned. En enkel måte å gjøre det på er å lage En Planlagt Jobb for å kjøre koden månedlig.
Det er mer vi kan legge til denne koden for å gjøre det bedre. Kode for feilkontroll og ytterligere brukerinformasjonsfelt vil være to nyttige tillegg. De fleste team som kjører denne typen aktiviteter, genererer en rapport om hva som ble deaktivert for noen å se gjennom, så de ekstra feltene vil være. Du kan inkludere flere felt Fra Active Directory for å gjøre en rapport mer nyttig. Vi kan ta denne oppgaven ett skritt videre ved å opprette en annen oppgave for å slette de deaktiverte brukerne etter 6 måneder.
Det Er mye enklere Å Løse utfordrende automatiseringsforespørsler når oppgavene er delt inn i håndterbare deler. Vi startet med krav og bygget opp vår syntaks i små trinn; bekrefter at hvert trinn fungerer før du prøver å legge til i en annen variabel. Ved å gjøre dette, vi gjorde denne oppgaven lett å forstå og forhåpentligvis en stor erfaring.