Stosowanie w kartotece usługi Active Directory podsieci typu przechwyć-wszystko

Autor: John Policelli

Opublikowano: 11 września 2009

Zawartość strony

	Sposób lokalizowania kontrolerów domeny przez klientów
	Problem
	Podsieć typu Przechwyć-wszystko (Catch-All)
	Podsumowanie

W idealnej sytuacji użytkownicy uwierzytelniani za pomocą usługi katalogowej Active Directory są kierowani do odpowiedniego kontrolera domeny (DC - domain controller). W większości organizacji może jednak dziać się inaczej, z powodu braku w kartotece usługi katalogowej Active Directory prawidłowych informacji o podsieci IP. W rezultacie uwierzytelnianie części użytkowników prowadzone jest przez arbitralnie wybrany kontroler domeny, który może nie być optymalny z punktu widzenia uwierzytelniania w usłudze katalogowej Active Directory.

W tym artykule przedstawione zostanie możliwe rozwiązanie, gwarantujące odnajdywanie przez użytkowników odpowiedniego kontrolera domeny dla celów uwierzytelniania, również wówczas, gdy informacje o podsieci IP nie zostały w pełni skonfigurowane w kartotece Active Directory.

Sposób lokalizowania kontrolerów domeny przez klientów

Gdy komputer przystępuje do wyszukiwania w sieci kontrolera domeny, następuje zainicjowanie procesu nazywanego lokalizatorem kontrolera domeny, pozwalającego na zlokalizowanie w sieci odpowiedniego kontrolera domeny Active Directory. Proces lokalizatora wykorzystuje informacje zapisane w kartotece usługi Active Directory próbując odnaleźć kontroler domeny pełniący żądane role i znajdujący się w lokacji położonej najbliżej danego klienta.

Proces lokalizatora wykorzystuje informacje zdefiniowane w kontenerze Configuration (Konfiguracja) głównej domeny lasu domen, który jest replikowany na wszystkie kontrolery domeny w obrębie lasu domen. Do wyszukania kontrolera domeny położonego najbliżej komputera klienta proces lokalizatora musi korzystać z obiektów lokacji, obiektów podsieci oraz z obiektów serwerów kontrolera domeny. Obiekty lokacji służą do reprezentowania lokacji (ang. site) usługi Active Directory. Obiekty podsieci (ang. subnet) służą do reprezentowania segmentów adresów IP i są skojarzone z odpowiednimi obiektami lokacji. Obiekty serwerów kontrolera domeny są natomiast używane do reprezentowania kontrolerów domeny i również są skojarzone z obiektami lokacji.

Kontrolery domeny Active Directory rejestrują w systemie DNS rekordy określające lokacje, w których znajdują się te kontrolery. Liczba rekordów DNS rejestrowanych przez każdy z kontrolerów domeny zależy od ról pełnionych przez dany kontroler. Np. kontroler domeny, który jest serwerem katalogu globalnego (ang. Global Catalog), zarejestruje dodatkowy rekord DNS ogłaszając w ten sposób, że pełni on tę rolę. Podobnie kontroler domeny pełniący rolę Operations Master zarejestruje rekord DNS ogłaszający pełnienie przez niego tej roli. Proces lokalizowania kontrolera domeny przez komputer klienta przebiega w następujący sposób:

1. Na komputerze klienta zostaje zainicjowany proces lokalizatora, poprzez wykonanie zdalnego wywołania procedury (RPC), skierowanego do lokalnej usługi Net Logon.
2. Klient gromadzi informacje potrzebne do wybrania właściwego kontrolera domeny i przekazuje je do usługi Net Logon.
3. Działająca na komputerze klienta usługa Net Logon używa zgromadzonych informacji do utworzenia zapytania, które zostanie wysyłane do systemu DNS w celu zidentyfikowania odpowiedniego kontrolera domeny.
4. Działająca na komputerze klienta usługa Net Logon, wysyła datagram do wykrytych kontrolerów domeny.
5. Zapytanie zostaje przechwycone przez usługę katalogową, która przekazuje je do usługi Net Logon, działającej na kontrolerze domeny.
6. Usługa Net Logon , działająca na kontrolerze domeny, używa adresu IP klienta do wyszukania w tabeli zawierającej odwzorowania podsieci na poszczególne lokacje obiektu podsieci najlepiej pasującej do adresu IP klienta. W wyniku tego wyszukiwania usługa zwraca do klienta następujące informacje: nazwę lokacji, w której znajduje się dany klient, lub nazwę lokacji najlepiej pasującej do adresu IP tego klienta; nazwę lokacji, w której znajduje się obecny kontroler domeny; oraz bit wskazujący, czy znaleziony kontroler domeny znajduje się w najbliższej lokacji dla danego klienta.
7. Klient sprawdza otrzymane informacje określając, czy powinien próbować znaleźć lepszy kontroler domeny. Decyzja ta jest podejmowana w następujący sposób: Jeśli zwrócony kontroler domeny znajduje się w najbliższej lokacji, to użyty zostanie ten kontroler domeny; Jeśli znaleziony przez klienta kontroler domeny znajduje się w lokacji, która według kontrolera domeny jest tą samą lokacją, w której znajduje się również sam klient, to użyty zostanie ten kontroler domeny. Jeśli znaleziony kontroler domeny nie znajduje się w najbliższej lokacji, klient zaktualizuje informacje o lokacji i wyśle nowe zapytanie DNS w celu znalezienia nowego kontrolera domeny w danej lokacji. Jeśli drugie zapytanie zakończy się powodzeniem, użyty zostanie nowy kontroler domeny. Jeśli natomiast drugie zapytanie zakończy się niepowodzeniem, użyty zostanie oryginalny kontroler domeny.
8. Jeśli odpytywana przez klienta domena jest tą samą domeną, do której należy komputer klienta, to informacje o lokacji komputera są zapisane na komputerze klienta w jego rejestrze.
9. Po zlokalizowaniu przez klienta kontrolera domeny, informacje o tym kontrolerze zostają zapamiętane w pamięci podręcznej. Jeśli kontroler domeny nie znajduje się w optymalnej lokacji, zawartość tej pamięci jest czyszczona przez klienta po upływie 15 minut. Następnie klient podejmie próbę znalezienia optymalnego kontrolera domeny, który będzie położony w tej samej lokacji.

