Artykuł ten kontynuuje serię na temat pracy z Narzędziem Diagnostycznym Kontrolera Domeny (Domain Controller Diagnostic Utility), omawiając konkretne testy, które można uruchomić.
Mam nadzieję, że do tej pory wszyscy zrozumieli, że Narzędzie Diagnostyczne Kontrolera Domeny ma wiele możliwości, dzięki którym można skonfigurować narzędzie tak, aby działało w sposób, który najbardziej odpowiada konkretnym potrzebom użytkownika. I teraz, gdy omówiłem przełączniki wiersza poleceń, chcę skierować swoją uwagę na konkretne testy, które narzędzie to potrafi uruchomić.
Anonsowanie
Pierwszym testem, który można uruchomić, jest test anonsowania. Test ten sprawdza czy każdy Agent Systemu Katalogowego (Directory System Agent) sam się anonsuje. Jeśli tak, to test upewnia się, że anonsowanie wymienia kontroler domeny, jako ten posiadający uprawnienia Agenta Systemu Katalogowego.
W przypadku, gdy koncepcja Agenta Systemu Katalogowego nie jest Ci znana, wyjaśnię, że Agent Systemu Katalogowego (Directory System Agent - często w skrócie DSA) jest w rzeczywistości zbiorem wielu usług i procesów, które działają na kontrolerze domeny. Jego zadaniem jest zapewnienie dostępu do bazy danych usługi Active Directory. DSA jest pod-elementem LSA (Local System Authority). Powodem, dla którego obejmuje on wiele procesów i usług, jest fakt, że dostarcza on wielu mechanizmów, za pomocą których klienci mają do niego dostęp.
Prawdopodobnie najbardziej znanym z tych mechanizmów jest Light Weight Directory Access Protocol (protokół zezwalający na dostęp do katalogów adresowych w sieciach TCP/IP), powszechnie znany jako LDAP. LDAP jest protokołem, za pośrednictwem którego większość nowszych systemów operacyjnych Windows przeszukuje katalog Active Directory. Starsi klienci nadal wymagają dostępu do DSA, ale zazwyczaj dokonują tego za pomocą Menedżera Kont Zabezpieczeń (Security Account Manager - SAM). Nie są to jedyne mechanizmy, dzięki którym DSA jest dostępny. Na przykład Microsoft Exchange komunikuje się z DSA przy użyciu połączeń RPC opartych na MAPI. DSA także komunikują się ze sobą przy użyciu zdalnego wywołania procedur.
CheckSDRefDom
Test ten sprawdza, czy wszystkie partycje katalogu aplikacji posiadają odpowiednie domeny odniesienia deskryptora zabezpieczeń. Domyślam się, że ten test będzie wydawał się bezsensowny dla każdego, kto nie jest ekspertem Active Directory. Dlatego poświęcę parę minut na wyjaśnienie tego testu.
Prawdopodobnie wiesz, że każdy obiekt w usłudze Active Directory zawiera deskryptor zabezpieczeń. Zadaniem deskryptorów zabezpieczeń jest utrzymanie listy kontroli dostępu. Zazwyczaj wbudowany deskryptor zabezpieczeń działa całkiem dobrze, jeśli chodzi o zapisywanie tego, kto ma dostęp do czego. Problemy mogą wystąpić, jeśli jedna organizacja zaczyna używać partycje katalogu aplikacji (wcześniej znane jako Active Directory Application Mode lub ADAM). Powodem tego jest fakt, że partycje katalogu aplikacji nie podlegają domenie. W rzeczywistości można stworzyć partycję katalogu aplikacji, a następnie stworzyć jej replikę w innych kontrolerach domeny poprzez wielokrotne domeny. Ze względu na ten problem Windows przypisuje domeny odniesienia deskryptora zabezpieczeń do każdej partycji katalogu aplikacji, gdy jest on tworzony.
Domeny odniesienia deskryptora zabezpieczeń informują partycję katalogu aplikacji, której nazwy domeny używać, gdy wartość domeny musi być wprowadzona do deskryptora zabezpieczeń. System Windows ma wiele reguł, które określają, jaka nazwa domeny jest używana. Mówiąc prościej, jeśli stworzysz nową partycję katalogu aplikacji, która nie jest podrzędna innej partycji, a domena odniesienia deskryptora zabezpieczeń używa domeny lasu głównego jako nazwy domeny do stosowania w różnych deskryptorach zabezpieczeń. Jeżeli partycja katalogu aplikacji jest podrzędna innemu obiektowi, to przyjmuje domenę odniesienia deskryptora zabezpieczeń obiektu nadrzędnego.
CheckSecurityError
Następnym testem, który chcę omówić jest test „Check Security Error”. W odróżnieniu od poprzedniego testu, który opisywałem, test „Check Security Error” nie jest uruchamiany domyślnie. Jeśli chcesz uruchomić ten test, będziesz musiał zrobić to ręcznie za pomocą polecenia DCDIAG.
Gdy uruchomisz ten test, DCDIAG zlokalizuje wszelkie błędy związane z bezpieczeństwem, jak i błędy, które mogą być związane z bezpieczeństwem, a następnie próbuje zdiagnozować problem. Istnieje jeden opcjonalny parametr, którego można użyć z tym przełącznikiem. Przełącznik /ReplSource umożliwia określenie konkretnego kontrolera domeny, wobec którego uruchamia się test. Można użyć dowolnego kontrolera domeny, niezależnie od statusu błędu jak i bez względu na to czy jest dostępnym partnerem, czy nie. Wystarczy podać nazwę testu (CheckSecurityError), i dopisać przełącznik /ReplSource, dwukropek i nazwę kontrolera domeny, który chcesz przetestować.
Connectivity
Test „Connectivity” (Test Łączności) jest jednym z najbardziej użytecznych testów, jakie można uruchomić. W rzeczywistości test ten jest tak istotny, że DCDIAG nie pozwala na jego pominięcie. Po domyślnym uruchomieniu DCDIAG, test „Connectivity” jest uruchamiany automatycznie.
Test „Connectivity” sprawdza czy kontrolery domen są zarejestrowane w systemie DNS oraz czy mogą być przetestowane przy użyciu polecenia ping i czy mogą nawiązywać połączenia LDAP/RDP.
CrossRefValidation
Muszę być szczery i powiem, że nie byłem w stanie znaleźć wielu dokumentów na temat tego testu. Mogę powiedzieć, że test ten szuka odsyłaczy, które są w jakikolwiek sposób nieprawidłowe. Jeśli zdarzy się tak, że otrzymasz błąd poprawności odsyłaczy, problem może być rozwiązany za pomocą przystawki Edytor ADSI, która usunie nieprawidłowy obiekt.
Pragnę także podkreślić, że jeśli użyjesz Edytora ADSI nieprawidłowo, możesz zniszczyć usługę Active Directory. Dlatego też chciałbym zalecić zrobienie pełnej kopii zapasowej stanu systemu kontrolera domeny przed dokonaniem jakichkolwiek zmian za pomocą Edytora ADSI.
CutOffServers
Ostatnim testem, który chcę omówić w tym artykule jest test „Cut off Servers” (Serwery Rozłączone). Podstawą tego testu jest fakt, że w większości przypadków, kontrolery domeny posiadają jeden lub więcej partnerów replikacji. Jeśli partner replikacji kontrolera domeny jest wyłączony, to kontroler domeny może nie móc się „odświeżyć” aktualizacjami Active Directory, a DCDIAG zgłosi błąd „Cut off Servers”.
Aby być w stanie rozwiązać tego typu problemy wystarczy dowiedzieć się, jakich partnerów replikacji ma kontroler domeny. Faktyczna metoda różni się w zależności od wersji systemu Windows, ale w systemie Windows Server 2003 partnerów replikacji można sprawdzić za pośrednictwem Active Directory Site oraz konsoli usług.
Po otworzeniu drzewa konsoli, rozwiń kontener Site, aby wyświetlić listę serwerów w usłudze Active Directory. Następnie kliknij dwukrotnie na serwerze, zawierającym kontrolera domeny, który chcesz zbadać. Następnie rozwiń folder Servers, a następnie folder odpowiadający nazwie kontrolera domeny, którym jesteś zainteresowany. Na końcu kliknij dwukrotnie na kontener NTDSSettings, a system Windows wyświetli listę obiektów połączeń. Ta lista wyświetla partnerów replikacji w kolumnie „From Server”.
Podsumowanie
W artykule tym rozpocząłem omawianie niektórych testów, które można uruchomić za pomocą narzędzia DCDIAG. W następnej części tej serii artykułów, będę kontynuować dyskusję, przedstawiając jeszcze kilka testów, które można wykonać.
Źródło: www.windowsnetworking.com
|
