CrossRealm troubleshooting – Negocjacja wykorzystywanych typówszyfrowania.
CC - Resclassic
Kilka tygodni temu opisywałem problemy w konfiguracji trustu (cross realm trust’u) między MIT KDC i domeną Active Directory. Niby na maszynach wirtualnych wszystko działało. Użytkownicy mogli się zalogować, pobrać dane z AD, pobrać polisy czy uzyskać dostęp do udziałów sieciowych. Po kilku dniach; w sumie dwóch tygodniach klonowania, poprawiania tego co się źle sklonowało i instalowania tego czego zabrakło nadszedł czas na udostępnienie stacji użytkownikom. Na początku wszystko działało poprawnie. Jednak już po kilku godzinach pojawiały się głosy, że na stacji xyz nie można się zalogować do Realmu MIT. Wszelkie próby kończyły się informacją “Zły login lub hasło”:)
Niestety z względu na wsteczną kompatybilność byłem zmuszony do wykorzystywania DES-CBC-CRC. Jak wiadomo DES został wyłączony w domyślnej instalacji Windows 7. O tym jak go włączyć pisałem w jednym z poprzednich postów.
Niestety istnieją sytuacje, w których Windows 7 nie uwzględnia DES-CBC-CRC jako dozwolony typ szyfrowania:/ Nawet jeśli zostanie on włączony w rejestrze lub przez GP.
Skrótowy schemat pozyskiwania kluczy podczas logowania jest następujący:
- System wysyła prośbę o odpowiednie tickety, prosząc o wykorzystanie najmocniejszego z obsługiwanych mechanizmów szyfrowania - w moim przypadku RC4-Hmac.
- Jeśli serwer kluczy (KDC) obsługuje dany typ szyfrowania to zwracany jest odpowiedni ticket. Jeśli jednak dany typ/typy nie jest obsługiwany to dostajemy zwrotkę: KDC has no support for encryption type
- Jeśli klient otrzyma informacje o nieobsługiwanym typie szyfrowania to próbuje poprosić o ten sam ticket podając wspierane mechanizmy szyfrowania. W moim przypadku (RC4-HMAC, DEC-CBC-MD5, DES-CBC-CRC)
- Jeśli KDC kolejna zwrotka jest postaci: KDC has no support for encryption type to system wyświetli informacje “ Błędny login lub hasło”. Jeśli jednak hasło i typ szyfrowania był poprawny to system otrzyma odpowiednie tickety.
Niestety, po pewnym czasie bezczynności na końcówce z Windows 7 nie można się zalogować do Realmu. Po zgłoszeniu tego problemu przez studentów priorytetem było zalogowanie użytkownika a nie sprawdzenie problemu:/ – o dziwo restart rozwiązywał problem. Oczywiście przez kilka dni można prosić użytkowników o restart sprzętu, jednak nie można sobie pozwolić na zastosowanie restartu jako ostatecznego rozwiązania naszego problemu.
Dziś gdy testowałem pewne poprawki zauważyłem, że podczas wystąpienia w/w problemu system włączał oszczędzanie energii na karcie sieciowej. Po wznowieniu aktywności karta wracała do życia, niestety od tego czasu nie można się zalogować do realmu MIT Kerberos:/ Jak się okazało przy próbie zalogowania w logach KDC możemy zobaczyć komunikat typu:
kdc.realm krb5kdc[5102](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) IP.ADDRESS: BAD_ENCRYPTION_TYPE: [email protected] for krbtgt/MIT.REALM@MITREALM, KDC has no support for encryption type
Co ciekawe stacja wysyła dwie prośby o takiej samej treści a potem przestaje próbować negocjować odpowiedni mechanizm szyfrowania. Mimo włączenie DES-CBC-CRC nie jest on specyfikowany podczas komunikacji:/ Informacja o tym jest zawarta w (6 etypes{18 17 23 24 -135 3}). Te kilka cyfr mówi nam:
Proszę o ticket zaszyfrowany jednym z 6 mechanizmów (aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96, rc4-hmac, rc4-hmac-exp, .., des-cbc-md5). Super wyłączyłem wykorzystanie aes a system mimo to chce z niego korzystać. Niestety nigdzie nie pojawia się numerek 1 – des-cbc-crc:/
Jak się wstępnie okazuje jeśli w właściwościach karty sieciowej wyłączymy “Allow the computer to turn off this device to save power” to nawet po bardzo długim czasie bezczynności sprzętu (+-1,2h) z końcówki nadal można przeprowadzić logowanie do mitowskiego KDC. Oczywiście obecnie poprawka jest w fazie sprawdzania i jutro będzie testowana przez sporą liczbę studentów, jednak z tego co zdążyłem zauważyć w tygodniu ta drobna zmiana wykluczyła zgłaszanie problemów z logowaniem. Mam nadzieję, że nie jest to tylko kilkudniowy zbieg okoliczności…. cdn – pewnie po weekendzie:)
Swoją drogą jak to zwykle bywa analiza logów MIT KDC opiera się o znajomość pewnych cyferek. Pod tym linkiem można znaleźć kilka przydatnych numerków:)