Monday, December 7th, 2009...11:52 pm

Kerberos a sprawa portu

Jump to Comments

W środowisku Windows Kerberos jest obecny od lat 10-ciu z okładem. A jednak wciąż pozostaje nieujarzmiony w większości wypadków czego dowodem są poniekąd wyniki mojej sesji jak i codzienna praktyka mojej pracy. Problemy są tu i ówdzie, w większości użytkownicy nie są ich świadomi … aż do czasu …

… do czasu gdy problem wystąpi. I wtedy zaczynają się schody. Dzisiaj schody te trochę postaram się zmniejszyć przynajmniej w kwestii jednej czyli Kerberos i usługi HTTP na porcie innym niż standardowy.

(cc) TheCX

Dzisiejszy post sponsorowany jest przez literkę A jak Architekt, który mnie do niego swoimi bojami z Kerberosem skłonił :).

Rzecz dotyczy nie tyle samego protokołu a tego jak go obsługuje klient w postaci Internet Explorera.

Never ending story, czyli SPNy …

Dla krótkiego przypomnienia – w chwili gdy klient próbuje uzyskać dostęp do usługi korzystając z uwierzytelnienia Kerberos występuje o bilet dostępu do zasobu (TGS). W celu określenia usługi, do której dostęp próbuje uzyskać używa SPN (service principal name), który KDC używa w celu zlokalizowania odpowiedniego konta obsługującego usługę. SPN to łańcuch znaków w formacie zasadzie dowolnym ale przyjeło sie że zawiera on przedrostek usługi, na przykład HTTP i jej adres, czyli nazwę hosta.

Czyli w przypadku, gdy użytkownik próbuje dostać się do serwera WWW pod adresem www.w2k.pl jego klient poprosi o dostęp do usługi (TGS REQ) używając SPN w formie HTTP/www.w2k.pl.

Jak wspomniałem SPN to łańcuch znaków w formacie w zasadzie dowolnym, ale w konwencji w jakiej się je przyjęło formułować jest i miejsce dla określenia portu, na którym działa usługa. SPN w takim przypadku przyjmuję formę <przedrostek/<adres usługi>:<port>. Na przykład dla serwera www.w2k.pl na porcie 8080 byłoby to HTTP/www.w2k.pl:8080.

Pozwala to na obsługę dwóch wirtyn, działających na różnych portach przez różne konta serwisowe. To tak w telegraficznym skrócie.

 

Na scenę wchodzi Internet Explorer …

Jak to teraz wygląda od strony klienta jakim jest IE. Załóżmy że mamy witrynę działającą na porcie 8080, do której próbujemy uzyskać dostęp z poziomu IE uwierzytelniając sie przy pomocy Kerberos. Ruch sieciowy w domyślnej konfiguracji pokaże nam coś w stylu tego zrzutu (powiekszenie po kliknięciu):

Jak widać IE próbuje uzyskać dostęp do witryny na porcie 8080, ale w żądaniu TGS REQ występując o bilet dostępu tego portu już nie specyfikuje, podając SPN HTTP/lhr2dc01.w2k.pl zamiast oczekiwangeo HTTP/lhr2dc01.w2k.pl:8080.

Zachowanie to wynika z problemu jaki pojawił się w IE6, polegającego dokładnie na tym, że IE nie specyfikuje numeru portu w żądaniu biletu Kerberos i opisanego w KB 908209. Dla IE 6 rozwiązanie to odpowiednia poprawka oraz wpis w rejestrze zgodnie z opisem  w artykule KB.

Pomimo że nie jest to napisane w tym artykule KB ten sam problem dotyczy w domyślnej konfiguracji również IE7 oraz IE8. W przypadku tych przeglądarek wystarczy jednak tylko wprowadzić odpowiedni wpis w rejestrze, bez konieczności instalacji poprawek. A po jego wprowadzeniu sytuacja staje się zupełnie inna (powiększnenie po kliknięciu) …

