Automatyczne dodawanie nowych podsieci Active Directory

1 lipca 2015 at 14:09

Jak ważny jest porządek w podsieciach i lokacjach Active Directory wie każdy, kto ma styczność z usługami katalogowymi. Nieporządek skutkuje w najlepszym wypadku opóźnionymi czasami logowania i uwierzytelniania oraz przestojami w replikacji, natomiast w najgorszym jest w stanie rozłożyć Active Directory na łopatki. Można mieć 100% procedury zarządzania nowymi podsieciami i przyłączania ich do AD, natomiast zawsze istnieje ryzyko, że coś zostanie pominięte. Aby tego uniknąć można oczywiście zautomatyzować sobie część pracy. Założenia: 1. W Active Directory tworzymy lokację działającą jak czyściec, gdzie trafiać będą wszystkie nowe, nieuwzględnione wcześniej przez administratorów podsieci. Lokację nazywamy ‚Purgatory‚ 2. Wszystkie podsieci w firmie mają maskę /24 (255.255.255.0) 3. Cyklicznie przeglądamy czyściec żeby rozrzucić podsieci do prawidłowych lokacji, lub generujemy jakieś reguły przydziału automatycznego   Od strony technicznej: Na każdym z kontrolerów domeny w lokalizacji: ‚C:\Windows\Debug\Netlogon.log‚ znajduje się plik, gdzie logowane są między innymi zdarzenia o klientach nie przypisanych do żadnej lokacji AD. Każdy taki wpis ma postać:

Wystarczy więc zacząć monitorować zmiany w pliku na kontrolerach domeny i automatycznie przetwarzać dane w nich zawarte. Let’s go 😉

W pierwszym kroku sprawdzamy, czy plik netlogon.log zmienił sie w ciągu ostatniego dnia. Jeśli nie, to nie przetwarzamy danych. Jeśli tak – zaczynamy zabawę […]

Delegacja uprawnień Active Directory z Powershella

1 lipca 2015 at 12:35

O delegacji uprawnień do obiektów Active Directory było już wiele artykułów, ale zdecydowana większość z nich  opiera się o przeklikiwanie delegacji z interfejsu graficznego. Nie dość, że zajmuje to sporo czasu, to odnalezienie szczegółowego atrybuty, do którego chcemy przekazać kontrolę innej osoby może skończyć się oczopląsem… 😉 Jak więc zrobić to szybciej i sprawniej? Oczywiście wykorzystując Powershella. Niezbędna będzie zainstalowana przystawka Quest AD Management (dla mnie wygodniejsza niż natywny moduł do AD)

I teraz załóżmy, że chcemy wydelegować uprawnienia do modyfikacji atrybutu ‚physicalDeliveryOfficeName’ użytkowników w jednostce „OU=IT,DC=mkrzanowicz,DC=corp” dla grupy „PhoneAdmins”: Wystarczy, że w tym celu wykorzystamy polecenie:

Jesli uprawnienia mają być delegowane również „w dół” to używamy przełącznika -ApplyTo ‚ChildObjects’ w przeciwnym wypadku -ApplyTo ‚ThisObjectOnly’. Jeśli chcemy jawnie odmówić jakiegoś uprawnienia, to dorzucamy przełącznik -Deny W przypadku, gdy chcemy zastosować do konkretnych obiektów, to uwzględniamy je w przełączniku -ApplyToType  np: ‚group’, ‚organizationalUnit’,’user’ itd. Natomiast typ delegowanych uprawnień obsługujemy przełącznikiem -Rights np: ‚ReadProperty’,’WriteProperty’, ‚CreateChild’  itd. Jeśli wykorzystamy uprawnienie ‚CreateChild’ to możemy dodatkowo określić jakich typów będzie ono dotyczyć np: -ChildType ‚user’   Polecenie jest na prawdę bardzo użyteczne i pozwala wykonać zasadniczo każą, najbardziej zawiłą delegacje uprawnień. Ostatecznie możemy również uprawnienia skopiowac z wzorcowej jednostki 1:1 poleceniem:

Enjoy! 😉

Zdalna deinstalacja poprawek

1 lipca 2015 at 07:50

