Proces lokalizacji kontrolerów domeny – DC Locator

Proces lokalizacji kontrolerów domeny – DC Locator

Potoczne „logowanie do domeny” termin popularny, znany, powszechny. Ot, niby nic nadzwyczajnego – jednakże mało kto wie jak przebiega ten proces krok po kroku. Nie mając natomiast wiedzy o zasadzie działania niezwykle trudno realizować efektywny troubleshooting.

Spróbujmy zatem rozpocząć od tego jak wygląda proces lokalizacji kontrolerów domeny (DCLocator Process).

DC Locator jest procesem wyszukiwania i określania kontrolera domeny wykorzystywanego przez klienta (lub aplikację świadomą Active Directory) podczas logowania oraz dalszej pracy systemu. Wchodząc głębiej w szczegóły techniczne – jest to specjalny algorytm działający w kontekście usługi Netlogon w ramach każdego systemu operacyjnego Windows. Ten algorytm wykorzystuje w swoim działaniu głównie dwie funkcjonalności:

  • Rozwiązywanie nazw domenowych (DNS)
  • Topologię Active Directory (AD Sites, AD subnets)

Wydaje mi się, że tyle wstępu teoretycznego wystarczy i pora przejść do bardziej technicznej działki, którą Tygryski lubią najbardziej 🙂

 

Sekwencja działania procesu DNS Discovery:

  1. System kliencki za pośrednictwem usługi Netlogon wysyła do zdefiniowanych w systemie serwerów DNS zapytanie dotyczące kontrolerów domeny w danej domenie Active Dirctory, której jest członkiem.

Zapytanie DNS (53 UDP) dotyczy rekordów SRV: _ldap._tcp.dc._msdcs.Nazwa.DomenyAD np.: _ldap._tcp.dc._msdcs.mkrzanowicz.pl

  1. Jeśli serwery DNS nie odpowiedzą, lub zwrócą brak rekordów SRV, to proces DC Locator kończy się błędem. Zakładamy jednak prawidłową konfigurację Active Directory oraz zintegrowanego DNS, zatem w odpowiedzi do klienta wraca lista rekordów SRV powiązanych z kontrolerami domeny.
  2. Klient DNS dokonuje przeglądu listy zwróconych rekordów SRV i wybiera ten, który ma najniższy priorytet. Jeśli jest kilka rekordów o takim samym priorytecie, to klient wybiera rekord w sposób pseudolosowy bazując na jego najwyższej wadze określającej najwyższe prawdopodobieństwo wyboru. Jeśli ktoś chce być bardziej dociekliwy to może przejrzeć dokumentację usługi DNS zdefiniowaną m.in. w: RFC 2782 oraz RFC 2052.
  3. Po ustaleniu rekordu SRV, klient odpytuje ponownie serwer DNS celem ustalenia adresu IP wybranego kontrolera domeny. (zapytanie o rekord DNS typu A)
  4. Serwer DNS odpowiada klientowi, zwracając w odpowiedzi adres IP kontrolera domeny.

 

Następnie Proces DC Locator zaczyna wykorzystywać protokół LDAP:

  1. Klient wysyła LDAP Ping (389 UDP) celem weryfikacji, czy zwrócony przez serwer DNS kontroler domeny prawidłowo obsługuje zapytania, jest dostępny etc. Ważna uwaga –  LDAP Ping jest wykonywany z wykorzystaniem protokołu UDP, więc jest to protokół bezpołączeniowy.
  2. Klient oczekuje na odpowiedź kontrolera domeny. W przypadku nie uzyskania odpowiedzi, powtarza proces LDAP Ping dla kolejnych kontrolerów domeny z uzyskanej wcześniej listy aż do odnalezienia działającego kontrolera domeny lub wyczerpania listy.

W tym miejscu zatrzymajmy się trochę dłużej przy kwestii LDAP Ping. Czytając archaiczne dokumentacje można na trafić na informację, że LDAP Ping kontrolerów domeny wykonywane są na porcie UDP 138. Takie zachowanie nie ma miejsca dla nowożytnych (wspieranych) systemów operacyjnych Windows, czyli co najmniej od Windows Server 2008). Zapytania realizowane są w normalny sposób wykorzystując LDAP na porcie 389 UDP.

LDAP Ping jest w rzeczywistości zapytaniem LDAP na poziomie rootDSE o atrybut „NetLogon”. Niestety manualne odpytanie o atrybut „Netlogon” się nie uda (nie zwróci odpowiedzi LDAP możliwej do dalszej „obróbki” bo takowego atrybutu nie ma w usłudze katalogowej a jest jedynie wykorzystywany do realizacji LDAP Ping), zgodnie z dokumentacją: https://msdn.microsoft.com/en-us/library/cc223811(v=prot.20).aspx

