Znajdź nieaktywne konta użytkowników w Twojej domenie
Active Directory to usługa katalogowa, która przechowuje informacje o użytkownikach, komputerach i powiązanych obiektach. Oto jak możesz znaleźć nieaktywne konta użytkowników.
jest to baza danych informacji relacyjnych, które wymagają konserwacji w czasie, aby były użyteczne i istotne. Katalog nie będzie już używany. Znalezienie tych kont w usłudze Active Directory nie jest takie proste, jak się wydaje na pierwszy rzut oka. Przejdźmy przez znajdowanie nieaktywnych kont użytkowników i automatyzację ich usuwania.
Zdefiniuj kryteria wyszukiwania
zdefiniujmy, co jest potrzebne do tego procesu. Naszym celem jest zlokalizowanie kont pracowników, którzy przez dłuższy czas nie logowali się do sieci. Zawsze używałem 90 lub 120 dni jako dobrego środka do zapytania o nieaktywność, ale ta liczba może wynosić tak niskie 14 dni. Musisz zdecydować, co jest właściwe dla Twojej organizacji. 90 dni daje wystarczająco dużą poduszkę, aby umożliwić ludziom wyjście z Biura na wakacje, nagłe sytuacje rodzinne lub przedłużone urlopy Medyczne. Gdy konta osiągną 90 dni nieaktywności, chcemy wyłączyć te konta i przenieść je do oddzielnej jednostki organizacyjnej.
zdefiniowanie tego, czego szukamy, pozwala nam zbudować prosty zestaw reguł do naśladowania. Nasz zestaw zasad wygląda następująco:
- znajdź i wyłącz aktywne konta, które nie mają aktywności logowania przez 90 dni.
- Przenieś każde wyłączone konto do wyłączonych użytkowników OU
- zaznacz każdego wyłączonego użytkownika komentarzem, że zautomatyzowany proces go wyłączył.
Znajdź właściwości braku aktywności konta
każde konto użytkownika ma kilka atrybutów zawierających informacje logowania. Chcemy znaleźć atrybuty pokazujące czas ostatniego logowania. Jeśli uda nam się znaleźć te atrybuty, możemy użyć ich do wyszukania kont niezalogowanych od określonej daty. Możemy użyć PowerShell, aby wyświetlić wszystkie reguły i wybrać atrybut do pracy.
Get-ADUser jest najczęściej używanym cmdletem do wyświetlania informacji o użytkowniku. Możesz użyć Get-ADObject i Search-Adaccount, ale Get-ADUser jest najlepszym cmdletem dla naszego zadania. Aby wyświetlić wszystkie właściwości użytkownika, musimy dodać-properties * do składni cmdlet. Jeśli pominiemy tę składnię, zobaczymy tylko domyślne właściwości, czyli tylko 10 właściwości.
Get-ADUser Michael_Kanakos -Properties *
zwracamy długą listę pól z naszego zapytania (ponad 150!). Możemy wyszukiwać atrybuty zawierające konkretne słowa za pomocą symboli wieloznacznych. Pomaga nam to zlokalizować atrybuty, które mogą być przydatne dla naszego zadania. Chcemy znaleźć informacje o logowaniu, więc poszukajmy atrybutów zawierających słowo Logon.
gdy powiemy Powershellowi, aby pobrał wszystkie właściwości, byłoby pomocne, gdybyśmy mogli ograniczyć listę właściwości tylko do pokazywania właściwości, które pasują do logowania słowa. Select-Object daje możliwość rozegrania meczu z dziką kartą i ograniczenia naszych wyników. Znak / (zwany „the pipe”) pobiera wyniki po lewej stronie i przekazuje je do wyboru-obiektu. Select-Object następnie przeprowadza dopasowanie dzikiej karty, a następnie ogranicza wyniki na podstawie naszych kryteriów dzikiej 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
wyniki będą się nieco różnić w zależności od poziomu funkcjonalności domeny Active Directory. Moje wyszukiwanie zwraca osiem atrybutów. Trzy wyglądają obiecująco: LastLogon, LastLogonDate i LastLogonTimeStamp. Niektóre wartości mogą wyglądać trochę dziwnie, jeśli nie jesteś zaznajomiony z tym, jak Active Directory przechowuje informacje o dacie i godzinie w określonych atrybutach. Niektóre informacje o dacie są tradycyjnymi informacjami o dacie i czasie, a niektóre są zapisywane jako ” kleszcze.”
wartości daty w PowerShell i. NET Framework przedstawiają daty jako liczbę wskazów od 12: 00 1 stycznia 0001. Kleszcze są równe jednej dziesiątej milionowej sekundy, co oznacza, że na milisekundę przypada 10 000 kleszczy. Istnieją cmdlety matematyczne, które mogą konwertować Kleszcze do standardowego formatu daty.
PowerShell pokazuje rzeczywisty znacznik, który reprezentuje datę/godzinę. Jeśli wygodnie konwertujesz Kleszcze do formatu daty, możesz spojrzeć na te pola w Active Directory User and Computers lub Active Directory Administrative Center. W obu aplikacjach kleszcze są reprezentowane jako format daty czasu.
Aduser-Logon-Propertes
Wyjaśnienie atrybutów logowania
nasze wyszukiwanie znalazło wiele właściwości, które wyświetlają informacje o dacie/godzinie logowania. Dwie właściwości mają tę samą datę i godzinę, a jedna nie. Co tu się dzieje?
wariancja informacji o dacie i czasie jest zaprojektowana i jest na miejscu, aby chronić DC przed zmiażdżeniem ruchem replikacji, próbując zsynchronizować wszystkie informacje o logowaniu. Właściwość LastLogon aktualizuje się za każdym razem, gdy uwierzytelniasz, ale dane są przechowywane na DC, na którym uwierzytelniasz i nie są replikowane do innych DC. właściwości LastLogonTimeStamp i LastLogonDate są replikowane do wszystkich DC, ale replikacja zdarza się rzadko.
jeśli spojrzymy na daty, zobaczymy, jak opóźniona replikacja może wpłynąć na nasze zapytanie. Zauważ, że LastLogonTimeStamp jest rzeczywiście dwa dni w tyle w tym przykładzie. Za każdym razem, gdy użytkownik interaktywnie loguje się, dotyka udziału plików sieciowych lub wykonuje inne działania, które wymagają uwierzytelnienia konta przez sieć, przechowuje informacje o logowaniu w usłudze Active Directory. Jeśli dc replikuje te dane za każdym razem, gdy ktoś dotknie czegoś w sieci, DC może być przytłoczony w dużym środowisku. W rezultacie niektóre informacje logowania są dokładne, ale nie są replikowane, a niektóre informacje logowania replikują się, ale tylko sporadycznie.
dla naszych wymagań nie potrzebujemy dokładnego znacznika czasu logowania. Musimy tylko znaleźć konta, które nie logowały się od dłuższego czasu (dłużej niż 90 dni). Każda wartość może być przydatna, nawet jeśli data jest wyłączona o kilka dni. Jeśli jako przykład użyjemy moich dat logowania, zapytany czas może wynosić 11/11 lub 11/13, w zależności od użytej wartości. Przewiń do przodu trzy miesiące i załóżmy, że nigdy więcej się nie zalogowałem. Jedna data oznaczałaby jako nieaktywna przez ponad 90 dni, a jedno pole nie. Ale jeśli skonfiguruję ten proces, aby działał co miesiąc, złapię konto następnym razem, gdy sprawdzimy. To jest najważniejsza część. Jeśli robimy to regularnie, możemy użyć dowolnego pola, o ile konsekwentnie sprawdzamy.
użyłem właściwości LastLogonDate z dwóch powodów. Po pierwsze, jest to już wartość daty, więc nie muszę zajmować się konwersją wartości. Po drugie, jest to powielana wartość, która ułatwia mi życie. Jeśli użyłbym LastLogon, miałbym daty, które nie są aktualne dla osób, które są uwierzytelniania wobec innych kontrolerów domeny w mojej sieci. Musiałbym zapytać lokalnego DC dla każdego użytkownika, aby uzyskać najnowszy znacznik czasu, a to jest dużo pracy do zrobienia i niezbyt wydajne.
aby uzyskać informacje na temat jednego konta, kod jest prosty.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
aby to zrobić dla wszystkich moich użytkowników wymaga tylko trochę więcej kodu. Musimy użyć filtra do odpytywania wszystkich kont użytkowników.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
teraz znajdźmy tylko konta z datą logowania starszą niż 90 dni. Potrzebujemy zapisanej bieżącej daty, aby użyć jej jako operatora porównania.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
ten kod pobiera wszystkich użytkowników, którzy nie zalogowali się w ciągu 90 dni. Zapisujemy datę 90 dni temu do zmiennej. Możemy utworzyć filtr reklam, aby znaleźć loginy mniejsze niż ta data. Następnie musimy dodać wymóg odpytywania tylko aktywnych kont. W tym przykładzie używam splatting, aby Kod był bardziej czytelny, ponieważ składnia jest bardzo długa. Splatting ad cmdlets może być trudny, więc pokazałem również długą wersję składni pod przykładzie 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 daje nam naszych nieaktywnych użytkowników, którzy są włączeni. Zapisujemy wyniki do zmiennej w celu ponownego użycia. Właściwość Distinuishedname jest potrzebna później. Gdy znajdziemy użytkowników, możemy pracować nad naszym następnym krokiem: wyłączanie kont. Używamy polecenia Set-ADUser do wprowadzania zmian na koncie użytkownika reklamy.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
wyłączyliśmy nasze konta użytkowników. Czas przenieść ich do nowego biura. W naszym przykładzie użyjemy OU nazwanego Disabled-Users. Wyróżnioną nazwą dla tego OU jest „ou=Disabled-Users,DC=Contoso,DC = Com” używamy polecenia Move-ADObject, aby przenieść użytkowników do docelowego OU.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
w naszym ostatnim kroku użyliśmy Move-ADObject, aby przenieść użytkowników do nowego OU. Mamy teraz Podstawowy kod potrzebny do stworzenia niezawodnego, powtarzalnego zautomatyzowanego zadania. Co dalej? To zależy od indywidualnych wymagań. Ten kod może i powinien być skonfigurowany tak, aby działał automatycznie co miesiąc o tej samej porze. Jednym z łatwych sposobów jest utworzenie zaplanowanego zadania, aby uruchamiać kod co miesiąc.
możemy dodać więcej do tego kodu, aby go ulepszyć. Kod do sprawdzania błędów i dodatkowe pola informacji o użytkowniku byłyby dwoma przydatnymi dodatkami. Większość zespołów wykonujących tego typu zadania generuje raport o tym, co zostało wyłączone, aby ktoś mógł je przejrzeć, więc dodatkowe pola będą się zmieniać. Możesz dodać więcej pól z Active Directory, aby raport był bardziej użyteczny. Możemy wykonać to zadanie o krok dalej, tworząc kolejne zadanie, aby usunąć tych niepełnosprawnych użytkowników po 6 miesiącach.
rozwiązywanie trudnych żądań automatyzacji jest znacznie łatwiejsze, gdy zadania są podzielone na łatwe do zarządzania części. Zaczęliśmy od wymagań i zbudowaliśmy naszą składnię w małych krokach; potwierdzając, że każdy krok działa, zanim spróbujemy dodać kolejną zmienną. Robiąc to, uczyniliśmy to zadanie łatwym do zrozumienia i miejmy nadzieję wspaniałym doświadczeniem edukacyjnym.