W przypadku gdy komputer klienta używa adresu IP, który nie ma swojej reprezentacji w tabeli odwzorowującej podsieci na lokacje, kontroler domeny zwróci jako nazwę lokacji wartość NULL, a klient korzystać będzie ze wskazanego kontrolera domeny, który może znajdować się w dowolnej lokacji usługi katalogowej Active Directory.

 Do początku strony

Problem

Jeśli kontroler domeny nie może określić najbliższej lokacji z powodu braku w kartotece Active Directory informacji o podsieci IP, to w procesie uwierzytelniania używany będzie nieoptymalny kontroler domeny.

Rysunek 1 przedstawia przykładową architekturę lokacji kartoteki Active Directory o topologii gwiaździstej (ang. hub and spoke). Użytkownicy logujący się przy użyciu komputera znajdującego się w jednej z podsieci zdefiniowanych w kartotece Active Directory zostają skierowani do uwierzytelnienia w najbliższej lokacji usługi Active Directory. Natomiast użytkownicy logujący się przy użyciu komputera znajdującego się w dowolnej innej podsieci, np. 10.1.4.0/24, zostaną skierowani do arbitralnie wybranego kontrolera domeny.

Odpowiednim rozwiązaniem tego problemu jest oczywiście zdefiniowanie dodatkowych podsieci w kartotece usługi Active Directory i skojarzenie ich z odpowiednimi lokacjami. Wiele organizacji (zwłaszcza średniej i dużej wielkości) często jednak spotyka się z problemami w uzyskiwaniu informacji potrzebnych do dodania tych dodatkowych podsieci do kartoteki Active Directory. Co więcej, dzięki różnym błędom i plikom dzienników administratorzy usługi Active Directory zwykle mają świadomość istnienia dodatkowych podsieci, ale nie wiedzą, w których fizycznych biurach się one znajdują, co uniemożliwia im określenie lokacji, z którymi należy skojarzyć te podsieci.

 Do początku strony

Podsieć typu Przechwyć-wszystko (Catch-All)

Bardziej praktycznym rozwiązaniem tego problemu jest użycie w kartotece usługi Active Directory jednej lub kilku podsieci typu przechwyć-wszystko (ang catch all). Podsieć typu przechwyć-wszystko jest podsiecią usługi Active Directory, która jest używana do przechwytywania żądań uwierzytelniania użytkowników pochodzących od klientów z podsieci, które nie zostały zdefiniowane w usłudze Active Directory. Podsieć typu przechwyć-wszytko jest zasadniczo super podsiecią. Jak pokazano na Rysunku 1, podsieć 10.1.1.0/24 została zdefiniowana w kartotece usługi Active Directory i jest skojarzona z lokacją Toronto usługi Active Directory. Załóżmy, że zauważyliśmy uwierzytelnianie w usłudze Active Directory klientów z podsieci 10.1.4.0/24 oraz 10.1.5.0/24. Na podstawie prefiksu tych podsieci (10.1.x.x) zakładamy, że znajdują się one w biurze w Toronto. Chcemy więc, by komputery z tych podsieci, a także ze wszystkich innych podsieci używających prefiksu 10.1.x.x, były uwierzytelniane przez kontroler domeny z lokacji Toronto. Należy więc utworzyć podsieć typu przechwyć-wszystko z prefiksem 10.1.0.0/16 i wszystkie żądania uwierzytelniania napływające z tych podsieci, które naszym zdaniem znajdują się w biurze w Toronto, skierować do kontrolera domeny z lokacji Toronto. Odwzorowanie podsieci typu przechwyć-wszytko dla tego przykładu zostało pokazane na Rysunku 2.

