W serii Ruch sieciowy prawdę Ci powie nadszedł czas na odcinek #2 … tym razem w roli głównej Kerberos, farma aplikacji wielowarstwowa i niekończące się problemy z uwierzytelnieniem. Przeważnie o tej samej lub podobnej przyczynie.
W życiu niemłodego już konsultanta, zdarzają się jak już wspominałem dni, w których wezwany zostaje w charakterze kawalerii do rozwiązywania problemów. I tym razem tak było, a problem był całkiem typowy czyli uwierzytelnienie Kerberos nie działa. Może i samo uwierzytelnienie działa, ale skakać po farmie już nie chce. Ale nie uprzedzajmy faktów …
… i od początku
Konfiguracja, o której mowa, a w której występowały problemy była całkiem typowa jak na aplikacje wdrażane w instytucjach. Per-analogia do pewnego systemu uprawy rolnej nazwijmy ją „trójwarstwówką”. Składała się ona z:
- Warstwy prezentacji, ogólnie front-end zwanej, w tym konkretnym wypadku był to MOSS 2007 działający w ramach farmy
- Warstwa raportowa po środku (często warstwą logiki zwaną), w tym wypadku konkretnie realizowana przez SQL Reporting Services 2008
- Warstwa baz danych, zawierająca dane ważne i pożądane, aby w tych raportach uczestniczących, tutaj na SQL 2008 składowane (OLAP dokładniej).
Całość miała być dostępna z poziomu warstwy inteligentnej zwanej użytkownikiem w jego kontekście bezpieczeństwa, czyli użytkownik dostając się do MOSS widzi te raporty i te dane w ramach raportów, do których dostęp ma na podstawie swojego konta z usługi katalogowej. Zadanie lekkie, łatwe i przyjemne dla protokołu Kerberos i mechanizmu delegacji w nim działającego. Który jak to zwykle bywa działać nie chciał. Przypadek typowy, ale z małymi przypadłościami i dlatego ciekawy …
… warstwa prezentacji
MOSS 2007 jest typowym przykładem aplikacji, która potrafi skorzystać z mechanizmów uwierzytelnienie Kerberos o ile zostanie do tego skonfigurowana. Wymagana konfiguracja opisana jest w szczegółach na stronach Technet: Configure Kerberos authentication (Office SharePoint Server). Jedna rzecz o której warto wiedzieć i pamiętać – artykuł ten, wspomina o konieczności konfiguracji SPN dla adresów z odpowiednimi portami, co jest rozwiązaniem problemy związanego z domyślnym zachowaniem IE o którym już kiedyś pisałem. To o czym dokument ten nie wspomina, to fakt że IE ma jeszcze jedno „domyślne zachowanie” wpływające na działanie mechanizmów uwierzytelnienia, czyli w przypadku odwołania do adresu serwera z użyciem rekordu CNAME (popularnie mówiąc aliasu) konstruuje zapytanie o SPN używając rekordu podstawowego (A) dla tego aliasu. Problem jest znany i opisany w artykule KB 911149. Pomimo że nie jest to napisane wprost w tym artykule KB to zachowanie takie jest identyczne dla IE 7 i 8, tyle że nie jest potrzebny hotfix a tylko wpis w rejestrze.
I to był pierwszy problem, jaki był do wyprostowania w opisywanym przykładzie. Wszystko jak na dłoni widać w ruchu sieciowym, ale dla tego akurat przykładu nie mam – pozostawiam dla własnego przetestowania.
… warstwa raportowania
Następnym elementem układanki jest dostanie się do warstwy raportowej. W tym celu, MOSS rzeczony musi przejąć poświadczenia użytkownika, wystąpić o odpowiedni bilet dostępu do usługi i uwierzytelnić się w imieniu użytkownika względem usługi Reporting Services. Schemat delegacji omawiałem w swojej prezentacji na MTS, zainteresowanych odsyłam do materiałów (a i video jest na stronie MTS 2009).
Reporting Services muszą zostać również skonfigurowana do użycia uwierzytelnienia Windows – można tego dokonać przy instalacji lub później poprzez plik konfiguracyjny usługi. Oczywiście wiąże się to z koniecznością zarejestrowania w AD odpowiednich SPN dla tej usługi dla odpowiedniego konta, jednak poprawnie wykonuje to sama usługa przy starcie po skonfigurowaniu jej do działania z uwierzytelnieniem Windows (i o ile posiada takie uprawnienia). Odnotować należy również, że Reporting Services domyślnie uruchamiają swój web service na porcie innym niż 80, w związku z tym rejestrują też SPN dla odpowiedniego portu.
Wracając do naszej aplikacji … pomimo, że użytkownik poprawnie uwierzytelniał się do portalu MOSS to nie miał dostępu do raportów udostępnianych przez Reporting services. Wniosek … delegacja nie działa. Szybkie uruchomienie Network Monitor (chociaż ostatnio odnowiłem swoją znajomość z Wireshark odkąd da się go uruchomić na Win7 x64) i obserwujemy co poniżej:
Jak widać na zrzucie z ruchu sieciowego klient (farma MOSS) próbuje wykonać uwierzytelnienie z użyciem Kerberos (ramki 424, 428), niestety nie udaje się to i ponawia próbę używając NTLM (NLMP to błąd w paserach Network Monitor, oznacza NTLM), co również się nie udaje (co jednak było oczekiwane bo w takim kontekście próba ta wykonywana w kontekście użytkownika anoniomowego, NTLM nie umożliwia bowiem delegacji).
Kluczem do zagadki jest to, że Reporting Services udostępnia swoje usługi na porcie innym niż domyślny TCP/80. Wiąże się z tym to, że SPN zarejestrowane dla odpowiedniego konta, również zarejestrowane są z odpowiednim numerem portu.
Następny element układanki to wiedza trochę wyciągnięta z placu boju, czyli to że problemy z Kerberos opisane w KB w kontekście IE obejmują nie tylko samego IE ale również komponenty z niego korzystające lub korzystające z tych samych mechanizmów (bibliotek). W związku z tym, MOSS który wykonuje w naszej przykładowej aplikacji delegację do usługi reporting services konstruuje(zgodnie z opisywanym zachowaniem) SPN do usługi bez podania portu, czyli:
http/<nazwa serwera>
zamiast:
http/<nazwa serwera>:<numer portu>
Możliwe rozwiązania w danej sytuacji są co najmniej trzy:
- Uruchomienie usługi Reporting Services na porcie 80
- Wykonanie dla odpowiedniego procesu MOSS konfiguracji opisanej w KB
- O ile to jest możliwe i nie konfliktuje z innymi usługami dodanie do konta serwisowego Reporting Services SPN dla usługi HTTP bez podanego portu .
W wypadku naszej aplikacji zastosowane zostało rozwiązanie trzecie (bardziej obejście niż rozwiązanie) i w wyniku tego działania delegacja pomiędzy MOSS a Reporting Services zaczęła działać poprawnie:
Takie zachowanie nie dotyczy tylko usługi MOSS. Innym przykładem, gdy warto pamiętać o obsłudze portu przy generowaniu SPN to scenariusze, w których ISA używana jest do publikowania usług, które wewnątrz sieci działają na portach innych niż standardowe. W takim wypadku, ISA przekazując zapytanie do usługi gdy wymaga to uwierzytelnienia z użyciem Kerberos również może generować zapytania używając SPN bez numeru portu.
… warstwa bazy danych
Dalej, w przypadku naszej aplikacji wymagana jeszcze była delegacja Kerberos z poziomu Reporting Services do bazy danych SQL. W tym wypadku była to już standardowa konfiguracja wymagająca zarejestrowania odpowiednich SPN dla usług dla odpowiednich konta, na których one działały.
… i po farmie
Jak widać nasz scenariusz do bardzo skomplikowanych nie należał, jednak jest ciekawy ze względu na:
- Przekazanie uwierzytelnienia Kerberos pomiędzy trzema warstwami aplikacji,
- Uwzględnienie niestandardowego zachowania zarówno IE jak i innego oprogramowania w zakresie obsługi protokołu Kerberos.
Jak zwykle w takich wypadkach najszybszym i najbardziej efektywnym narzędziem diagnostycznym okazuje się sniffer ruchu sieciowego … który jak to mówią … prawdę Ci powie.
I kolejny problem rozwiązany.