Cross Realm Trust.

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>0x00000008</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:

• 0x00 None – brak flag


• 0x01 SendAddress – pozwalaj na adresy IP w generowanych ticketach


• 0x02 TcpSupported – serwery kluczy akceptują ruch TCP, wymagany przy dużych pakietach


• 0x04 Delegate – każdy w realmie jest zaufany do delegacji


• 0x08 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.