Synchronizacja czasu Active Directory

12 stycznia 2015 at 09:16

Synchronizacja czasu w lesie Active Directory jest jednym z najistotniejszych zagadnień wymagających zrozumienia i prawidłowego utrzymywania w celu zapewnienia poprawnego jej funkcjonowania. Od synchronizacji czasu zależy pośrednio między innymi możliwość poprawnego uwierzytelniania w domenie, więc de-synchronizacja czasu skutkuje naprawdę dużymi problemami…

Często można się spotkać z pytaniami „po co synchronizacja czasu w domenie, skoro są zewnętrzne serwery NTP?”, „czemu pojawiają się problemy przy różnicach w czasie?” albo „po co się rozwodzić nad tematem skoro jest dostępny kontroler domeny utrzymujący rolę PDC, którą zawsze można przejąć?”. Aby znaleźć na nie odpowiedzi zacznijmy od przyczyny, dla której czas jest tak ważny w Active Directory. Otóż domyślnym protokołem uwierzytelniania w środowisku Active Directory jest Kerberos, który w procesie uwierzytelniania wykorzystuje znaczniki czasowe, które następnie są weryfikowane. Domyślnie maksymalna tolerancja różnicy czasowej, z którą taki pakiet uznany będzie za prawidłowy wynosi 5 minut. Jeśli różnica będzie większa, to pojawiają się poważne problemy… Warto nadmienić także, że Microsoft oficjalnie nie gwarantuje perfekcyjnej dokładności usługi czasu w swoich systemach operacyjnych, jednak niedokładność na poziomie kilku sekund jest w zupełności wystarczająca na potrzeby poprawnego działania uwierzytelniania z wykorzystaniem protokołu Kerberos.

Jak działa sama synchronizacja czasu w lesie Active Directory? Trywialna odpowiedź brzmiałaby „w oparciu o rolę emulatora PDC”. Jednak my nie chcemy poprzestawać na trywialnych odpowiedziach, bo zależy nam na zgłębieniu tematu pozwalającym na jego zrozumienie i łatwe rozpoznanie miejsc, gdzie mogą pojawić się w przyszłości problemy.

Jako reprezentatywny przykład wybierzmy sobie przykładowy las z dwoma domenami – Rys.1.

Rys.1. Hierarchiczna synchronizacja czasu w środowisku Active Directory.

Rys.1. Hierarchiczna synchronizacja czasu w środowisku Active Directory.

Synchronizacja czasu działa w sposób hierarchiczny, jednak należy tą hierarchię prawidłowo rozumieć i tak idąc od samego dołu:

  • Klient w domenie 1 synchronizuje swój czas z kontrolerem domeny, który go uwierzytelnia. Może więc synchronizować czas z dowolnym kontrolerem domeny w swojej domenie.
  • Dowolny kontroler domeny w domenie 1 oraz domenie 2 nie pełniący roli emulatora PDC w danej domenie synchronizuje swój czas z emulatorem PDC w swojej domenie. Może również synchronizować swój czas z dowolnym kontrolerem domeny w domenie głównej lasu Active Directory.
  • Dowolny kontroler domeny w domenie głównej lasu Active Directory synchronizuje swój czas z kontrolerem domeny pełniącym rolę emulatora PDC w tejże domenie.
  • Emulator PDC w domenie głównej lasu Active Directory jest więc wiarygodnym źródłem czasu dla całego lasu. Można go natomiast synchronizować również z zewnętrznymi serwerami czasu NTP. W przeciwnym wypadku czas pobierany jest bezpośrednio z CMOS.

Co do zasady widzimy już hierarchię synchronizacji czasu. Wyróżnić w niej można dwa zasadnicze procesy tj:

  1. Określanie źródła czasu przez klienta – odbywa się ono w obrębie domeny, do której należy dany klient. Synchronizacja odbywa się w oparciu o kontroler domeny, na którym nastąpiło uwierzytelnienie.
  2. Określanie źródła czasu przez kontroler domeny – kontroler domeny w celu określenia hierarchii synchronizacji czasu wykonuje maksymalnie 6 zapytań mających na celu zlokalizowanie wiarygodnego źródła czasu w hierarchii. Każde z zapytań jest skonstruowane w celu ustalenia innych parametrów, takich jak określenie lokacji kontrolera, pełnionych przez niego roli, czy weryfikacja wiarygodności jego czasu.

Zapytania wykonywane przez kontroler domeny mające na celu ustalenie źródła czasu:

  1. Lokalizacja kontrolerów domeny w domenie nadrzędnej, w obrębie danej lokacji. – Preferowane jest wiarygodne źródło czasu, jednak w przypadku niedostępności synchronizacja odbywa się również w oparciu o „niewiarygodne” źródła czasu, czyli kontrolery domeny nie pełniące roli emulatora PDC w domenie nadrzędnej.
  2. Lokalizacja kontrolerów domeny w danej domenie, w obrębie danej lokacji – synchronizacja tylko z wiarygodnym źródłem czasu
  3. Lokalizacja emulatora PDC w danej domenie, w obrębie danej lokacji – To zapytanie nie jest wykonywane przez kontroler domeny pełniący rolę emulatora PDC, ponieważ synchronizacja czasu w domenie nigdy nie odbywa się w oparciu o lokalny czas maszyny.
  4. Lokalizacja kontrolerów domeny w domenie nadrzędnej, poza daną lokacją. – Preferowane jest wiarygodne źródło czasu, jednak w przypadku niedostępności synchronizacja odbywa się również w oparciu o „niewiarygodne” źródła czasu, czyli kontrolery domeny nie pełniące roli emulatora PDC w domenie nadrzędnej.
  5. Lokalizacja kontrolerów domeny w danej domenie, poza daną lokacją – synchronizacja tylko z wiarygodnym źródłem czasu
  6. Lokalizacja emulatora PDC w danej domenie, poza daną lokacją – To zapytanie nie jest wykonywane przez kontroler domeny pełniący rolę emulatora PDC, ponieważ synchronizacja czasu w domenie nigdy nie odbywa się w oparciu o lokalny czas maszyny.

 

W wyniku każdego z powyższych zapytań zwracana jest lista kontrolerów domeny mogących zostać wykorzystanych jako wiarygodne źródła czasu. Usługa czasu Windows przydziela każdemu ze zwróconych w odpowiedzi kontrolerów domeny noty wynikające z ich wiarygodności oraz lokalizacji. Noty te prezentują się następująco:

  • 8 – kontroler domeny w tej samej lokacji
  • 4 – kontroler domeny oznaczony jako „wiarygodny”
  • 2 – kontroler domeny w domenie nadrzędnej
  • 1 – Kontroler domeny pełniący funkcję emulatora PDC

Przy końcowym wyborze noty są sumowane. Najwyższa nota oznacza kontroler domeny z którym nastąpi synchronizacja czasu. Jeżeli w trakcie wykonywania kolejnych zapytań zostanie osiągnięta maksymalna nota, to następne w kolejności nie są już wykonywane. Zamiast tego dokonywana jest synchronizacja z najlepszym możliwym kontrolerem domeny.

Jak więc posiadając wiedzę teoretyczną na temat działania usługi synchronizacji czasu w środowisku Active Directory przekuć ją w praktykę? W wersji najprostszej dla wszystkich członków domeny, oprócz serwera pełniącego rolę emulatora PDC w domenie głównej lasu Active Directory skonfigurować obiekt zasad grup (GPO) zawierający regułę:

Computer Configuration\Policies\Administration Templates\System\Windows Time Service\Time Providers\Configure Windows NTP Client, w której Wartość parametru „NtpServer” pozostanie pusta, natomiast wartość parametru „NTP” zostanie ustawiona jako „NT5DS”.

Z kolei dla emulatora PDC w domenie nadrzędnej skonfigurować ustawienia „NtpServer” podając adresy IP zewnętrznych serwerów czasu NTP, natomiast „Typ” jako „NTP”.

(Więcej o sposobach określania celów zasad grup: http://mkrzanowicz.pl/?p=72 )

W celu weryfikacji ostawień systemu należy odczytać właściwości kluczy rejestru:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters\Type  (NT5DS bądź NTP)

oraz:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters\NtpServer (Adresy IP serwerów NTP bądź time.windows.com,0x9)

Powyższe zapewni prawidłowe działanie usługi synchronizacji czasu domenowego jednak implikuje szereg problemów w przypadku konieczności przeniesienia emulatora PDC w domenie głównej na inny kontroler domeny. Jeśli wydarzy się awaria, mało kto będzie pamiętać o tym, że podczas przenoszenia PDC musi zmienić wykluczenie w stosownym GPO oraz zmienić konfigurację usługi czasu na nowym emulatorze PDC tak, by korzystała z zewnętrznego serwera NTP. Można tego jednak łatwo uniknąć i niejako przewidzieć takową sytuację już na etapie planowania usług katalogowych Active Directory. Metody są co najmniej dwie:

 

  • Zbudowanie lasu Active Directory w taki sposób, że w domenie głównej lasu utrzymywane są jedynie kontrolery domeny. Nie są w niej tworzone żadne zbędne obiekty, nie są do niej przyłączane bezpośrednio serwery ani stacje klienckie – główna domena jest utrzymywana niejako pusta. Wszystkie kontrolery domeny w domenie głównej są skonfigurowane jako wiarygodne źródła czasu pobierające czas z zewnętrznych serwerów NTP. Pozwala to w przypadku problemów z kontrolerem domeny utrzymującym obecnie rolę emulatora PDC po prostu przenieść tę rolę na inny kontroler domeny w domenie głównej lasu o uniknąć późniejszych problemów z synchronizacją czasu.

To rozwiązanie jest bez wątpienia bardzo wygodne oraz zapewnia możliwie wysoką niezawodność synchronizacji czasu w środowisku Active Directory. Jest jedna stosunkowo drogie z racji utrzymywania mało produktywnych serwerów pełniących rolę kontrolerów domeny w domenie głównej lasu.

  • Zapewnienie emulatora PDC w domenie głównej lasu Active Directory działającego w trybie „Stand-By”. Każdy administrator domeny powinien mieć dobrze przemyślany plan awaryjny oraz przynamniej wstępnie wybrany kontroler domeny, który w przypadku awarii przejmie rolę emulatora PDC. Wychodząc kilka kroków do przodu można taki wybrany wcześniej serwer skonfigurować jako wiarygodne źródło czasu korzystające z zewnętrznych serwerów NTP. W przypadku awarii obecnego emulatora PDC wystarczy również przejąć rolę emulatora i nie martwić się problemami związanymi z czasem domenowym.

To rozwiązanie z kolei jest znacznie tańsze i efektywniejsze kosztowo, bo wszystkie kontrolery domeny są w pełni wykorzystywane. Problem pojawi się w przypadku, jeśli nie będzie można skorzystać z wybranego wcześniej „zapasowego PDC”… W niektórych środowiskach nie można/nie chcemy korzystać z części kontrolerów domeny do pełnienia ról FSMO i wtedy pojawia się problem.

*W obu przypadkach należy pamiętać o wykluczeniu stosownych kontrolerów domeny z GPO aplikującego na staje członkowskie ustawień czasu NT5DS.

Tym samym zachęcam do stworzenia własnego przemyślanego planu działania w przypadku awarii kontrolerów domeny i zorganizowania sobie pracy w sposób zapewniający minimalną ilość czynności do wykonania w przypadku wystąpienia takiej awarii. Zyskasz na czasie w momencie usuwania awarii i unikniesz problemów z czasem domenowym w przyszłości.