Tuesday, April 7th, 2009...10:01 pm

Pokrycie podsieci – zagadka rozwiązana

Jump to Comments

Dwa dni temu kolega w pracy zwrócił mi uwagę że nie odpowiedziałem jeszcze na głos ludu wyrażony w komentarzach pod postem dotyczącym ustalania lokacji. Się wzięło na barki obowiązek blogowania … trzeba cierpieć. Dzisiaj więc kilka uwag w temacie lokalizowania kontrolera domeny i sterowania tym procesem.


(cc) Martin Deutsch

Przypomnijmy więc sobie oryginalny problem, od którego opisywanie się zaczeło. W sieci, w której istnieje kilka lokalizacji fizycznych z przypisanymi podsieciami zapanował mały bałagan. Wynikiem tego bałaganu jest sytuacja, w której nie wszystkie podsieci przypisane są do odpowienich lokacji. Jako remedium dla takiej sytuacji, do lokacji głównej usługi katalogowej (nazwijmy tak hub replikacji przyjmijmy skrót w procesie myślowym że konfiguracja naszej sieci odpowiada topologii hub-n-spoke), przypisana została super podsieć obejmująca wszystkie pozostałe podsieci. Teoretycznie miało to służyć temu, by klienci którzy nie mają bezpośrednio przypisanej podsieci do lokcji zawsze korzystali z kontrolerów domeny w lokacji głównej. Nie do końca prawidłowa to droga i ma swoje konsekwencje o których pisałem poprzednio.

Sytuacja sieciowa

Zacznijmy od opisu naszej sytuacja w zakresie lokacji usługi katalogowej i przypisanych do nich podsieci wygląda tak:

  • Default-First-Site (IP subnet: 192.168.1.0/24), DC –> LHFDC01
  • DMZ (IP subnet: 192.168.2.0/24), DC –> LHFDC02

Żeby sprawę skomplikować w sieci istnieje jeszcze jedna podsieć 192.168.3.0/24, w której pracują klienci (czytaj stacje robocze), a dla której nie został utworzony odpowiedni obiekt podsieci w katalogu, tym samym nie została ona przypisana do żadnej z istniejących lokacji. Administrator zapomniał … zdarza się.

Jak więc możemy w takiej sytuacji podejść do konfiguracji i jak pokierować wyborem kontrolera domeny przez klientów?

Czytanka

Na początek, dla przypomnienia linki do serii artykułów jakie popełnił Jorge, które opisują proces lokalizacji kontrolera domeny: część 1, 2 i 3. Teraz uzbrojeni w tę wiedzę możemy przystąpić do konfiguracji. Kluczem do sukcesu jest tutaj zamodelowanie procesu lokalizacji kontrolera domeny przy pomocy odpowiedniej rejestracji rekordów DNS przez kontrolery domeny w odpowiednich lokalizacja. Dla przypomnienia – każdy kontroler domeny rejestruje domyślnie dwa zestawy rekordów usług:

  • na poziomie domeny (domain wide)
  • dla własnej lokalizacji (site specific).

Klient lokalizując kontroler domeny próbuje zawsze zlokalizować kontroler we własnej lokalizacji, czyli w efekcie skorzystać z kontrolera domeny, który zarjestrował rekordy DNS specyficzne dla danej lokalizacji. Jeżeli to mu się nie uda spróbuje on skontaktować się z jednym z kontrolerów domeny, który zarejestrował swoje rekordy dla całej domeny.

W przypadku naszego klienta w podsieci 192.168.3.0/24 nie jest on w stanie określić kontrolera domeny w ramach własnej lokalizacji, ponieważ ona nie istnieje. Spróbuje więc znaleźć jeden z kontrolerów domeny, który zarejestrował rekordy DNS na poziomie domeny – czyli wybierze jeden z dwóch dostępnych kontrolerów LHFDC01 lub LHFDC02. Pomimo że całość będzie działać to nie jest to do końca to o co nam chodziło.

Konfiguracja

Spróbujmy więc sytuacje poprawić. Kluczem jest tutaj możliwość określenia dla danego kontrolera domeny poprzez odpowiednią opcję GPO, których rekordów DNS nie powinien on rejestrować porzez usługę Netlogon. W naszym wypadku chcemy powstrzymać LHFDC02 od rejestracji rekordów na poziomie domeny, tak aby mógł być zlokalizowany tylko w ramach własnej lokacji.

W tym celu prznosimy LHFDC02 do osobnego OU, na poziomie tego OU tworzymy nowe GPO i w ramach tego GPO ustawiamy opcję “DC locator DNS records not registered by the DCs” podając wartość “LdapIpAddress Ldap Gc GcIPAddress Kdc Dc DcByGuid Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc”.

Dzięki temu nasza stacja robocza działająca w sieci 192.168.3.0/24 po nieudanej próbie zlokalizowania kontrolera domeny we własnej lokacji zapyta się o kontrolery, które zrejestrowały się na poziomie domeny … w wyniku tego zapytania uzyska jedynie adres LHFDC01. Co odpowiada naszemu zamierzeniu (aczkolwiek w rzeczywistej sytucji warto by było, żeby tych kontrolerów było conajmniej dwa).

I w ten sposób używając jedynie konfiguracji i odpowiedniej rejestracji rekordów DNS przez kontrolery domeny uzyskaliśmy interesujący nas efekt, w którym stacji robocze bez przypisanej lokacji używają kontrolerów w lokcji centralnej w celu uwierzytelnienia. Co było do okazania :).

Pozostaje jeszcze kwestia lokalizacji SYSVOL 🙂 … ale to już temat na kolejny wpis :).

Małe PS

A prewencyjnie … każda próba dostępu klienta bez przypisanej lokacji powoduje na odpowiednim DC, który obsłużył to zapytanie odnotowanie tego faktu w event log i pliku netlogon.log. Można więc pomyślec o wdrożeniu procesu, który takie wpisy będzie analizwał i sukcesywnie “dziury” w konfiguracji podsieci będą identyfikowane i łatane. Ale czy ja nie za dużo bym chciał …. 🙂

2 Comments

  • Dzieki za garsc cennych informacji!

  • ” … Pozostaje jeszcze kwestia lokalizacji SYSVOL 🙂 … ale to już temat na kolejny wpis :). …”
    Ja tylko czekam cierpliwie na kolejną “garść cennych informacji” 🙂

Leave a Reply