Natomiast samo zapytanie LDAP Ping ma postać Filtru LDAP

, gdzie DomainGuid to wartość z zapytania powershell:

Proces NetLogon na kontrolerze domeny weryfikuje adres IP klienta w bazie topologii Active Directory (powiązaniach podsieci z lokacjami Active Directory) poprzez odnalezienie podsieci, która jest najbliżej adresu IP klienta wykonującego zapytanie LDAP. Należy zwrócić uwagę na to, że weryfikowany jest adres IP klienta, nie zaś jego podsieć z punktu widzenia konfiguracji sieciowej klienta.  Kontroler domeny po przeprowadzeniu takiej inspekcji odpowiada z wykorzystaniem pakietu  NETLOGON_SAM_LOGON_RESPONSE_EX. Ten pakiet zawiera m.in.:

  • Nazwę Lokacji AD, w której znajduje się klient (lub nazwę najbliższej lokacji w stosunku do adresu IP klienta)
  • Nazwę Lokacji AD, w której zlokalizowany jest kontroler domeny odpowiadający na LDAP Ping
  • Wartość flagi DSClosestFlag, która określa, czy kontroler domeny znajduje się w najbliżej dla klienta Lokacji Active Directory.
  • Dodatkowe informacje o tym czy jest RODC, czy działa KDC, czy jest GlobalCatalogiem etc.

 

  1. Odpowiedź jest cache’owana na kliencie w pamięci podręcznej DC Locator’a. W przypadku gdy odpowiedz wskazuje na kontroler domeny poza Lokacją klienta, to proces LDAP Ping wykonywany jest do kolejnych kontrolerów domeny, przy czym tym razem klient posiadając już informację o swojej poprawnej Lokacji Active Directory wykorzystuje zapytanie DNS o rekordy SRV w danej Lokacji np.: _tcp.LokacjaAD.dc._msdcs.mkrzanowicz.pl
  2. Po skutecznym uzyskaniu informacji o kontrolerze domeny, klient cache’uje informacje o Lokacji Active Directory oraz najbliższym kontrolerze domeny.

Na tym etapie klient jest gotowy do normalnej pracy w domenie Active Directory, uwierzytelniania, autoryzacji itd.

Poniżej dla wzrokowców graficzna reprezentacja procesu DC Locator:

Istotne informacje odnośnie procesu DC Locator:

  • Długość cache`owania informacji DC Locator określa wpis w rejestrze: CloseSiteTimeout (domyślna wartość to 15 minut; minimalna wartość to 15 sekund a maksymalna to 49 dni)
  • W nowożytnych systemach (od Windows Server 2008) każdy klient AD powinien mieć przypisaną Lokację AD bazując na podsieciach/adresach IP. Jeśli się tak nie dzieje to jest przypisywany do Lokacji defaultowej tj: „Default-First-Site-Name”
  • Nazwa przypisanej Lokacji Active Directory znajduje się w rejestrze w ścieżce: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName
  • Dynamicznej nazwy Lokacji z powyższego punktu nie należy modyfikować (!). Jeśli jest potrzebne wymuszenie innej Lokacji, to należy skorzystać z klucza REG_SZ : HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\SiteName i jako wartość podać nazwę Lokacji.
  • Domyślnym interwałem, który służy do wykonywania ponownego odkrywania kontrolerów domeny jest 12 godzin. Najmniejszą wartością DWORD jest 0 (wtedy klienta za każdym razem wykonuje cały proces na nowo), najwyższą 4294967295. Zmian można dokonywać w kluczu rejestru: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ForceRediscoveryInterval
  • Czyszczenie cache DC Locator: NLTest /dsgetdc:<Domain Name> /Force
  • Informacje o topologii Lokacji Active Directory (wraz z adresacją IP przypisaną do lokacji) utrzymywane są w partycji konfiguracji, z której dane replikowane są pomiędzy wszystkimi kontrolerami w lesie Active Directory, dzięki czemu zachowana jest spójność danych.
  • Czas oczekiwania klienta na odpowiedź LDAP Ping zależy od ilości wysłanych wcześniej pakietów. Do 5 pierwszych prób czas oczekiwania wynosi 0,4 sekundy, do kolejnych 5 wynosi już 0,2 sekundy a 11 i kolejne LDAP Pingi oczekują na odpowiedź już tylko 0,1 sekundy.

 

Tym mocno technicznym artykułem chciałbym powrócić do rozpoczętego kilka lat temu cyklu dotyczącego podstaw architektury i działania usług katalogowych Active Directory.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *