W tym rozdziale omówione zostały:
· Dynamiczny DNS (DDNS). Krótki przegląd nowej funkcji dynamicznych aktualizacji DNS-u, z punktu widzenia administratora Windows i DNS. Omówiono tutaj ogólnie wiążące się ze sobą kwestie bezpieczeństwa i porządkowania pliku strefy, oraz szczegółowo — oczyszczania (scavenging) w Windows 2000.
· Integracja stref DNS z Active Directory. Dotyczy wykorzystania Active Directory w roli magazynu danych strefy DNS, powody dla których funkcja ta została udostępniona, jej możliwości i czynniki które należy rozważyć podejmując decyzję, czy skorzystać z tej, opcjonalnej, funkcji. Uzyskane w ten sposób bezpieczeństwo dynamicznych aktualizacji zostało opisane szczegółowo.
· Zależność Active Directory od rekordów usług (SRV). Daje wgląd w wykorzystanie rekordów SRV w środowisku domen Windows 2000. Ze wszystkich nowych możliwości DNS udostępnionych w Windows 2000, z tej trzeba koniecznie skorzystać na potrzeby Active Directory.
· Łączyć Active Directory i DNS czy nie. Zgromadzono tu szereg czynników, o których trzeba wiedzieć podejmując świadomą decyzję o skorzystaniu z tej technologii.
Active Directory w Windows 2000 implementuje usługi katalogowe LDAP (Lightweight Directory Access Protocol). Jednakże odrobina historii powinna przydać się, aby wyjaśnić co to dokładnie oznacza. Oryginalna specyfikacja standardu usług katalogowych X.500 marniała bez pełnej komercjalnej implementacji z szeregu powodów. Jeden z nich — fakt, iż jest to nader dogłębnie rozbudowana specyfikacja — doprowadził do zaimplementowania jej podzbiorów. Z tych wysiłków powstał LDAP.
Chociaż charakter LDAP wciąż ulega zmianom, w Windows 2000 [poprawiony] został fakt, iż istniejące implementacje LDAP zazwyczaj nie zawierały usługi lokalizatora na globalną skalę, w takim sensie, w jakim jest nią DNS. Pierwotnym pomysłem w X.500 było stworzenie takiej właśnie funkcjonalności, dającej możliwość znajdowania struktur katalogowych a następnie nawigowania w ich obrębie. Jak dotąd jednakże, implementacje LDAP koncentrowały się raczej na pracy ze strukturami katalogowymi a nie ich znajdowaniu.
Konstrukcja Active Directory zwiększa istniejące możliwości lokalizacyjne DNS-u, co zostało osiągnięte przez ścisłe dopasowanie przestrzeni nazw Active Directory i DNS. W efekcie najwyższe poziomy obiektów Active Directory sprawiają wrażenie nazw domen DNS. Są też w istocie nimi dokładnie, ponieważ obiekty kontrolerów domen (DC) wykorzystane tutaj reprezentują granice domen Windows 2000 i w pierwszym wydaniu Windows 2000 mają być nazywane zgodnie z identycznie rozłożonymi domenami i poddomenami DNS.
Niesie to za sobą wiele implikacji. W rozdziale niniejszym przedstawiono niektóre możliwości, współzależności i wrażliwe punkty będące skutkami takiej konstrukcji oraz faktu korzystania z niektórych najnowszych funkcji DNS-u do obsługi tejże konstrukcji.
Poświęcony DDNS-owi dokument RFC 2136 omawia szczegóły operacji aktualizacji (Update), definiując nowy kod operacji dla DNS-u, oraz format komunikatu którego może użyć klient DNS żądając dokonania zmian w domenach DNS. Jak już widzieliśmy, dane domeny muszą pochodzić z serwera podstawowego domeny, wobec czego DDNS ustala, iż żądanie aktualizacji odebrane przez serwer wtórny powinno być przesłane do głównego serwera podstawowego w celu przetworzenia. Jeśli czytelnikowi wydaje się, że brzmi to łatwo, prosto i przyjemnie, radzimy zaczekać chwilę: pojawi się znacznie więcej czynników. Sama operacja aktualizacji Update jest bardzo prosta i oczywista, lecz jej implikacje stają się zawiłe.
Za pomocą dynamicznej aktualizacji klient, znajdując serwer nazw z pełnomocnictwami (pytając o rekordy serwerów nazw NS) w domenie, może obwieścić swoją obecność żądając zarejestrowania rekordu adresu A i ewentualnie wskaźnika PTR. Klient Windows 2000 w istocie pyta o rekord początku pełnomocnictwa SOA a nie NS, rejestrując następnie dane w serwerze podstawowym domeny. Po wykonaniu tej operacji przez komputer, jego nazwę daje się rozwiązać, ewentualnie zweryfikować według adresu IP, tak jak w przypadku ręcznego wpisania rekordów zasobów.
Gdyby ten proces był bezbolesny, każdy administrator DNS cieszyłby się z niego jak dziecko z nowego roweru. Jak nam wszystkim jednak wiadomo, bardzo niewiele nowości daje duże zyski bez kosztów lub ryzyka. W przeciwnym razie zrobiono by to już dawno temu.
Możliwość dynamicznej aktualizacji DNS-u została wyspecyfikowana w RFC 2136, który to dokument wprowadza komunikat Update (Aktualizuj) do języka DNS-u. Korzystając z formatu komunikatu Update, klienci mogą dodawać i usuwać rekordy zasobów, lub testować i potwierdzać warunki wstępne.
Dokument RFC szczegółowo opisuje korzystanie z zestawów RR — na przykład, zestawów rekordów z tymi samymi nazwami, jak wiele rekordów A dla WWW w domenie DNS-owej. Aktualizacje mogą dotyczyć pojedynczego rekordu, zestawu lub zestawów rekordów zasobów. Przez aktualizację dynamiczną można dodać rekord, usunąć rekord lub zestaw rekordów.
Można dokonywać testów spełnienia pewnych kryteriów — na przykład, czy nie istnieje rekord A dla fs2.hq.example.net. Testy takie mogą sprawdzać warunki wstępne niezbędne do przetworzenia żądania aktualizacji, lub jedynie dokonywać potwierdzeń bez podjęcia dalszych działań. Potwierdzenia, korzystające z możliwości wysłania komunikatu Update zawierającego test bez zależnych od niego aktualizacji, pozwalają w prosty sposób sprawdzić w bazie danych DNS obecność lub brak rekordów i ich zasobów.
Serwer DNS powiadamia klienta o wyniku testu potwierdzenia lub aktualizacji. Jeśli warunki wstępne są spełnione i wiąże się z nimi dokonanie aktualizacji, serwer DNS dokonuje tychże aktualizacji. W takim przypadku, aktualizacja wykonywana jest w trybie “wszystko albo nic” — to znaczy, jest ona niepodzielna.
Komunikaty aktualizacji nie ograniczają się do żądania prostego dodania lub usunięcia pojedynczych rekordów. Żądanie aktualizacji może usuwać całe zestawy rekordów. Z powodu ograniczeń w stosowaniu znaków uniwersalnych (wildcards), aktualizacje muszą być dość precyzyjnie formułowane.
RFC 2136 [zapewnia] wymuszenie w procesie aktualizacji poziomu bezpieczeństwa zależnego od implementacji, lub w normie bazującej na RFC, lecz nie definiuje mechanizmów zapewnienia bezpieczeństwa. RFC 2137 przedstawia pierwszą specyfikację bezpiecznej aktualizacji dynamicznej DNS (Secure DNS Dynamic Update). Zabezpieczenia aktualizacji dynamicznych były odtąd w ciągłym rozwoju i obecnie większość standardowych według RFC metod wymaga wsparcia ze strony infrastruktury kluczy publicznych. W pierwszym wydaniu Windows 2000 zaimplementowano metodę zabezpieczeń korzystającą z Kerberosa (co omówione będzie w dalszej części rozdziału).
Przed chwilą zostało stwierdzone, iż klienci Windows 2000 odwołują się bezpośrednio do podstawowego serwera DNS w celu aktualizacji DNS-u, co jest sensowne — gdyż wszelkie zmiany danych domeny muszą być dokonywane w serwerze posiadającym początek pełnomocnictwa (SOA). Domyślne ustawienia klienta w pierwszym wydaniu Windows 2000 każą klientom skonfigurowanym do korzystania z DDNS-u próbować odświeżania swoich wpisów w DNS-ie co 24 godziny.
Jak zostanie wyjaśnione w dalszych podrozdziałach, niepotrzebne aktualizacje powodują obciążenie zasobów, bez którego cały system miałby się lepiej. Wobec tego, klienci Windows 2000 w rzeczywistości zachowują się bardziej inteligentnie niż sugerowaliśmy dotychczas. Podczas rejestracji, w pierwszej kolejności wysyłają tylko potwierdzający komunikat aktualizacji, sprawdzając czy wiadomości posiadane przez DNS są poprawne z punktu widzenia klienta. Jeśli tak, aktualizacja nie jest dokonywana. Jeśli klient potrzebuje dokonać aktualizacji, w przypadku niepowodzenia rejestracji sprawdza inne serwery podstawowe mogące istnieć gdy strefa jest zintegrowana z Active Directory.
Przy dalszym braku powodzenia, klient powtarza proces po odczekaniu 5, a następnie 10 minut. Jeśli w dalszym ciągu brak sukcesu, przed kolejną próbą odczekuje 50 minut. Komputer działający pod systemem Windows 2000 i skonfigurowany do dynamicznej aktualizacji DNS-u z uporem będzie starał się powiadomić o swojej obecności.
W rozdziale 15 – “Usługi DHCP w Windows” opisano zdolność serwera DHCP Windows 2000 do rejestracji w imieniu klienta. Może być to zrobione na różne sposoby, lecz domyślnie klient Windows 2000 modyfikuje rekordy A, zaś serwer DHCP (Dynamic Host Configuration Protocol – protokół dynamicznej konfiguracji hosta) rekord PTR. Serwer DHCP w Windows NT nie posiada tej zdolności. DHCP można skonfigurować tak, aby obsługiwał oba typy rekordów, oraz aby rejestrował klientów innych niż Windows 2000. Wszystkie te możliwości zaczynają grać rolę przy bezpieczeństwie aktualizacji oraz czyszczeniu wpisów, o czym później.
Jeśli DDNS jest w stanie odciążyć administratora DNS-u od harówki z utrzymaniem pliku strefy i został zdefiniowany przez RFC już w kwietniu 1997, dlaczego jak dotąd jest tak mało używany? Albo, patrząc z innej strony, o czym trzeba pamiętać przed wejściem do klubu?
Odpowiedzią na powyższe pytanie, w jednym słowie, jest bezpieczeństwo. Wiele odmian ataków przez podszywanie się (spoofing) i przechwytywanie (hijack) staje się trywialnie proste jeśli ktokolwiek może zarejestrować — na przykład, rekord A dla www.example.net lub, jeszcze bardziej bezczelnie, serwer nazw ns.example.net. Bez pewnego poziomu kontroli nad tym kto, lub jaki komputer, ma prawo aktualizować rekordy, DDNS jest podobny do sportów ekstremalnych – tylko dla odważnych.
Microsoft podszedł do problemu zabezpieczenia procesu dynamicznej aktualizacji poprzez integrację stref z Active Directory. Charakter tej integracji stanowi temat następnego dużego podrozdziału w tym rozdziale.
Po umożliwieniu dynamicznych aktualizacji strefy można zauważyć, że zaczną pojawiać się nowe rekordy usług (SRV). Active Directory potrzebuje tych rekordów SRV do lokalizowania swoich najważniejszych usług. Na przykład, oczekuje się, że usługi będą w przyszłości rejestrować odpowiadające im rekordy _http._tcp, _ftp._tcp. Może stanowić to problem dla środowiska, więc proszę pamiętać, że system Windows 2000 “z pudełka” jest w pełni przygotowany do korzystania z rekordów SRV do granic możliwości.
Drugą stroną medalu bezpiecznych aktualizacji są konflikty aktualizacji i czystość strefy. W przypadku odrzucenia rejestracji, łącznie z usuwaniem zapisów które powinno w rzeczywistości być dozwolone, istnieje możliwość osierocenia rekordów. Jeśli na przykład klient nie usunie rekordów które zarejestrował wówczas, gdy miał na to zezwolenie, a następnie mechanizmy zabezpieczeń odbiorą mu to prawo, kto kiedykolwiek usunie takie rekordy?
Załóżmy, że zaimplementowany serwer DNS odrzuca aktualizację polegającą na rejestracji nazwy przez rekord A, jeśli nazwa lub związany z nią adres IP już istnieje w domenie. Następnie rozważmy doświadczenie klienta DHCP który usiłuje zarejestrować nazwę już obecną, lub gdy inna nazwa będzie odpowiadała adresowi IP, który klient chciał będzie zarejestrować.
To jedynie dwa z teoretycznych przykładów problemów powodowanych przez przedawnione rekordy. Jeśli proces aktualizacji nie posiada zabezpieczeń, problemy te znikają. Próba aktualizacji przez klienta jest wtedy zawsze pomyślna. Klient mógłby wtedy wykonywać zapytania i aktualizacje aby usuwać rekordy powodujące konflikty i prawdopodobnie stare, aby zapewnić poprawne działanie.
Oczywistym wyborem dokonanym przez społeczność DNS-ową było bezpieczeństwo kosztem czystości. Lecz problem z przedawnionymi rekordami może działać jak klej unieruchamiający funkcjonowanie całej maszyny.
W domyślnej implementacji Windows 2000 usuwanie rekordów jest dozwolone dla administratorów i klienta który pierwotnie dodał rekord. Wobec tego, jeśli klient rejestrujący rekord porzuci go, rekord ten pozostaje w bazie danych DNS dopóki nie podejmie się innych działań mających na celu oczyszczenie bazy. Jest to jedna z zachęt do korzystania z DHCP w celu rejestracji: odpowiedzialność za czystość przeniesiona zostaje na bardziej odpowiedzialnie zachowujący się serwer DHCP. W końcu klienci mogą zmieniać swoje zachowanie i często to czynią.
Korzystanie z DDNS-u ma nowy wpływ na zachowanie strefy. Pozwala również na nowe metody osiągania celów. Na przykład, rejestracja klientów DHCP w rekordach DNS-u zapewnia opartą o standardy metodę, zastępującą starszą integrację DNS-u z usługą WINS. Inny przykład: DDNS w połączeniu z typem rekordu SRV daje możliwości powiadamiania o usługach, dostępnego jak dotąd w systemach Windows jedynie poprzez nazwy NetBIOS.
Strefa dynamiczna podlega, przynajmniej w teorii, ciągłym zmianom. Nie tylko obciąża to mechanizm transferu stref, lecz również tworzy pewne nowe problemy. Jak transfer strefy może dostarczyć spójnej kopii strefy? W jaki sposób administrator ma dokonać ręcznej edycji strefy a następnie załadować ją, jeżeli nie jest w stanie przewidzieć jej numeru seryjnego wersji? Można tu powiedzieć: “Ale po co ręczna edycja? DDNS miał uwolnić nas od tych metod masowych zmian.” No cóż, w porządku. Ale co z czyszczeniem strefy?
Windows 2000 próbuje uprzedzać tego typu problemy. Serwer DNS blokuje możliwość zmiany strefy podczas jej transferu. Jednak dla transferów pierwszą linią obrony jest stosowanie opcji powiadamiania (Notify) wraz z transferami przyrostowymi (IXFR). Kolejną metodą jest projektowanie stref ze zwracaniem uwagi na ich rozmiar, tak aby zachodzące pełne transfery trwały najkrócej jak to możliwe (z powodu wspomnianego blokowania zmian). Dziennik zdarzeń zmian serwera DNS ma ograniczoną długość, wobec czego niektóre żądania transferu przyrostowego IXFR mogą powodować transfer pełny (AXFR), gdy żądane zmiany przyrostowe przekroczą swą ilością te zarejestrowane w dzienniku. Strefy zintegrowane z Active Directory unikają tego potencjalnego problemu w wymianie danych między serwerami podstawowymi, lecz nie przy transferach do serwerów wtórnych.
Jeśli chodzi o nowe troski administratorów, zacząć należałoby od poznania możliwości nowych narzędzi dostarczanych z Windows 2000.Szczególnie warto zaznajomić się z DNSCMD.EXE (patrz rozdział 12 – “Narzędzia i programy użytkowe do rozwiązywania problemów ” oraz rozdział 13 – “Najważniejsze wskazówki
“Best practices” w terminologii MS
i konserwacja systemu”). Obiekt DNS w Monitorze systemu zawiera szereg nowych liczników które należy obserwować (patrz rozdział 11 – “Konfigurowanie serwerów DNS w systemie Windows ”); liczniki te pozwolą na zorientowanie się jak dobrze działają funkcje dynamicznej aktualizacji. Natomiast w samym interfejsie zarządzania DNS-em znajduje się funkcja rejestracji [zdarzeń
Tu i poniżej w nawiasach [] umieściłem uzupełnienia zdań których nie ma w oryginale
], pozwalająca na zagłębienie się w szczegóły gdy dysponuje się wolnym czasem i mocami przerobowymi.
Windows 2000 stosuje funkcje oczyszczania (ang. scavenging) do walki z tendencją stref dynamicznych do zaśmiecania się. Bez integracji z Active Directory nie istnieją w Windows 2000 żadne zabezpieczenia aktualizacji przez DDNS. Integracja z Active Directory umożliwia bezpieczne aktualizacje, co z kolei tworzy potrzebę czyszczenia [strefy]. Podrozdział zatytułowany “Integracja stref DNS z Active Directory” w dalszej części tego rozdziału omawia funkcje zabezpieczeń. Niniejszy podrozdział zajmuje się funkcją oczyszczania zaimplementowaną w celu kontroli wyników [działania zabezpieczeń].
Strategia oczyszczania w Windows 2000 nie jest najłatwiejszym do zrozumienia tematem. Jednakże funkcję tę należy koniecznie dobrze zrozumieć przed użyciem. Rozsądnie jest powstrzymać się od aktywacji oczyszczania aż do dobrego zrozumienia jej zachowań i wyników działania w konkretnej konfiguracji serwera.
Oczyszczanie może usuwać przestarzałe rekordy (ang. stale records), niezależnie od tego czy zostały dodane automatycznie czy ręcznie, zgodnie z harmonogramem dostrajania systemu. Usuwany rekord może być rzeczywiście przestarzały albo niezbędnie potrzebny, liczy się tylko czy spełnia warunki klasyfikujące go jako przestarzały. Proszę wiedzieć co się zamierza zrobić przed rzeczywistym zrobieniem tego. Usunięcie ważnych rekordów oczywiście spowoduje problemy. Po usunięciu rekordu, usługa aktualizacji dynamicznej pozwala zarejestrować ten rekord dowolnemu komputerowi, co może spowodować jego uzurpację.
Oczyszczanie działa przez usuwanie nieaktualnych rekordów, zgodnie z datą ich ostatniego odświeżania. Odświeżanie powodowane jest przez żądanie aktualizacji ze strony DDNS-u, w którym nie wyspecyfikowano żadnych zmian w rekordzie w porównaniu z istniejącym. Oznacza to, że statycznie wprowadzone rekordy mogą zostać usunięte w procesie oczyszczania, ponieważ nie są odświeżane. Jak uprzednio wspomniano, Windows 2000 skonfigurowane do korzystania z dynamicznych aktualizacji DNS-u dokonuje prób odświeżania w interwałach 24-godzinnych.
Oczyszczanie można aktywować dla podstawowych stref niezależnie od tego, czy są typu standardowego czy zintegrowane z Active Directory. W przypadku aktywacji oczyszczania niezbędna jest metoda śledzenia, kiedy ostatnio rekord był odświeżany. Jeśli strefa zintegrowana jest z Active Directory, do przechowywania znacznika czasu służą atrybuty obiektów zawierających rekordy zasobów. W przypadku standardowej strefy, format pliku strefy jest modyfikowany tak, aby można było w nim korzystać ze znacznika czasowego. Znacznik czasu (datownik) aktualizowany jest przy modyfikacji lub odświeżeniu rekordu. Znacznik ten jest usuwany z odpowiedzi i transferów DNS-u, tak że zmiana zawartości rekordu zasobu jest modyfikacją wewnętrzną w serwerze DNS. Różnicę tę brać trzeba jednak pod uwagę podczas ręcznej edycji lub przenoszenia pliku strefy.Rekordy dodane do strefy standardowej przy nie aktywowanym oczyszczaniu nie zawierają znacznika czasu. W efekcie rekordy te nie podlegają oczyszczaniu, nawet po przeniesieniu zawierającej je strefy do Active Directory i aktywacji oczyszczania. Narzędzie DNSCMD.EXE umożliwia nadanie znacznika czasowego takim rekordom.
Oczyszczanie działa z wykorzystaniem szeregu parametrów przedziałów czasowych. Dwa z nich na poziomie serwera posiadają domyślną wartość równą siedmiu dniom. Proszę zauważyć, że również domyślny okres dzierżawy DHCP wynosi siedem dni, co nie jest zbiegiem okoliczności. Istnieją również dwa interwały na poziomie strefy, a wartości z poziomu serwera stosowane są jako dla ustawień na poziomie strefy jako domyślne.
Ustawienia na poziomie serwera dostępne są przez wybór Ustaw przedawnienie/oczyszczanie
Tu i dalej: bezpośrednie cytaty z W2K SP1 Pl
dla wszystkich stref z menu podręcznego serwera lub menu Akcja. Na poziomie strefy można je znaleźć za pomocą przycisku Przedawnienie na zakładce Ogólne właściwości strefy. Rozdział 11 opisuje znajdowanie tych menu i dostępne opcje. Rysunek 7.1 przedstawia dialog Właściwości przedawnienia/oczyszczania strefy dla ustawień na poziomie strefy. Dialog na poziomie serwera nazwany jest Właściwości przedawnienia/oczyszczania serwera i poza brakiem daty i czasu oczyszczania jest identyczny.
Interwały te są następujące:
§ Interwał braku odświeżania. Ustawia czas przez jaki żądania odświeżenia rekordu zasobu są odrzucane. Rekord może być aktualizowany, lecz aktualizacja bez dokonania zmian (odświeżenie) nie jest wykonywana. Zakaz ten działa jak ogranicznik dla zbędnej pracy która w przeciwnym razie zostałaby poświęcona na replikację danych strefy, ponadto uniezależnia redukcję tych kosztów administracyjnych od zachowań klientów. Obniżenie tej wartości miałoby ujemny wpływ na obciążenie serwera transferami stref i replikacjami Active Directory.
Rys. 7.1 Ustawienia oczyszczania (scavenging) w oknie dialogowym Właściwości strefy
§ Interwał odświeżania. Ustawia okres czasu następujący po interwale braku odświeżania, podczas którego możliwe jest odświeżanie rekordów, lecz nie są one przeszukiwane w celu oczyszczania. Rekord może zostać odświeżony w dowolnym czasie po wykazaniu przez znacznik czasu iż jest starszy od interwału braku odświeżania. Gdy według znacznika czasu rekord staje się starczy niż suma dwóch powyższych interwałów, rekord zostaje udostępniony do oczyszczania.
W momencie aktualizacji lub odświeżenia rekord otrzymuje nowy znacznik czasu. W strefach, w których aktywowano oczyszczanie rekordów nie utworzonych przez aktualizację dynamiczną (to znaczy, tworzonych ręcznie), jak się wydaje nie są stosowane znaczniku czasu, chociaż zgodnie z dokumentacją Microsoftu stosuje się znaczniki równe zero. Algorytm oczyszczania pomija rekordy zasobów za znacznikiem czasu równym zero. Jest jednak dostępne we właściwościach indywidualnych rekordów zasobów pole wyboru Usuń ten rekord, kiedy się zestarzeje, które może posłużyć do aktywacji oczyszczania dla tych rekordów.
Oczyszczanie nie zachodzi nigdy przed upłynięciem okresu łaski. Jest to dodatek do logiki interwałów. Strefa musi być w sposób ciągły dostępna dla aktualizacji dynamicznych przez czas równy interwałowi odświeżania, zanim można będzie rozpocząć odświeżanie. Zapewnia to klientom pełną szansę odświeżenia rekordów przed oczyszczaniem. Oczyszczanie uruchamiane może być zgodnie z harmonogramem przez wybór zakładki Zaawansowane we właściwościach serwera (patrz dolna część rysunku 11.4), lub ręcznie z menu podręcznego serwera.
Jeśli oczyszczanie aktywowane jest na poziomie serwera, wtedy wykonywane jest w pewien czas po upływie okresu łaski. Oczyszczanie wykonywane jest w strefach w których aktywowano zarówno samo oczyszczanie jak aktualizacje dynamiczne. W obrębie takich stref rekordy podlegające starzeniu i posiadające niezerowy znacznik czasu wskazujący, że rekord nie był ostatni w odpowiednim czasie odświeżony mogą zostać usunięte w procesie oczyszczania.
Słuchanie marketingowych “ewangelistów” może doprowadzić do uwierzenia, że Active Directory jest leczącym wszystko eliksirem, przynoszącym wszędzie samo dobro. Być może taki sposób myślenia — lecz , co bardziej prawdopodobne, czas w którym wydarzenia zachodziły — był źródłem strategii zabezpieczania dynamicznych aktualizacji w Windows 2000. Specyfikacja bezpiecznej aktualizacji dynamicznej DNS-u (RFC 2137) powstała w tym samym czasie co specyfikacja aktualizacji dynamicznej. Lecz badania szły naprzód i dalsze wysiłki rozjaśniają, w jaki sposób kodowanie kluczem publicznym może być stosowane w DNS-ie. Tak czy owak, Microsoft do zabezpieczania dynamicznych zachowań DNS-u wybrał technikę wykorzystującą wkład pracy w Active Directory. Można tu zajrzeć do dodatku B – “Dokumenty RFC związane z usługą DNS”, gdzie wymieniono propozycje dokumentów opisujących szczegóły podejścia do funkcji zabezpieczeń uprzednio skodyfikowanych przez GSS-API (RFC 2078)
Jak się okazuje, integracja strefy z Active Directory nie tylko zapewnia nadające się do użytku - chociaż niedoskonałe - rozwiązanie dylematu “Bezpieczeństwo czy czystość?” omówionego w poprzednim podrozdziale, lecz również daje w zamian pewne funkcje z których będzie można skorzystać w przyszłości..
Sposób integracji danych strefy z Active Directory jest z jednego punktu widzenia uosobieniem prostoty. Dane strefy są po prostu konwertowane na obiekty katalogu. Wszystko w katalogu jest obiektami, więc konwersja była konieczna aby skorzystać z magazynu danych katalogu. Strefa po integracji jest widoczna dla administratora w trybie tylko do odczytu (z wyjątkiem deskryptorów bezpieczeństwa, które można zapisywać) w konsoli Użytkownicy i komputery Active Directory, pod warunkiem aktywacji trybu zaawansowanego, w którym rekordy listowane są jako węzły Microsoft DNS (patrz rys. 7.2).
Aby spowodować integrację wystarczy przełączyć opcję we właściwościach serwera. Przełącznik przedstawiony jest na rys. 11.4 - zmiana miejsca przechowywania strefy z pliku do Active Directory jest pokrótce opisana w rozdziale 11. Tryb przechowywania poszczególnych stref podstawowych można zmieniać przyciskiem Zmień w zakładce Ogólne okna dialogowego Właściwości strefy (patrz rys. 11.7). Przeniesienie pierwszej strefy podstawowej do pamięci Active Directory powoduje zmianę właściwości serwera. W temacie zmiany trybu składowania strefy to już wszystko, przynajmniej jeśli chodzi o to, co może zrobić administrator lub czego się od niego oczekuje.
Zapisanie danych strefy w postaci obiektów katalogowych pociąga za sobą kilka natychmiastowych konsekwencji. Niektóre wynikają bezpośrednio z charakteru trwałej pamięci wykorzystanej dla Active Directory, jak np. przydział atrybutów bezpieczeństwa, inne są konsekwencją przeniesienia danych do postaci z którą mogą pracować usługi wspierające Active Directory, jak np. technologia replikacji.
Rys. 7.2 Dane strefy wylistowane w obrębie Active Directory
Poniżej pokrótce omówiono dwie dodatkowe wykorzystane możliwości, a następnie wdamy się w dość długie i zawiłe objaśnienia bezpieczeństwa danych strefy, łącznie z zabezpieczaniem procesu aktualizacji dynamicznej i jego ustawieniami domyślnymi.
Active Directory stosuje model z wieloma serwerami głównymi (multimaster), w którym, dla większości zakresu odpowiedzialności, każdy kontroler domeny jest równorzędny z wszystkimi pozostałymi w domenie. Ponieważ kontrolery domeny są od siebie oddalone, opóźnienia w komunikacji występują z natury przy propagacji zmian w obiektach zapisanych w katalogu. Domyślna instalacja ogranicza całkowite opóźnienie do 15 minut w obrębie lokacji
Wolałbym “ośrodka” ale tak chce Microsoft
(site); jednakże pomiędzy lokacjami opóźnienie jest zależne od połączenia między nimi.
Opóźnienie to oznacza, że dwie aktualizacje w dwóch kontrolerach domeny mogą ze sobą kolidować ponieważ zmiany nie są przesyłane w modelu rozproszonym, lecz każdy kontroler wierzy że jego dane są aktualne. Model ten jest obsługiwany przez technologię replikacji, w której zastosowano algorytm “ostatni zapis wygrywa” ze strategią przełamywania remisów (tie-breaking) służącą do rozwiązywania konfliktów. W skrócie, jest to ściśle powiązany system ze słabą zbieżnością. Kontrolery domen cechuje więcej niż równorzędność działania - w większości przypadków zachowują się jak identyczne klony, co daje ścisłe powiązanie. Jednakże z powodu niezależnych zmian i algorytmów replikacji, zawartość Active Directory jest nieustannie zbieżna; ponieważ zaś każda konkretna zmiana może zostać wycofana, zbieżność jest słaba (luźna). Wszelkie dane zapisane w Active Directory są automatycznie replikowane za pomocą tej technologii na wszystkie kontrolery w domenie. Tak więc, podobnie jak w standardowych transferach strefy, w strefach zintegrowanych z Active Directory pojawia się okres w którym dwa różne serwery DNS z pełnomocnictwami w strefie mogą dać dwie różne odpowiedzi na zapytanie dotyczące strefy.
Ponieważ wszystkie dane strefy stanowią po prostu zawartość Active Directory (i wobec tego replikowane są na wszystkie kontrolery domeny), maksymalne wykorzystanie tej szansy przez wprowadzenie niewielkich zmian w serwerze DNS narzucało się samo. W wyniku tego, gdy dane zintegrowane są z Active Directory, serwer DNS również pracuje w trybie multimaster (wielokrotnych serwerów nadrzędnych). Strefa może być obecna w wielu równorzędnie podstawowych instalacjach serwera DNS, z których każdy mieści się na kontrolerze domeny (ponieważ t...
paradoks24h