W2K.PL

Jak przynajmniej co niektórzy moi znajomi wiedzą musiałem ostatnio rozwiązać pewien mały problem z aplikacją napisaną w Java. Jako że nie do wszystkich chyba wydzwaniałem tamtego wieczora to doświadczeniem podzielę się i tutaj :).

Na początku małe zastrzeżenie - jakoś do środowisk i aplikacji opartych o Java przekonany nie jestem (na swoim laptopie JVM nawet nie posiadam). Co może i da się odczuć w ramach tego postu, doświadczenia ostatnie raczej mnie do środowiska nie przekonały.

Problem był więc następujący - aplikacja napisana w Javie, działająca konkretnie w środowisku Tomcat + Axis posiadała niepomierną potrzebę uzyskania dostępu do pewnych usług web services działających na IIS6. Pech chciał, że dostęp ten nie mógł być anonimowy i konieczne było uwierzytelnienie się tej apliakcji z użyciem co najmniej NTLM. I tutaj zaczęły się pewne schody.

Po usuniÄ™ciu pierwszej warstwy problemów wygenerowanych w Å›rodowisku przez administratorów (po raz kolejny okazuje siÄ™ że to nie jest tak że “samo” siÄ™ psuje a Å›rodowiska testowe, w których wszystko dziaÅ‚a nie sÄ… jednak identyczne z produkcjÄ…) doszliÅ›my w rozwiÄ…zywaniu problemu do momentu gdzie jak zwykle najskuteczniejszÄ… formÄ… diagnostyki jest posÅ‚uchanie “co na drucie piszczy”.

Szybko okazało się, że rzeczona aplikacja nawet może i próbuje rozpocząć sekwencję uwierzytelnienia ale jakoś nie spotyka się to z aprobatą ze strony IIS. I tutaj clue dzisiejszego postu, czyli ta mała rzecz, która powoduje że warto o tym wspomnieć dla potomności. Pomimo że z analizy ruchu sieciowego wyraźnie wynikało że uwierzytelnienie nie następuje to klient w odpowiedzi uzyskiwał kod błędu HTTP 500 (Internal Error) zamiast oczekiwanego HTTP 401 (Unauthorized).

Okazuje się że sytuacja ta opisana jest w artykule KB 903071 i występuje w przypadku, gdy klient próbuje uwierzytelnić się z użyciem NTLMv1 gdy konfiugracja ustawień serwera wymusza NTLMv2. Zwrócenie kodu błędu HTTP 500 jest po prostu sposobem IISa na powiedzenie, że nie podoba mu się sposób uwierzytelnienia wybrany przez użytkownika (do zapamiętania).

Tutaj warto wrócić do środowiska Java, w którym występował problem. Okazuje się, że różne implementacje klienta HTTP w środowisku Java pozwalają na obsługę różnych funkcjonalności, w tym różnych metod uwierzytelnienia. Można porównać je między sobą chociażby na tym zestawieniu.

W tym konkretnym wypadku problem występował z powodu kombinacji trzech czynników:

• konfiguracji zabezpieczeÅ„ serwera, które zostaÅ‚y wykonane zgodnie z ustalonym w organizacji szablonem, bez uwzglÄ™dnienia specyfiki pracy serwera
• Wyboru przez developera Å›rodowiska aplikacji, które nie wspieraÅ‚o przyjÄ™tych w ramach organizacji metod uwierzytelnienia
• BÅ‚Ä™du developera w implementacji usÅ‚ugi (ale to już kompletnie inny temat).

RozwiÄ…zanie tego typu zagadek zajmuje jednak chwilÄ™. Coż … chociaż byÅ‚o z tego trochÄ™ “zawodowej” zabawy.

Wnioski na przyszÅ‚ość dla administratorów … rozmawiajcie ze swoimi developerami, chociażby po to aby ich kontrolować.

Wnioski na przyszÅ‚ość dla developerów … zainteresujcie siÄ™ czasami, czy przyjÄ™te przez Was rozwiÄ…zanie zadziaÅ‚a w istniejÄ…cej infrastrukturze.

Wnioski na przyszÅ‚ość dla mnie … zawsze (no może w miarÄ™ szybko po sprawdzeniu oczywistych rzeczy) rozpoczynać diagnostykÄ™ od analizy tego co “na drucie” piszczy :).