zoek inactieve Gebruikersaccounts in uw domein
Active Directory is een directoryservice die informatie bijhoudt over gebruikers, computers en gerelateerde objecten. Hier is hoe u inactieve gebruikersaccounts kunt vinden.
het is een database met relationele informatie die in de loop van de tijd moet worden onderhouden om nuttig en relevant te zijn. In een directory worden geen accounts meer gebruikt. Het vinden van die accounts in Active Directory is niet zo eenvoudig als het klinkt op het eerste gezicht. Laten we lopen door het vinden van inactieve gebruikersaccounts en het automatiseren van het verwijderen van hen.
definieer zoekcriteria
laten we definiëren wat er nodig is voor dit proces. Ons doel is om werknemersaccounts te vinden die gedurende een langere periode niet op het netwerk zijn ingelogd. Ik heb altijd gebruikt 90 of 120 dagen als een goede maatregel om te vragen inactiviteit door, maar dat aantal kan zo laag 14 dagen. U moet beslissen wat goed is voor uw organisatie. 90 dagen geeft een groot genoeg kussen voor mensen uit het kantoor voor vakantie, familie noodsituaties, of langere medische verlof. Zodra de accounts 90 dagen inactiviteit hebben bereikt, willen we deze accounts uitschakelen en verplaatsen naar een aparte organisatie-eenheid.
door te definiëren waar we eerst naar op zoek zijn, kunnen we een eenvoudige set regels maken die we moeten volgen. Onze regelset ziet er zo uit:
- Zoek en schakel actieve accounts uit die gedurende 90 dagen geen aanmeldingsactiviteit hebben.
- Verplaats elk uitgeschakeld account naar de gehandicapte-gebruikers OU
- markeer elke gehandicapte gebruiker met een opmerking dat een geautomatiseerd proces het uitgeschakeld heeft.
Find account Inactivity Properties
elk gebruikersaccount heeft verschillende attributen die login-informatie bevatten. We willen attributen vinden die de laatste aanmeldtijd tonen. Als we die kenmerken kunnen vinden, kunnen we ze gebruiken om accounts te zoeken die sinds een bepaalde datum niet zijn aangemeld. We kunnen PowerShell gebruiken om alle regelset weer te geven en een attribuut kiezen om mee te werken.
Get-ADUser is de meest gebruikte cmdlet voor het tonen van gebruikersinformatie. U kunt gebruik maken van Get-ADObject en Search-Adacount, maar Get-ADUser is de beste cmdlet voor onze taak. Om alle gebruikerseigenschappen weer te geven, moeten we-properties * toevoegen aan de cmdlet-syntaxis. Als we die syntaxis weglaten, zullen we alleen de standaard eigenschappen zien, wat slechts 10 eigenschappen is.
Get-ADUser Michael_Kanakos -Properties *
we retourneren een lange lijst met velden uit onze zoekopdracht (meer dan 150!). We kunnen zoeken naar attributen die bepaalde woorden bevatten met behulp van jokertekens. Dit helpt ons attributen te vinden die nuttig kunnen zijn voor onze taak. We willen aanmeldingsinformatie vinden, dus laten we zoeken naar attributen die het woord aanmelden bevatten.
zodra we PowerShell vertellen om alle eigenschappen te krijgen, zou het handig zijn als we de lijst met eigenschappen konden beperken tot alleen eigenschappen die overeenkomen met de word-aanmelding. Select-Object biedt de mogelijkheid om een wild-card match te doen en onze resultaten te beperken. Het / karakter (genaamd” The pipe”) neemt de resultaten aan de linkerkant en geeft ze door aan Select-Object. Select-Object voert vervolgens de wild-card matching uit en beperkt vervolgens de resultaten op basis van onze wild-card criteria.
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
de resultaten zullen enigszins variëren op basis van het domeinfunctionaliteitsniveau van de Active Directory. Mijn zoekopdracht geeft acht attributen. Drie zien er veelbelovend uit: LastLogon, LastLogonDate en LastLogonTimeStamp. Sommige waarden kunnen er een beetje raar uitzien als u niet bekend bent met hoe Active Directory datum/tijd-informatie in bepaalde attributen opslaat. Sommige Datum info is traditionele datum-tijd info, en sommige worden opgeslagen als “teken.”
PowerShell en. NET Framework datum-tijd waarden vertegenwoordigen datums als het aantal teken sinds 00: 00 am 1 januari 0001. Teken zijn gelijk aan een tien miljoenste van een seconde, wat betekent dat er 10.000 teken per milliseconde. Er zijn math cmdlets die teken kunnen converteren naar een standaard datumformaat.
PowerShell toont de werkelijke Vink die de datum/tijd vertegenwoordigt. Als u het gemakkelijk vindt om teken naar datumnotatie te converteren, kunt u deze velden bekijken in Active Directory-gebruiker en-Computers of Active Directory-Beheerderscentrum. In beide apps, de teken worden weergegeven als een tijd-datum formaat.
ADUser-Logon-Propertes
Logon attributen Explained
onze zoekopdracht heeft meerdere eigenschappen gevonden die datum/tijd aanmeldingsinformatie tonen. Twee woningen hebben dezelfde datum en tijd en één niet. Wat is hier aan de hand?
de variantie in datum-tijd informatie is door het ontwerp en is op zijn plaats om DC ‘ s te beschermen tegen verpletterd met replicatieverkeer proberen om alle logon info in sync te houden. De eigenschap lastlogon wordt elke keer bijgewerkt als u authenticeert, maar de gegevens worden opgeslagen op de DC waartegen u authenticeerde en niet gerepliceerd naar de andere DC ‘s. de eigenschappen LastLogonTimeStamp en LastLogonDate worden gerepliceerd naar alle DC’ s, maar de replicatie gebeurt slechts zelden.
als we naar de datums kijken, kunnen we zien hoe de vertraagde replicatie onze query kan beïnvloeden. Merk op dat LastLogonTimeStamp eigenlijk twee dagen achter ligt in dit voorbeeld. Telkens wanneer een gebruiker zich interactief aanmeldt, een netwerkbestandshare aanraakt of andere activiteiten uitvoert waarvoor het netwerk het account moet verifiëren, wordt aanmeldingsinformatie opgeslagen in Active Directory. Als de dc die data repliceerde elke keer als iemand iets op het netwerk aanraakte, kunnen de DC ‘ s overweldigd worden in een grote omgeving. Het resultaat is dat sommige aanmeldingsgegevens juist zijn, maar niet worden gerepliceerd, en dat sommige aanmeldingsgegevens slechts af en toe worden gerepliceerd.
voor onze vereisten hebben we niet de exacte aanmeldingstijdstempel nodig. We hoeven alleen accounts te vinden die al lang niet zijn aangemeld (langer dan 90 dagen). Elke waarde kan nuttig zijn, zelfs als de datum is uitgeschakeld door een paar dagen. Als we mijn aanmeldingsdatums als voorbeeld gebruiken, kan de tijd die wordt opgevraagd 11/11 of 11/13 zijn, afhankelijk van de waarde die we gebruiken. Spoel drie maanden door en neem aan dat ik nooit meer ingelogd ben. Een datum zou vlag als inactief voor het zijn van meer dan 90 dagen, en een veld zou niet. Maar als ik het opzetten van dit proces om maandelijks te draaien, zou ik de rekening te vangen de volgende keer dat we controleren. Dat is het cruciale deel. Als we dit Regelmatig doen, kunnen we beide velden gebruiken zolang we consequent controleren.
Ik heb de eigenschap LastLogonDate om twee redenen gebruikt. Ten eerste, het is al een datum waarde, dus ik heb niet te maken met het omzetten van de waarde. Ten tweede, het is een gerepliceerde waarde, en dat maakt mijn leven makkelijker. Als ik LastLogon zou gebruiken, zou ik datums hebben die niet up-to-date zijn voor mensen die zich authenticeren tegen andere domeincontrollers in mijn netwerk. Ik zou moeten vragen de lokale DC voor elke gebruiker om de laatste tijdstempel te krijgen, en dat is een hoop werk te doen en niet erg efficiënt.
om de informatie op één account te krijgen, is de code eenvoudig.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
om dit voor al mijn gebruikers te doen heeft u slechts een beetje meer code nodig. We moeten een filter gebruiken om alle gebruikersaccounts te bevragen.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
laten we nu alleen de accounts vinden met een aanmeldingsdatum ouder dan 90 dagen. We hebben de huidige opgeslagen Datum nodig om als vergelijkingsoperator te gebruiken.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
deze code haalt alle gebruikers op die langer dan 90 dagen niet zijn ingelogd. We slaan de datum 90 dagen geleden op in een variabele. We kunnen een ADVERTENTIEFILTER maken om aanmeldingen van minder dan die datum te vinden. Volgende, We moeten toevoegen aan de eis om alleen actieve accounts query. In dit voorbeeld gebruik ik splatting om de code leesbaarder te maken omdat de syntaxis erg lang is. Splatting AD cmdlets kan lastig zijn, dus ik heb ook de lange-vorm versie van de syntaxis Onder het splatting voorbeeld.
$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
dit geeft ons onze Inactieve gebruikers die zijn ingeschakeld. We slaan de resultaten op in een variabele voor hergebruik. De DistinguishedName eigenschap is later nodig. Zodra we de gebruikers vinden, kunnen we werken aan onze volgende stap: het uitschakelen van de accounts. We gebruiken de set-ADUser cmdlet om AD gebruikersaccount wijzigingen aan te brengen.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
we hebben onze gebruikersaccounts uitgeschakeld. Het is tijd om ze naar een nieuwe OU te verhuizen. In ons voorbeeld gebruiken we de OU genaamd Disabled-Users. De DN-naam voor deze OU is “ou=Disabled-Users,DC=Contoso,DC=Com” we gebruiken de Move-ADObject cmdlet om gebruikers naar de doel OU te verplaatsen.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
in onze laatste stap gebruikten we het Move-ADObject om gebruikers naar een nieuwe organisatie-eenheid te verplaatsen. We hebben nu de kerncode die nodig is om een betrouwbare, herhaalbare geautomatiseerde taak te maken. Dus wat nu? Dat hangt af van uw individuele wensen. Deze code kan en moet worden ingesteld om automatisch te draaien op hetzelfde tijdstip elke maand. Een gemakkelijke manier om dat te doen is het creëren van een geplande taak om de code uit te voeren op een maandelijkse basis.
er is meer dat we aan deze code kunnen toevoegen om het beter te maken. Code voor foutcontrole en extra gebruikersinformatie velden zou twee nuttige toevoegingen. De meeste teams die dit soort taken uitvoeren, genereren een rapport van Wat is uitgeschakeld voor iemand om te beoordelen, dus de extra velden zullen var. U kunt meer velden uit Active Directory toevoegen om een rapport nuttiger te maken. We konden deze taak een stap verder door het creëren van een andere taak om die gehandicapte gebruikers te verwijderen na 6 maanden.
het oplossen van uitdagende automatiseringsaanvragen is veel gemakkelijker wanneer de taken worden verdeeld in beheersbare stukken. We begonnen met vereisten en bouwden onze syntaxis op in kleine stappen; we bevestigden dat elke stap werkt voordat we een andere variabele proberen toe te voegen. Door dit te doen, maakten we deze taak gemakkelijk te begrijpen en hopelijk een geweldige leerervaring.