W większości organizacji administratorzy usługi Active Directory są informowani o tym, jakie podsieci IP są używane w odległych biurach. Brak tego typu informacji zwykle dotyczy biur centrali, lokalizacji centralnych oraz centrów przetwarzania danych. Podsieci typu przechwyć-wszytko można użyć do usprawnienia procesu uwierzytelniania również w tych przypadkach. Ponieważ podsieci IP dla zdalnych biur są prawie statyczne i zwykle są one dobrze znane administratorom, podsieci typu przechwyć-wszystko można utworzyć dla wszystkich pozostałych podsieci.

W kolejnym przykładzie utworzymy podsieć typu przechwyć-wszystko z prefiksem 10.0.0.0/8, której zadaniem będzie przechwytywanie żądań uwierzytelniania napływających ze wszystkich podsieci, które naszym zdaniem nie należą do żadnego ze zdalnych biur, i kierowanie tych żądań do kontrolera domeny z centralnej lokacji Toronto. Odwzorowanie podsieci typu przechwyć-wszytko dla tego przykładu zostało pokazane na Rysunku 3 przy użyciu tekstu w kolorze czerwonym. W razie potrzeby możliwe jest nawet użycie kilku podsieci typu przechwyć-wszystko tak, jak to zostało pokazane na Rysunku 4.

Należy zwrócić uwagę na fakt, że podsieci typu przechwyć-wszystko, pokazane na Rysunku 3 i 4, używają prefiksów obejmujących prefiksy używane w zdalnych biurach (np. prefiks 10.0.0.0/8 obejmuje prefiks 10.1.1.0/24). Można więc zacząć się zastanawiać, czy żądania uwierzytelniania napływające z komputerów znajdujących się w tych zdalnych biurach nadal będą kierowane do odpowiednich kontrolerów domeny, znajdujących się w danym biurze. Odpowiedź na to pytanie brzmi: tak. Jeśli w kartotece usługi Active Directory istnieją nakładające się na siebie podsieci IP, to użyta zostanie podsieć o najmniejszej pasującej masce. Np. jeśli adres IP komputera pochodzić będzie z podsieci 10.1.1.5/24, to użyta zostanie podsieć 10.1.1.0/24, a nie 10.0.0.0/8. Jeśli jednak komputer będzie mieć adres IP 10.1.1.5, to użyta zostanie podsieć 10.1.1.1./32, a nie podsieć 10.1.1.0/24.

 Do początku strony

Podsumowanie

Zanim przejdziemy do implementowania w praktyce podsieci typu przechwyć-wszystko, należy zdać sobie sprawę, że koncepcja podsieci typu przechwyć-wszytko nie jest odpowiednia dla każdego środowiska. Możliwość zastosowania tego rozwiązania zależy w dużym stopniu od przyjętego schematu adresacji IP.

W prezentowanych przykładach używany był całkiem prosty schemat adresacji IP. Jednak wraz ze wzrostem złożoności używanego schematu adresacji IP, możliwości zastosowania podsieci typu przechwyć-wszystko stają się coraz mniejsze. Jeśli np. nasze środowisko będzie się składać z wielu segmentów sieci, a schematy adresacji używane w poszczególnych lokalizacjach nie będą sekwencyjne, to utworzenie podsieci typu przechwyć-wszystko posiadającej jakąkolwiek wartość będzie praktycznie niemożliwe. Podobnie jak w przypadku każdego rozwiązania, określając możliwości implementacji podsieci typu przechwyć-wszystko należy uwzględnić wszelkie aspekty techniczne, biznesowe i środowiskowe, charakterystyczne dla posiadanego środowiska.

Należy również pamiętać, że użycie podsieci typu przechwyć-wszytko nie rozwiązuje całkowicie problemu brakujących definicji podsieci. W rzeczywistości wprowadzając do swojego środowiska podsieci typu przechwyć-wszystko jawne zdefiniowanie w kartotece usługi Active Directory wszystkich znanych podsieci staje się jeszcze ważniejsze.

Użycie podsieci typu przechwyć-wszystko pozwala zwiększyć liczbę użytkowników lokalizujących prawidłowo najbliższy kontroler domeny. Naszym celem nadal jednak powinno być zlikwidowanie przyczyn problemu i doprowadzenie do sytuacji, w której będziemy odpowiednio informowani o wszystkich dodawanych, modyfikowanych i usuwanych podsieciach, co pozwoli na utrzymywanie w kartotece usługi Active Directory aktualnej architektury lokacji, zapewniającej efektywne uwierzytelnianie wszystkich użytkowników.

O autorze

John Policelli (posiada tytuł Microsoft MVP z zakresu usług katalogowych Directory Services oraz certyfikaty MCTS, MCSA, ITSM, iNet+, Network+ i A+) jest konsultantem IT, od ponad dziesięciu lat specjalizującym się z powodzeniem w architekturze, zabezpieczeniach, planowaniu strategicznym oraz planowaniu odtwarzania po całkowitej katastrofie. Ostatnie dziewięć lat poświęcił tematyce zarządzania tożsamością i dostępem (Identity and Access Management), kierując kilkoma z największych instalacji usługi katalogowej Active Directory w Kanadzie. John utrzymuje swój własny blog pod adresem http://policelli.com/blog.

Do początku strony