Niestety ostatnio coraz częściej zdarza się, że Microsoft wypuszcza poprawki, które psują pewne działające wcześniej funkcjonalności systemów. W przypadku, gdy zależy nam na szybkim usunięciu poprawki z wybranej stacji roboczej/serwera celem weryfikacji czy dana poprawa była przyczyną zaprzestania działania funkcjonalności i nie mamy do tego żadnych płatnych narzedzi możemy wykorzystać oczywiście Powershell’a Skorzystamy z narzędzia systemowego wusa.exe, z tym że trochę podrasujemy zwracane przez nie wyniki, żebyśmy mieli na bieżąco informację o tym, czy dana poprawka jest w trakcie deinstalacji, czy proces już się zakończył:

Wykorzystanie powyższej funkcji np: Uninstall-Hotfix -computername PC1 -HotfixID KB2676562

Nie można odnaleźć zasobu $(string. * ), do którego odwołuje się atrybut displayName. Plik *.admx

27 kwietnia 2015 at 16:50

Kolejny dzień – kolejne problemy do rozwiązania Tym razem problemy z GPO, a ściślej mówiąc z widocznością ustawień i możliwością ich edycji. Podczas próby podglądu czy edycji ustawień GPO użytkownicy otrzymywali groźnie wyglądające błędy typu: Na szczęście sytuacja nie była zła, bo zasady grup działały, aplikowały zmiany itd. Co ciekawe na kontrolerach domeny problem nie występował – tam można było normalnie przeglądać i edytować ustawienia wszystkich GPO: Gdzie jest więc „pies pogrzebany”? W tym środowisko funkcjonuje Central Store for Group Policy Admin Templates, więc nie była to kwestia poszczególnego kontrolera domeny. Zostały również sprawdzone uprawnienia użytkownika per konkretne GPO i plik ADMX z definicją – wszystko było OK… Podmienione zostały nawet wybrane pliki ADMX – bez efektu… Sprawa niby nie pilna, bo zasadniczy mechanizm GPO działał prawidłowo, natomiast mocno irytująca dla operatorów GPO. Test na spostrzegawczość – czym jeszcze różnią się zrzut działający od tego, który nie działał jak powinien? Bingo – językiem A więc mimo opisu wskazującego na uszkodzenie plików ADMX – w istocie problem stanowiły pliki ADML odpowiadające za „reprezentację” zasad w danym języku. Prawdopodobnie ktoś podczas aktualizacji folderu „PolicyDefinitions” na SYSVOL’u zapomniał o wgraniu aktualnych plików ADML lub podczas odtwarzania/przywracania plików rozjechały się ich tłumaczenia. Jak można […]

Czyszczenie metadanych Active Directory po awarii kontrolera domeny

16 kwietnia 2015 at 13:37

Cytując klasyka – „Nie myli się ten kto nie robi niczego”. Bywają sytuacje nieprzewidziane, gdzie awarii ulega któryś z kontrolerów domeny i nie bardzo jest sposób na przywrócenie mu pełnej funkcjonalności. Pozostaje więc usunięcie kontrolera domeny, posprzątanie bazy Active Directory i wypromowanie nowego kontrolera. Pamięć często choć dobra – bywa krótka… więc jako przypomnienie procedura sprzątania metadanych Active Directory po awarii kontrolera domeny. Zakładając, że kontroler, który uległ awarii nie utrzymywał żadnej z ról FSMO (jeśli utrzymywał trzeba je awaryjnie przejąć) procedura powinna wyglądać mniej więcej tak: 1. Zalogowanie się na działający kontroler domeny z uprawnieniami administratora domeny. 2. Uruchomienie jako administrator powershell’a / wiersz poleceń 3. Uruchomienie narzędzia ndtsutil:

4. Przejście do trybu oczyszczania metadanych Active Directory:

5. Wybranie połączenia:

6. Połączenie z działającym (np. lokalnym) kontrolerem domeny:

7. Powrót do wyższej instancji

8. Przejście w tryb wyboru celu

9. Wy listowanie dostępnych domen

10. Wskazanie numery domeny, gdzie znajdował się kontroler domeny, który uległ awarii

11. Wy listowanie dostępnych lokacji

12. Wskazanie numeru lokacji, w której był nasz kontroler domeny:

13. Wy listowanie wszystkich obiektów kontrolerów domeny we wskazanej lokacji Active Directory

14. Wskazanie konkretnego kontrolera domeny […]

© Marcin Krzanowicz