it-flow.pl

Migracje, migracje i jeszcze raz migracje. Od pewnego czasu siedzę i staram się poprawić i udoskonalić stare usługi, zaktualizować systemy, itd.

Jedną z bardziej interesujących rzeczy jest migracja z Windows XP do Windows 7. Jak to zwykle bywa jednym z częstszych problemów jest odpowiednia konfiguracja systemów do współpracy z trustem między REALM-em MIT Kerberos a Active Directory.

W Windows 7 Microsoft wprowadził sporo zmian część z nich dotyczy konfiguracji samego logowania do REALMu.

Główne zmiany to:

• Uproszczenie konfiguracji samego REALMu na stacjach klienckich
• Wyłączenie przestarzałych mechanizmów szyfrowania (DES-CBC-{CRC,MD5})- źródło
• Wprowadzenie odpowiedniego szablonu polis do konfiguracji REALMu

Po instalacji Windows 7 i wpięciu systemu do domeny rozpocząłem konfigurację REALMu. Po małym przeglądnięciu kilku stron amerykańskich uniwersytetów okazało się, że konfiguracji realmu w Windows 7 nie przeprowadza się już za pomocą ksetup.exe:

ksetup.exe /addkdc nazwa_realmu nazwa_serwera_kdc_dla_podanego_realmu

ksetup.exe /domain nazwa_domyslnej _domeny

Dla ułatwienia Microsoft utworzył odpowiedni szablon polis:

Na początku zainteresowałem się tylko dwiema opcjami:

• Define interoperable Kerberos V5 realm settings – opcja odpowiada za odpowiednią konfigurację realmu oraz serwerów KDC, które ma wykorzystać klient. W Windows XP konfiguracja tych ustawień dobywała się za pomocą ksetup.exe
• Require strict KDC validation – sprawdza pewne obostrzenia dotyczące certyfikatu serwera KDC.

Dodatkowo skusiłem się na ustawienie DefaultLogonDomain na nazwę mojego Realmu. Jak większość pamięta od Visty z ekranu logowania zniknęła możliwość wyboru domeny/realmu logowania. Aktualnie użytkownik ma się logować za pomocą User Principal Name (login@nazwadomeny). Ustawnie DefaultLogonDomain pozwala logować się do domyślnej domeny/realmu za pomocą samego loginu

Jeśli, ktoś nie chce konfigurować tych ustawień za pomocą GPO to może wykorzystać odpowiedni wpisy w rejestrze

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
“DefaultLogonDomain”=”Nazwa_Realmu”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos]
“MitRealms_Enabled”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\MitRealms]
“Nazwa_Realmu”=”<f>0×00000008</f><k>serwer_kdc_1;serwer_kdc_2</k>”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
“KdcValidation”=dword:00000002

W przypadku trzeciego ustawienia (Define interoperable Kerberos V5 realm settings) między <f></f> podajemy w postaci hex-a listę opcji, które mają być wykorzystane podczas odpytywania serwerów KDC w danym realmie:

• 0×00 None – brak flag
• 0×01 SendAddress – pozwalaj na adresy IP w generowanych ticketach
• 0×02 TcpSupported – serwery kluczy akceptują ruch TCP, wymagany przy dużych pakietach
• 0×04 Delegate – każdy w realmie jest zaufany do delegacji
• 0×08 NcSupported – podany realm wspiera Name Canonicalization

Przepraszam za trochę lakoniczne tłumaczenie, więcej informacji o opcjach w technecie.

Jeśli po konfiguracji nie udaje się zalogować do systemu. Występuje komunikat błędny login lub hasło, to najprawdopodobniej serwery kluczy wykorzystują mechanizmy DES-CBC-CRC lub DES-CBC-MD5, które w Windows 7 i Windows Server 2008 R2 zostały domyślnie wyłączone. Włącznie mechanizmów najlepiej wykonać za pomocą GPO:

Tutaj taka drobna uwaga, którą podał Tomek Onyszko na wss.pl. W niektórych przypadkach warto wyłączyć AES128 i AES256 jeśli nie jest on wykorzystywany.