Jak widać IE poprawnie wysepcyfikował numer portu przesyłany w ramach TGS REQ co umożliwa poprawne uwierzytelnienie się względem tej usługi.

 

Kiedy to się przydaje …

‘”A po co takie dziwolągi ???” ktoś spyta. A po to właśnie aby możliwe było uruchomienie kilku witryn na jednym adresie IP lecz na różnych portach, które będą działały w kontekście różnych kont serwisowych (pul aplikacji IIS).

Jeżeli wszystkie aplikacje działają w kontekście konta lokalnego komputera lub pojedynczego konta domenowego  to nie ma to znaczenia. Jeżeli jednak będziemy korzystali z różnych kont serwisowych dla aplikacji na różnych portach z których korzystać będziemy poprzez IE poprawka ta może być wymagana.

 

A dlaczego nie włączyć tego domyślnie …

Ano właśnie … to pytanie pewnie przemknęło komuś przez głowę i mi również. Problem był w IE6 ale dlaczego w kolejnych wersjach nie jest to poprawione i włączone domyślnie?

Oficjalnej odpowiedzi nie znam ale moje prywatne domysły to wpływ czegoś co określam jako “przekleństwo IE6” :). Ponieważ w IE6 tak to działało domyślnie, nikt nie zauważył (o ile nie musiał) że taki problem istnieje. Wszystko ładnie działa, nawet gdy aplikacje działają na jednym koncie (na przykład Network Service), na różnych portach a konto to posiada tylko jeden zarejestrowany SPN – HTTP/usługa. Działają, ponieważ IE nie wysyła numeru portu w SPN.

Co by się teraz stało, gdyby IE zaczął ten numer domyślnie dołączać do SPNa? Wszystkie instalacje, w których taka konfiguracja opisana powyżej występuje, nagle przestałyby poprawnie funkcjonować i zaczęłyby się problemy z uwierzytelnieniem. I dlatego decyzję o włączeniu tego mechanizmu pozostawiono administratorom.

Jest tylko jeden problem, a w zasadzie dwa:

1/ Muszą o tym wiedzieć (co mam nadzieję niniejszym trochę propaguję)

2/ Dlaczego tego ustawienia nie ma w domyślnych szablonach ADM dla IE ??

To w zasdzie tyle w temacie.

5 Comments

  • @ 2/ Dlaczego tego ustawienia nie ma w domyślnych szablonach ADM dla IE ??

    Może dlatego, że ten wpis nie jest robiony w “zatwierdzonym miejscu tworzenia zasad”?

  • @Zygmunt
    Tak .. dobry trop, dobry … oczywiście że tak jest i jestem tego świadom. Dalej jednak zadaje pytanie (co prawda w próżnię 🙂 ) dlaczego tak jest ??? 🙂

  • Ja pierwszy raz spotkałem się z tym problemem właśnie w SharePoint Server – w środowisku w którym konsolka administracyjna działała na innym koncie ( i oczywiście innym porcie ), a użytkownicy byli uwierzytelniani przy pomocy SmartCard i KCD na ISA.
    Dlaczego więc nie jest to automatycznie dostępne? Myślę że głównie ze względu na prostotę. Bez tego wpisu nie ma najmniejszego probelmu aby wystawić dowolny front-end webowy korzystający z Integrated Authentication na IIS. W przypadku konieczności ( z tego co pamiętam ten wpis wymusza stosowanie nr. portów w spn-ach, a domyślne przepisywanie nieokreślonych spn-ów na HOST/FQDN nie działa w wypadku nr. portu ) wpisania portu konfiguracja większości witryn by musiała zawierać dokonfigurowanie spn-a. A tak wszystko działa – czy to typowa strona webowa, czy konsolka administracyjna sharepoint, czy konsolka scom.

  • Będę czytał Twojego bloga. Będę czytał Twojego bloga. Będę czytał Twojego bloga. (Ale nie codziennie, ok?)

  • […] 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” […]

Leave a Reply