najít neaktivní Uživatelské účty ve vaší doméně
Active Directory je adresářová služba, která uchovává informace o uživatelích, počítačích a souvisejících objektech. Zde je návod, jak najít neaktivní uživatelské účty.
Jedná se o databázi relačních informací, která potřebuje údržbu v průběhu času, aby byla užitečná a relevantní. Adresář bude mít účty, které se již nepoužívají. Nalezení těchto účtů ve službě Active Directory není tak snadné, jak to zní na první pohled. Pojďme se projít hledáním neaktivních uživatelských účtů a automatizací jejich odstranění.
Definujte kritéria vyhledávání
pojďme definovat, co je pro tento proces potřeba. Naším cílem je najít zaměstnanecké účty, které se delší dobu nepřihlásily do sítě. Vždy jsem používal 90 nebo 120 dní jako dobré měřítko pro dotaz na nečinnost, ale toto číslo může být tak nízké 14 dní. Musíte se rozhodnout, co je pro vaši organizaci správné. 90 dny dává dostatečně velký polštář, aby pro lidi z kanceláře na dovolenou, rodinné nouze, nebo rozšířené Lékařské listy. Jakmile účty dosáhnou 90 dnů nečinnosti, chceme tyto účty deaktivovat a přesunout je na samostatnou OU.
definování toho, co hledáme, nám nejprve umožňuje vytvořit jednoduchou sadu pravidel, kterou budeme dodržovat. Naše sada pravidel vypadá takto:
- Najděte a deaktivujte aktivní účty, které nemají žádnou přihlašovací aktivitu po dobu 90 dnů.
- přesuňte každý zakázaný účet do Zakázaného uživatele ou
- označte každého postiženého uživatele poznámkou, že automatizovaný proces jej deaktivoval.
najít vlastnosti nečinnosti účtu
každý uživatelský účet má několik atributů obsahujících přihlašovací údaje. Chceme najít atributy, které ukazují poslední čas přihlášení. Pokud tyto atributy najdeme, můžeme je použít k dotazu na účty, které nebyly přihlášeny od určitého data. Pomocí PowerShell můžeme zobrazit všechny sady pravidel a vybrat atribut, se kterým chcete pracovat.
Get-ADUser je nejpoužívanější rutina pro zobrazení informací o uživateli. Dalo by se použít Get-ADObject a Search-ADAccount, ale Get-ADUser je nejlepší rutina pro náš úkol. Chcete-li zobrazit všechny vlastnosti uživatele, musíme do syntaxe rutiny přidat-properties*. Pokud tuto syntaxi vynecháme, uvidíme pouze výchozí vlastnosti, což je pouze 10 vlastností.
Get-ADUser Michael_Kanakos -Properties *
vracíme dlouhý seznam polí z našeho dotazu (přes 150!). Můžeme hledat atributy, které obsahují konkrétní slova pomocí zástupných znaků. To nám pomáhá najít atributy, které mohou být užitečné pro náš úkol. Chceme najít přihlašovací informace, takže pojďme hledat atributy obsahující slovo Logon.
jakmile řekneme PowerShell, aby získal všechny vlastnosti,bylo by užitečné, kdybychom mohli omezit seznam vlastností tak, aby zobrazoval pouze vlastnosti, které odpovídají přihlášení slova. Select-Object poskytuje možnost Provést divokou kartu a omezit naše výsledky. Znak | (nazývaný „trubka“) vezme výsledky vlevo a předá je Select-Object. Select-Object poté provede párování divoké karty a poté omezí výsledky na základě našich kritérií divoké karty.
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
výsledky se budou trochu lišit podle toho, jaká je funkční úroveň domény služby Active Directory. Moje hledání vrací osm atributů. Tři vypadají slibně: LastLogon, LastLogonDate a LastLogonTimeStamp. Některé z hodnot mohou vypadat trochu divně, pokud nejste obeznámeni s tím, jak služba Active Directory ukládá informace o datu a čase v určitých atributech. Některé informace o datu jsou tradiční informace o datu a čase, a některé jsou uloženy jako “ klíšťata.“
hodnoty data a času PowerShell a. NET Framework představují data jako počet klíšťat od 12: 00 1.ledna 0001. Klíšťata se rovnají jedné desetimiliontině sekundy, což znamená, že je 10 000 klíšťat za milisekundu. Existují matematické rutiny, které mohou převést klíšťata do standardního formátu data.
PowerShell zobrazuje skutečné zaškrtnutí, které představuje datum/čas. Pokud vám vyhovuje převod klíšťat do formátu data, pak se můžete podívat na tato pole v uživatelském a počítačovém adresáři služby Active Directory nebo v administrativním centru služby Active Directory. V obou aplikacích, klíšťata jsou reprezentována jako formát časového data.
Aduser-Logon-Properties
atributy přihlášení vysvětleny
naše vyhledávání našlo více vlastností, které zobrazují informace o datu/čase přihlášení. Dvě vlastnosti mají stejné datum a čas a jedna ne. Co se to tu děje?
rozptyl informací o datu a čase je záměrný a je na místě, aby chránil DC před rozdrcením s replikačním provozem, který se snaží udržet všechny přihlašovací informace v synchronizaci. Vlastnost LastLogon se aktualizuje při každém ověření, ale data jsou uložena na DC, proti kterému jste ověřili, a nejsou replikována na ostatní DC. vlastnosti LastLogonTimeStamp a LastLogonDate jsou replikovány na všechny DC, ale replikace se děje jen zřídka.
pokud se podíváme na data, můžeme vidět, jak by zpožděná replikace mohla ovlivnit náš dotaz. Všimněte si, že LastLogonTimeStamp je v tomto příkladu ve skutečnosti o dva dny pozadu. Pokaždé, když se uživatel interaktivně přihlásí, dotkne se sdílení síťových souborů nebo provede jiné činnosti, které vyžadují, aby síť ověřila účet, ukládá přihlašovací informace do služby Active Directory. Pokud dc opakuje tato data pokaždé, když se někdo dotkne něčeho v síti, DC by mohlo být ohromeno ve velkém prostředí. Výsledkem je, že některé přihlašovací informace jsou přesné, ale nejsou replikovány, a některé přihlašovací informace se opakují, ale pouze příležitostně.
pro naše požadavky nepotřebujeme přesné časové razítko přihlášení. Potřebujeme najít pouze účty, které se nepřihlásily po dlouhou dobu (více než 90 dní). Jakákoli hodnota může být užitečná, i když je datum vypnuto o několik dní. Použijeme-li jako příklad Moje přihlašovací data, dotazovaný čas může být 11/11 nebo 11/13, v závislosti na hodnotě, kterou používáme. Rychlý posun vpřed o tři měsíce a předpokládám, že jsem se už nikdy nepřihlásil. Jedno datum by označilo jako neaktivní za to, že skončilo 90 dnů, a jedno pole ne. Ale pokud nastavím tento proces tak, aby běžel měsíčně, chytil bych účet při příští kontrole. To je rozhodující část. Pokud to děláme pravidelně, můžeme použít jedno pole, pokud důsledně kontrolujeme.
použil jsem vlastnost LastLogonDate ze dvou důvodů. Za prvé, je to již hodnota data, takže se nemusím zabývat konverzí hodnoty. Za druhé, je to replikovaná hodnota, a to mi usnadňuje život. Kdybych použil LastLogon, měl bych data, která nejsou aktuální pro lidi, kteří ověřují proti jiným řadičům domény v mé síti. Musel bych požádat místní DC, aby každý uživatel získal nejnovější časové razítko, a to je spousta práce a není příliš efektivní.
Chcete-li získat informace o jednom účtu, kód je jednoduchý.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
Chcete – li to pro všechny mé uživatele vyžaduje jen trochu více kódu. K dotazování na všechny uživatelské účty musíme použít filtr.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
nyní najdeme pouze účty s datem přihlášení starším než 90 dní. Potřebujeme aktuální datum uložené pro použití jako srovnávací operátor.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
tento kód načte všechny uživatele, kteří se nepřihlásili více než 90 dní. Uložíme Datum 90 Před dny na proměnnou. Můžeme vytvořit filtr reklam, abychom našli logony menší než toto datum. Dále musíme přidat požadavek na dotaz pouze aktivních účtů. V tomto příkladu používám splatting, aby byl kód čitelnější, protože syntaxe je velmi dlouhá. Splatting ad cmdlets může být složité, takže jsem také ukázal dlouhou verzi syntaxe pod příkladem 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
to nám dává naše neaktivní uživatele, kteří jsou povoleni. Výsledky ukládáme do proměnné pro opětovné použití. Vlastnost DistinguishedName je zapotřebí později. Jakmile najdeme uživatele, můžeme pracovat na našem dalším kroku: zakázání účtů. Rutinu Set-ADUser používáme k provádění změn uživatelského účtu reklamy.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
zakázali jsme naše uživatelské účty. Je čas přesunout je do nového OU. Pro náš příklad použijeme OU s názvem Disabled-Users. Rozlišující název pro toto OU je „OU=Disabled-Users, DC=Contoso, DC=Com“ používáme rutinu Move-ADObject pro přesun uživatelů na cílové OU.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
v našem posledním kroku jsme použili Move-ADObject k přesunu uživatelů do nového OU. Nyní máme základní kód potřebný k vytvoření spolehlivého, opakovatelného automatizovaného úkolu. Tak co bude dál? To záleží na vašich individuálních požadavcích. Tento kód může a měl by být nastaven tak, aby běžel automaticky ve stejnou dobu každý měsíc. Jeden snadný způsob, jak toho dosáhnout, je vytvořit naplánovanou úlohu pro spuštění kódu na měsíční bázi.
k tomuto kódu bychom mohli přidat více, aby byl lepší. Kód pro kontrolu chyb a další uživatelská informační pole by byly dva užitečné doplňky. Většina týmů, které provozují tyto typy úkolů, vygeneruje zprávu o tom, co bylo zakázáno, aby někdo mohl zkontrolovat, takže další pole budou var. Můžete zahrnout více polí ze služby Active Directory, aby byla zpráva užitečnější. Tento úkol bychom mohli posunout o krok dále vytvořením dalšího úkolu k odstranění těchto postižených uživatelů po 6 měsících.
řešení náročných požadavků na automatizaci je mnohem snazší, když jsou úkoly rozděleny do zvládnutelných částí. Začali jsme s požadavky a vytvořili naši syntaxi v malých krocích; potvrzení, že každý krok funguje, než se pokusíte přidat jinou proměnnou. Tímto způsobem jsme tento úkol snadno pochopili a doufejme, že je to skvělý zážitek z učení.