Po zmianie tych ustawień można się poprawnie zalogować używając MITowskiego realmu. Niestety po zalogowaniu na użytkownika nie zostały nadrzucone polisy oraz sam użytkownik nie miał dostępu do serwerów będących w domenie Windows. Co prawda w logach DC widać, że zaszło mapowanie użytkownika z realmu na użytkownika w AD jednak polecenie klist nie wyświetla wymaganych ticketów.

Po trzech dniach spędzonych przy Wiresharku postanowiłem zapytać na wss i jak zwykle w sprawach związanych z Kerberosem Tomek Onyszko okazał się być bardzo pomocny. Nie wiem jak mu podziękować bo gdyby nie jego pomoc to nadal ślęczałbym nad ekranem z dumpem wiresharka.

Poniżej postaram się krótko opisać gdzie tkwił problem.

W przypadku zaufania między domenami czy realmami, komputer odpytuje odpowiednie serwery kluczy w celu pozyskania odpowiednich ticketów, które później będzie wykorzystywał do uzyskania dostępu do konkretnych serwerów. W tym poście nie będę tego jakoś szczególnie opisywał (dobry materiał na kolejny post). W skrócie jeśli klient nie dostanie ticketu z serwera kluczy z jednej domeny to prosi o odpowiedni ticket Granting Services, który pozwala mu odpytać kolejny serwer kluczy odpowiedniej domeny.

Tak robił XP, który jest aktualnie na stanowiskach:

Powyższy zrzut ekranu obrazuje prośbę klienta o odpowiedni ticket na potrzeby dostępu do miejsca gdzie leża polisy:

1. Klient prosi o TGS serwera KDC w realmie, w którym uwierzytelnił się użytkownik
2. Serwer kluczy dla danego realmu zwraca informacje PRINCIPAL_UNKNOWN – informacja o określonym SPN znajduje się w innym serwerze kluczy ( w moim przypadku kontrolerze domeny z którą zestawiony był trust realm )
3. Klient prosi o TGS (krbtgt/nazwa_realmu) ticket jest wymagany by klient mógł rozmawiać z zaufaną domeną
4. Serwer kluczy w naszym realmie odsyła odpowiedni ticket
5. Klient prosi kontroler domeny o określony ticket dla cifs/nazwa_kontrolera (strzałka 3 na zdjęciu), wykorzystując ticket, który otrzymał w kroku czwartym.
6. Serwer zwraca odpowiedni ticket.
7. Klient przystępuje do komunikacji z serwerem plików.

W przypadku Windows 7 spraw wyglądała trochę gorzej ponieważ, system pomijał prośbę o TGS (krbtgt, oraz o odpowiedni ticket w zaufanej domenie i przeskakiwał na NTLM):

Jak widać na powyższym zrzucie ekranu klient:

1. Pyta serwer kluczy dla wykorzystywanego realmu
2. Serwer zwraca odpowiedź o braku Principala o określonej nazwie (2)
3. Klient próbuje wykorzystać NTLM by dostać się do zasobów.
4. Próba w dalszej części kończy się fiaskiem.

Po pomocy Tomka okazało się że problem ten można rozwiązać poprzez wskazanie systemowi klienckiemu jakie nazwy realmow/lasow ma przeszukiwać. Można to skonfigurować w GPO ( pierwsze zdjęcie w wpisie) Use forest search order. Po dopisaniu tam nazwa_realmu, nazwa_domeny_ad, klient zaczyna odpytywać kontroler. Jedynym minusem który tutaj występuje jest brak zapytania ok określony  TGS (krbt/…) jednak ticket ten zostaje pobrany na samym początku podczas logowania do domeny. Po ostatniej zmianie klient zaczyna poprawnie funkcjonować:

• pobierane są polisy dla użytkownika
• można uzyskać dostęp do określonych zasobów dyskowych w zaufanej domenie.

Przyznam się, że problem jest dość ciekawy i w wolnej chwili trzeba się będzie trochę bardziej w niego zagłębić. Ale wcześniej muszę sobie skonfigurować wirtualnej środowisko by nie bawić się w zamazywanie zrzutów z Wiresharka. Przy okazji może uda mi się opisać proces konfiguracji Cross Realm Trusta.

