Forefront TMG 2010 - część 18 - Przekazywanie poświadczeń
.png "Udostępnij na: Facebook")
Autor: Jacek Światowiak
Opublikowano: 2012-04-05
Wprowadzenie
W poprzedniej części naszego cyklu omówiono wykorzystanie weryfikatora LDAP, jednakże zdecydowanie częściej wykorzystywany jest serwer RADIUS, celem uwierzytelniania, autoryzacji i rozliczania użytkowników czy urządzeń.
Wstęp
Zagadnienia przepływu poświadczeń zostały już poprzednio poruszone. W tej części postaramy się zebrać i usystematyzować wszystkie mechanizmy związane z przepływem poświadczeń od klienta do serwera docelowego, przechodzące przez serwer TMG 2010. Na Rys. 1. schematycznie przedstawiono mechanizm przepływu poświadczeń pomiędzy klientem a publikowanym zasobem (serwerem).
.jpg "Mechanizm przepływu poświadczeń")
Rys. 1. Mechanizm przepływu poświadczeń.
Realizując krok 1, użytkownik wysyła żądanie zestawienia połączenia uwierzytelnionego z serwerem docelowym. Po drodze znajduje się serwer TMG 2010, który zabezpiecza komunikację skierowaną do publikowanego zasobu. Biorąc pod uwagę sposób uwierzytelniania (miejsca uwierzytelniania), droga obiegu (przekazywania poświadczeń) może być różna. Nie rozpatrując specyficznego przypadku, zakładamy, iż uwierzytelnianie zachodzi na serwerze TMG 2010. Wówczas serwer TMG 2010, nie mając samodzielnej bazy, w której dokonuje uwierzytelniania, musi zweryfikować podane przez klienta poświadczenia w tzw. weryfikatorze. Proces ten realizowany jest podczas kroku 2. Takim weryfikatorem może być Active Direcory (kontroler domeny) lub serwer LDAP, RADIUS, lub RSA SecureID. Po weryfikacji, zakończonej powodzeniem w kroku 3, weryfikator potwierdza poświadczenia klienta, które to serwer TMG 2010, w kroku 4, przekazuje lub nie (w zależności od tego, czy serwer docelowy wymaga uwierzytelniania, czy nie) do serwera docelowego (zasobu). Podczas wykonywania kroku 5, serwer docelowy potwierdza tożsamość użytkownika. Informacje na ten temat przekazywane są zwrotnie, w kroku 5, do serwera TMG 2010, który to, w kroku 6, pozwala klientowi na dostęp do publikowanych zasobów. Na Rys. 2. przedstawiono przepływ poświadczeń pomiędzy klientem, serwerem TMG 2010, a serwerami docelowymi, wymagającymi dodatkowego uwierzytelniania wewnątrz komponentów serwera TMG 2010.
.jpg "Przepływ poświadczeń pomiędzy klientem, serwerem TMG 2010 a serwerami docelowymi, wymagającymi dodatkowego uwierzytelniania")
Rys. 2. Przepływ poświadczeń pomiędzy klientem, serwerem TMG 2010 a serwerami docelowymi, wymagającymi dodatkowego uwierzytelniania.
Tabela 1. Możliwe kombinacje metod uwierzytelnia wraz z możliwością przekazywania poświadczeń do serwerów docelowych oraz dostępnymi dla danego mechanizmu weryfikatorami.
| Metoda podawania poświadczeń przez klienta | Weryfikator | Delegacja poświadczeń – potencjalnie możliwe opcje |
Forms-based authentication (password only) Basic |
Active Directory (Windows) Active Directory (LDAP) RADIUS |
No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Basic NTLM Negotiate Kerberos constrained delegation |
Digest Integrated |
Active Directory (Windows) | No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Kerberos constrained delegation |
| Forms-based authentication with passcode | SecurID RADIUS one-time password |
No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly SecurID Kerberos constrained delegation |
| Forms-based authentication (passcode and password) | SecurID RADIUS one-time password |
No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Basic NTLM Negotiate SecurID |
| Client certificate | Active Directory (Windows) | No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Kerberos constrained delegation |
Lista wszystkich dostępnych opcji przekazywania poświadczeń dostępna jest, dla reguły publikacji zasobu, w zakładce Authentication Delegation. Przykład przedstawia Rys. 3.
.jpg "Widok zakładki Authentication Delegation dla przykładowej reguły publikacji serwera WWW")
Rys. 3. Widok zakładki Authentication Delegation dla przykładowej reguły publikacji serwera WWW.
Tabela 2. Mechanizmy przekazywania poświadczeń.
| Authentication Delegation | Wyjaśnienie |
| Basic authentication | Serwer TMG 2010 użyje metody Basic Authentication do uwierzytelnienia klienta, pragnącego uzyskać dostęp do publikowanego serwera WWW. Publikowany serwer również musi mieć włączone uwierzytelnianie metodą Basic. |
| No delegation, but client may authenticate directly | Jeżeli serwer HTTP wymaga uwierzytelnienia, serwer TMG 2010 prześle, w sposób przezroczysty, żądanie uwierzytelnienia do klienta i zwróci je z powrotem do serwera. TMG 2010 nie odpowiada w imieniu klienta. |
| No delegation, and client cannnot authenticate directly | Jeżeli serwer HTTP wymaga uwierzytelnienia, serwer TMG 2010 nie prześle tego żądania do klienta. Użytkownik nie będzie wówczas informowany o konieczności uwierzytelnienia się. Połączenie zostanie więc odrzucone. |
| NTLM authentication | Serwer TMG 2010 skorzysta z mechanizmu NTLM w celu uwierzytelnienia klienta, pragnącego uzyskać dostęp do publikowanego serwera Web. Publikowany serwer musi mieć włączone uwierzytelnianie NTLM. Jeżeli ten serwer to IIS, to musi być włączona opcja Windows authentication. |
| Negotiate (Kerberos/NTLM) | Serwer TMG 2010 wykorzysta mechanizm uwierzytelnienia negocjowanego (SPNEGO) w celu uwierzytelnienia klienta, pragnącego uzyskać dostęp do publikowanego serwera Web. Jako pierwszy zostanie wybrany Kerberos. Jeżeli nie zostanie przyznany bilet dostępu do usługi TGS, nastąpi przełączenie do uwierzytelnienia metodą NTLM. Jeżeli ten serwer to IIS, zatem musi być włączona opcja Windows authentication. Dodatkowo, dla uwierzytelniania Kerberos, należy podać parametr Service Principal Name (SPN), wykorzystywany przez serwer TMG 2010 w celu uwierzytelniania. Np. dla protokołu http: http/secure.test.com |
| Kerberos Constrained Delegation | Serwer TMG 2010 traktowany jest jako zaufany w kwestii delegowania. Zatem, to TMG 2010 uwierzytelnia się w imieniu użytkownika końcowego. Serwer TMG 2010 w konfiguracji Active Directory musi mieć zaznaczoną opcję delegacji zaufania. Publikowany serwer Web musi akceptować uwierzytelnianie protokołem Kerberos. Jeżeli ten serwer to IIS, zatem musi być włączona opcja Windows authentication. W celu uwierzytelniania Kerberos należy podać parametr Service Principal Name (SPN), wykorzystywany przez serwer TMG 2010 w celu uwierzytelniania. Np. dla protokołu http: http/secure.test.com |
Tabela 3. Zestawienie opcji konfiguracyjnych listenera, reguły oraz opcji uwierzytelniania na serwerze docelowym.
| Na listenerze | Na regule (authentication delegation) | Na serwerze docelowym | Uwagi |
| BASIC | BASIC | BASIC | |
| BASIC | NTLM | (Windows Authentication) | |
| BASIC | Negotiate (Kerberos/NTLM) | (Windows Authentication) | |
| BASIC | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| Digest | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| Integrated | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| BASIC + Digest | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| BASIC + Integrated | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| DIGEST + Intrated | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| BASIC + DIGEST + Interated | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| FormBased | BASIC | BASIC | |
| FormBased | NTLM | (Windows Authentication) | |
| FormBased | Negotiate (Kerberos/NTLM) | (Windows Authentication) | |
| FormBased | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
| FormBased with RADIUS OTP | BASIC | BASIC | Mechanizm RADIUS OTP będzie omawiany w oddzielnej części |
| FormBased with RADIUS OTP | NTLM | (Windows Authentication) | Mechanizm RADIUS OTP będzie omawiany w oddzielnej części |
| FormBased with RADIUS OTP | Negotiate (Kerberos/NTLM) | (Windows Authentication) | Mechanizm RADIUS OTP będzie omawiany w oddzielnej części |
| Certyfikat | Kerberos constrained delegation | (Windows Authentication) | Tak (ale wymaga utworzenia SPN) |
Przykład 1. Bezpośrednie uwierzytelnienie w trybie BASIC na docelowym serwerze Web – bez uwierzytelniania na TMG 2010.
Przykład pierwszy ma pokazać przekazywanie poświadczeń przez serwer TMG 2010 w trybie transparentnym. TMG 2010 nie będzie uwierzytelniać użytkownika, ale dokona inspekcji, czy ruch sieciowy wymaga uwierzytelniania, czy też nie. Na listenerze ustawiona została opcja — brak uwierzytelniania (ang. No Authentication). Scenariusz ten został przedstawiony na Rys. 4.
.jpg "Właściwości zaawansowane listenera")
Rys. 4. Właściwości zaawansowane listenera.
Właściwości reguły publikacji serwera Web, związane z przekazywaniem poświadczeń, przedstawione zostały na Rys. 5. Reguła musi działać na wszystkich użytkowników (zarówno tych uwierzytelnionych, jak i nieuwierzytelnionych), należy zatem pamiętać, aby w zakładce Users dodany został obiekt All Users.
.jpg "Właściwości reguły publikacji serwera Web — zakładka Listener") |
.jpg "Właściwości reguły publikacji serwera Web — zakładka Listener") |
Rys. 5. Właściwości reguły publikacji serwera Web — zakładka Listener.**
W celu udzielenia zezwolenia na uwierzytelnianie się klienta, po protokole http, na serwerze docelowym należy zmodyfikować właściwości zaawansowane w zakładce Listener. Opcje uwierzytelniania klienta przedstawione zostały na Rys. 6.
.jpg "Właściwości zaawansowane listenera — opcje uwierzytelniania klienta")
Rys. 6. Właściwości zaawansowane listenera — opcje uwierzytelniania klienta.
Jeżeli opcja listenera Allow client authentication over HTTP nie zostanie włączona, możemy spodziewać się komunikatu błędu typu 12250. Na Rys. 7. przedstawiono wygląd zakładki Authentication Delegation. W celu włączenia przekazywania poświadczeń w trybie transparentnym, należy wybrać opcję No delegation, but client may authenticate directly. Opcja ta wymusza brak uwierzytelniania na serwerze TMG 2010, ale dostępne jest bezpośrednie uwierzytelnienie w serwerze docelowym.
.jpg "Właściwości zaawansowane reguły publikacji serwera Web")
Rys. 7. Właściwości zaawansowane reguły publikacji serwera Web.
Serwery Web mogą być wyposażone w różne metody uwierzytelniania. Na Rys. 8. i Rys. 9. zaprezentowano metody uwierzytelniania serwera IIS 7.5.
.jpg "Metody uwierzytelniania na serwerze IIS 7.5 na poziomie określonej witryny")
Rys. 8. Metody uwierzytelniania na serwerze IIS 7.5 na poziomie określonej witryny.
Na poziomie całego serwera IIS można włączyć uwierzytelnianie bazujące na certyfikatach.
.jpg "Metody uwierzytelniania na serwerze IIS 7.5 na poziomie serwera")
Rys. 9. Metody uwierzytelniania na serwerze IIS 7.5 na poziomie serwera.
Poniższy przykład prezentuje informacje pobrane z event loga kontrolera domeny oraz serwera docelowego web.test.local, publikowanego przez serwer TMG jako www.test.com.
Faza I - prezentuje żądanie uwierzytelniania użytkownika jan.kowalski w domenie korzystając z negocjowanego mechanizmu uwierzytelniania.
W event logu na serwerze WEB odnotowane zostanie zdarzenie o numerze:
4648 – A logon wa attempt using explicit credentials
Account Whose Credentials Were Used
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Network Address: 192.168.0.254
Source Port: 13825
Detailed Authentication Information
Logon Process: Advapi
Authentication Package: Negotiate
Faza II - prezentuje przekazanie żądania uwierzytelnienia z serwera WEB do kontrolera domeny.
Poniżej przedstawiono żądanie widziane od strony kontrolera domeny. Do uwierzytelniania został wykorzystany Kerberos, gdyż serwer WEB jest członkiem domeny.
4768 – A Kerberos authentication ticket (TGT) was requested
Account Information:
Account Name: jan.kowalski
Supplied Realm Name: test.local
User ID: TEST\jan.kowalski
Service Information:
Service Name: krbtgt
** Service ID: TEST\krbtgt**
Faza III - po zweryfikowaniu biletu TGT (ang. Ticket Granting Ticket), nastąpi żądanie wygenerowania biletu dostępu do usługi TGS (ang. Ticket Granting Service).
4769 – A Kerberos service ticket was requested
Account Information:
Account Name: jan.kowalski@TEST.LOCAL
Account Domain: TEST.LOCAL
Service Information:
Service Name: WEB$
Service ID: TEST\WEB$
Faza IV – użytkownik zostaje uwierzytelniony w event logu na serwerze WEB, odnotowane zostanie wówczas zdarzenie o numerze:
4624 – An account wa successfully loggged on
New Logon
Security ID: TEST\jan.kowalski
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Workstation Name: WEB
Source Network Address: 192.168.0.254
Source Port: 13825
Detailed Authentication Information
Logon Process: Advapi
Authentication Package: Negotiate
Przykład 2. Bezpośrednie uwierzytelnianie typu Wdigest na serwerze WEB – bez uwierzytelniania na TMG 2010.
Na serwerze WEB w event logu pojawia się tylko wpis:
4624 – An account wa successfully loggged on
New Logon
Security ID: TEST\jan.kowalski
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Workstation Name: -
Source Network Address: 192.168.0.254
Source Port: 13847
Detailed Authentication Information
Logon Process: WDIGEST
Authentication Package: WDigest
Na kontrolerze domeny, pojawia się informacja o uwierzytelnieniu metodą WDigest.
4776 – The Computer attempt to validate the credentials for an account
Authentication Package: Wdigest
Logon account: jan.kowalski
Source Workstation: WEB
Przykład 3. Bezpośrednie uwierzytelnianie typu Windows Integrated na serwerze WWW – bez uwierzytelniania na TMG 2010.
Przykład kolejny to konfiguracja, w której serwer docelowy WWW ma włączony mechanizm zintegrowanego uwierzytelniania Windows (Windows Integrated Authentication). Pominiemy już komunikację pomiędzy przeglądarką internetową a serwerem WEB, wysyłaną po protokole HTTP.
Na serwerze WEB w event logu pojawia się tylko wpis:
4624 – An account wa successfully loggged on
New Logon
Security ID: TEST\jan.kowalski
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Workstation Name: KLIENT
Source Network Address: 192.168.0.254
Source Port: 13856
Detailed Authentication Information
Logon Process: NtLmSsp
Authentication Package:NTLM
Package Name (NTLM only): NTLM v2
KeyLength: 128
Na kontrolerze domeny pojawia się wpis:
4776 – The Computer attempt to validate the credentials for an account
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: jan.kowalski
Source Workstation: KLIENT
Jak widać z przykładu 3, domyślnym protokołem, przy tego typu konfiguracji, będzie NTLM (wersja zależna jest od typu serwera WEB oraz typu klienta).
Przykład 4. Uwierzytelnianie Basic na serwerze ISA. Uwierzytelnianie również metodą Basic na serwerze WWW.
Kolejny przykład to uwierzytelnianie realizowane już na serwerze TMG 2010 metodą Basic, wraz z przekazywaniem poświadczeń do serwera docelowego, również metodą BASIC.
Faza I – uwierzytelnienie użytkownika w TMG 2010.
4648 – A logon wa attempt using explicit credentials
Subject:
Security ID: NETWORK SERVICE
Account Name: TMG$
Account Domain: TEST
Account Whose Credentials Were Used
Account Name: jan.kowalski
Account Domain: TEST
Faza II – komunikacja z kontrolerem domeny.
4768 – A Kerberos authentication ticket (TGT) was requested (z TMG 2010)
4769 – A Kerberos service ticket was requested (odpowiedz kontrolera domeny do TMG 2010)
Faza III – uwierzytelnienie w serwerze docelowym realizowane przez TMG 2010 (przekazanie poświadczeń, które podał użytkownik końcowy).
4768 – A Kerberos authentication ticket (TGT) was requested (z serwera docelowego)
4769 – A Kerberos service ticket was requested (odpowiedz kontrolera domeny do serwra docelowego)
Faza IV - uwierzytelnienie w serwerze docelowym zakończone sukcesem.
4624 – An account wa successfully loggged on
New Logon
Security ID: TEST\jan.kowalski
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Workstation Name: WEB
Source Network Address: 192.168.0.254
Source Port: 13825
Detailed Authentication Information
Logon Process: Advapi
Authentication Package: Negotiate
Tym razem, również w obu przypadkach, wykorzystany został mechanizm Kerberos, gdyż TMG jak i serwer docelowy WEB są członkami domeny.
Przykład 5. Uwierzytelnianie Basic na serwerze ISA. Uwierzytelnianie metodą NTLM na serwerze WWW.
Faza I – uwierzytelnienie użytkownika w TMG 2010.
4648 – A logon wa attempt using explicit credentials
Subject:
Security ID: NETWORK SERVICE
Account Name: TMG$
Account Domain: TEST
Account Whose Credentials Were Used
Account Name: jan.kowalski
Account Domain: test.local
Target Server:
Target Server Name: WEB.test.local
Additional Information: WEB.test.local
Faza II – komunikacja z kontrolerem domeny.
4768 – A Kerberos authentication ticket (TGT) was requested (z TMG 2010)
4769 – A Kerberos service ticket was requested (odpowiedz kontrolera domeny do TMG 2010)
4776 – Credential Validation (negocjacja protokołu uwierzytelniania – tu z założenia NTLM)
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: jan.kowalski
Source Workstation: TMG
Faza III – uwierzytelnianie w serwerze docelowym z wykorzystaniem NTLM v2.
4624 – An account wa successfully loggged on
New Logon
Security ID: TEST\jan.kowalski
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Workstation Name: TMG
Source Network Address: 192.168.0.254
Source Port: 13856
Detailed Authentication Information
Logon Process: NtLmSsp
Authentication Package:NTLM
Package Name (NTLM only): NTLM v2
KeyLength: 0
Przykład 6. Uwierzytelnianie Basic na serwerze ISA. Uwierzytelnianie metodą Negotiate (Kerberos/NTLM) na docelowym serwerze WWW.
Wybór delegacji poświadczeń metodą Negotiate (Kerberos/NTLM) został zaprezentowany na Rys. 10. Komponent SPN należy utworzyć, gdy planujemy uwierzytelniać z wykorzystaniem Kerberosa, dla NTLM nie jest on wymagany.
.jpg "Delegacja poświadczeń metodą Negotiate (Kerberos/NTLM)")
Rys. 10. Delegacja poświadczeń metodą Negotiate (Kerberos/NTLM).
Faza I – uwierzytelnienia użytkownika w TMG 2010.
4648 – A logon wa attempt using explicit credentials
Faza II – komunikacja z kontrolerem domeny.
4768 – A Kerberos authentication ticket (TGT) was requested (z TMG 2010)
4769 – A Kerberos service ticket was requested (odpowiedz kontrolera domeny do TMG 2010)
Ponowne żądanie biletu (Negocjacja protokołu uwierzytelniania)
4768 – A Kerberos authentication ticket (TGT) was requested (z TMG 2010)
4776 – Credential Validation
Faza III – uwierzytelnianie w serwerze docelowym.
4624 – An account wa successfully loggged on – zrealizowanie za pomocą NTLMv2
Uwaga informacyjna
Mimo że zdefiniowane zostało SPN, to uwierzytelnianie za pomocą NTLMv2 i tak nastąpi.
Przykład 7. Uwierzytelnianie Basic na serwerze ISA. Uwierzytelnianie metodą Kerberos Constrained Delegation na docelowym serwerze WWW.
W celu skonfigurowania mechanizmu uwierzytelniania typu Kerberos Constrained Delegation, należy spełnić dwa warunki. Wszystkie serwery, uczestniczące w przekazywaniu łańcucha poświadczeń, muszą być członkami domeny (łącznie z serwerem TMG 2010). Warunek drugi, to zdefiniowanie parametru SPN dla określonej usługi oraz docelowego serwera, na którym ma następować uwierzytelnianie. Termin SPN (ang. Service Principal Name) bywa określany czasami jako nazwa główna usługi. Nazwy SPN są powiązane z wystawcami zabezpieczeń (czyli kontami użytkowników lub komputerów), w kontekście których, pracuje dana usługa.
Korzystając z przystawki Active Directory Users and Computer na zakładce Delegation właściwości konta komputera, należy dokonać zmian sposobu delegacji uprawnień. Serwery członkowskie w domenie nie posiadają domyślnie takiego uprawnienia (opcja Do not trust this computer for delegation), posiadają je natomiast kontrolery domeny. W omawianym przykładzie, należy jawnie zadeklarować fakt przekazywania poświadczeń po protokole http. Scenariusz został zaprezentowany na Rys. 11. Po lewej stronie Rys. 11. zaprezentowano domyślny wygląd zakładki delagation, po prawej zaś jego zmodyfikowaną postać.
.jpg "Włączenie delegowania poświadczeń od strony kontrolera domeny dla konta serwera TMG 2010") |
.jpg "Włączenie delegowania poświadczeń od strony kontrolera domeny dla konta serwera TMG 2010") |
Rys. 11. Włączenie delegowania poświadczeń od strony kontrolera domeny dla konta serwera TMG 2010.**
W momencie wyboru przekazywania poświadczeń metodą Kerberos Constrained Delegation*, serwer TMG poinformuje administratora o konieczności delegacji uprawnień komunikatem pokazanym na Rys. 12.*
.jpg "Komunikat informujący administratora o konieczności włączenia delegacji uprawnień")
Rys. 12. Komunikat informujący administratora o konieczności włączenia delegacji uprawnień.
W przypadku, gdy nazwa usługi SPN, zdefiniowana w regule publikacji, nie będzie zgadzać się z nazwą podaną w zakładce Delegation (konto komputera na kontrolerze domeny), wówczas przy testowaniu reguły publikacji możemy spodziewać się komunikatu błędu, zilustrowanego na Rys. 13.
.jpg "Komunikat błędu informujący o braku lub niezgodności zdefiniowanych elementów spn lub braku włączonej delegacji uprawnień")
Rys. 13. Komunikat błędu informujący o braku lub niezgodności zdefiniowanych elementów spn lub braku włączonej delegacji uprawnień.
Faza I – uwierzytelnianie użytkownika w TMG.
4648 – A logon wa attempt using explicit credentials
Faza II – komunikacja z kontrolerem domeny.
4768 – A Kerberos authentication ticket (TGT) was requested
Account Information:
Account Name: jan.kowalski
Supplied Realm Name: test.local
User ID: TEST\jan.kowalski
Service Information:
Service Name: krbtgt
** Service ID: TEST\krbtgt**
4769 – A Kerberos service ticket was requested
Account Information:
Account Name: jan.kowalski@TEST.LOCAL
Account Domain: TEST.LOCAL
Service Information:
Service Name: TMG$
Service ID: TEST\TMG$
4769 – A Kerberos service ticket was requested
Account Information:
Account Name: TMG$@TEST.LOCAL
Account Domain: TEST.LOCAL
Service Information:
Service Name: TMG$
Service ID: TEST\TMG$
4769 – A Kerberos service ticket was requested
Account Information:
Account Name: TMG$@TEST.LOCAL
Account Domain: TEST.LOCAL
Service Information:
Service Name: WEB$
Service ID: TEST\WEB$
Additional Information
Transited Services:
tmg$@TEST.LOCAL
Powyższy komunikat związany jest z mechanizmem uwierzytelniania, a właściwie uwierzytelniania jednego obiektu w imieniu drugiego obiektu. Tu, w scenariuszu uwierzytelnia się serwer TMG (dokładniej użytkownik NETWORK SERVICE, korzystając z hasła konta komputera TMG w imieniu użytkownika jan.kowalski, co widać w fazie III, poniżej).
Faza III - uwierzytelnianie w serwerze docelowym.
4624 – An account wa successfully loggged on
New Logon
Security ID: TEST\jan.kowalski
Account Name: jan.kowalski
Account Domain: TEST
Network Information:
Workstation Name:
Source Network Address: adres_ip_komputera_klienta
Source Port: jakis_numer_portu
Detailed Authentication Information
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services:
Tmg$@TEST.LOCAL
Package Name (NTLM only): -
KeyLength: 0
Podsumowanie
W niniejszej części omówiono zagadnienie przekazywania poświadczeń przez serwer TMG do serwerów docelowych. Na siedmiu przykładach pokazano, najczęściej wykorzystywane, opcje uwierzytelniania klasycznego z wykorzystaniem komponentów wbudowanych wraz z możliwością przekazywania poświadczeń do wnętrza sieci LAN lub DMZ, celem uwierzytelniania w serwerze docelowym.
W następnej części zaczniemy omawianie zagadnień publikacji serwerów pocztowych oraz komponentów serwera Exchange.