Nie lubię diagnozować problemów z replikacją. Zazwyczaj problemy te są proste do zidentyfikowania i poprawienia, jednak czasem człowiek wyrywa sobie włosy z głowy.

W jednej z domen, którą zarządzam mam mieszane środowisko Wind2k3 i Win 2k. Zazwyczaj wszystko pięknie chodzi, co często usypia moją czujność i pozwala mi zapomnieć o niektórych maszynach na długi czas ( czasem w końcu trzeba wgrać poprawki). Po ostatnich przenosinach, podmiankach, wymianach, readresacjach…, które odbyły się o dziwo bez problemu od pewnego czasu w logach pojawiały się Eventy 1311, 1566. Osoby zajmujące się Active Directory stwierdź – haha standardowe problemy How to troubleshoot intra-site replication failures. No i wszystko fajnie przeszedłem całą standardową procedurę omijając kroki, które mnie nie dotyczą, czyli ogólnie: repadmin …, net stop lsass …, netdom resetpwd …, net start lsass. Po restarcie wszystko działa jak poprzednio , replikacja nadal Access Denied. Wireshark mówi, że kontrolery się komunikują jednak DC wyraźnie stwierdza ze KCC nie może zbudować topologii replikacji.  Repadmin stwierdza, że wszystko spięte, połączenia istnieją, itd.  Jak się okazało rozwiązaniem problemu była aplikacja łatki Q819249.

In Windows 2000, the Knowledge Consistency Checker (KCC) uses the Intersite Messaging service to help it build the spanning tree topology for Microsoft Active Directory directory service replication. In a very small percentage of cases, Intersite Messaging may not complete building the hash table that it passes to the KCC. When the KCC uses this hash table in its calculations, this may generate the KCC logging event ID 1311 in the Directory Services event log.
This problem typically occurs in environments with large numbers of sites, domain controllers, and domains.

W sumie niewiele brakło a zadałbym pytanie na WSS. Jednak stwierdziłem, że skoro od pewnego czasu interesuję się AD to trzeba sobie z problemami radzić samemu <taniec szczęścia>.

Ostatnio przygotowując obrazy na laboratoria, powstała potrzeba stworzenia małej instalacji Windows 2003 Server. Sprawa dość prosta 2,5GB dysk szybka instalacja systemu. Dogranie niezbędnych aplikacji (newSid, Res Kit, Supp Tools, etc). Potem szybkie wrzucenie obrazu na serwer i włala można wracać do innych obowiązków.

Po pewnym czasie zaszła potrzeba by studenci wypromowali maszynki do roli kontrolera domeny. Promocja przebiegała bez problemu. Instalator zakończył proces promocji bez błędów, przynajmniej tak oznajmił:) Jak się potem okazało kontroler ładował się bardzo długo, nie było możliwości otwarcia domyślnych polis domeny, etc.

Po około 8h pracy, rozpinaniu wszystkiego, sprawdzaniu logów, szukania porad na stronach technetu i eventid.net udało się znaleźć przyczynę takiego zachowania:( Była ona dość błaha, podczas promocji do roli kontrolera domeny system miał tylko 499 MB wolnego miejsca. Zgodnie z tym co jest napisane w dokumentacji do Active Directory. Minimalnie MUSI być 512MB wolnego miejsca. Jeśli będzie mniej to instalator przeprowadzi proces promocji jednak sam kontroler nie będzie działał prawidłowo.

Swoją drogą szkoda, że w takiej sytuacji dcpromo nie krzyczy jakimś ładnym komunikatem: “brak wystarczającej ilości miejsca na dysku”. 

P.S.

Wszyscy zapomnieli o sprawdzeniu wolnego miejsca na dysku, bo w sali obok identyczna konfiguracja działała bez problemu. Był tylko jeden szczegół w drugiej sali było 256MB RAM a nie 512. Tak więc plik wymiany był mniejszy i dcpromo miało wystarczającą ilość wolnej przestrzeni:)