Zintegrowane uwierzytelnianie systemu Windows z ochroną rozszerzoną

Wprowadzono ulepszenia wpływające na sposób obsługi zintegrowanego HttpWebRequestuwierzytelniania systemu Windows przez klasy , , HttpListenerSmtpClient, SslStream, NegotiateStreami powiązane w System.Net powiązanych przestrzeniach nazw i. Dodano obsługę rozszerzonej ochrony w celu zwiększenia bezpieczeństwa.

Te zmiany mogą mieć wpływ na aplikacje korzystające z tych klas w celu tworzenia żądań internetowych i odbierania odpowiedzi, w których jest używane zintegrowane uwierzytelnianie systemu Windows. Ta zmiana może również mieć wpływ na serwery internetowe i aplikacje klienckie skonfigurowane do korzystania ze zintegrowanego uwierzytelniania systemu Windows.

Te zmiany mogą również mieć wpływ na aplikacje, które używają tych klas do tworzenia innych typów żądań i odbierania odpowiedzi, w których jest używane zintegrowane uwierzytelnianie systemu Windows.

Zmiany w zakresie obsługi rozszerzonej ochrony są dostępne tylko dla aplikacji w systemach Windows 7 i Windows Server 2008 R2. Funkcje rozszerzonej ochrony nie są dostępne we wcześniejszych wersjach systemu Windows.

Omówienie

Projekt zintegrowanego uwierzytelniania systemu Windows umożliwia uniwersalne odpowiedzi na żądanie poświadczeń, co oznacza, że mogą być ponownie używane lub przekazywane. Odpowiedzi na wyzwania powinny być konstruowane co najmniej z określonymi informacjami docelowymi, a najlepiej także z niektórymi informacjami specyficznymi dla kanału. Usługi mogą następnie zapewnić rozszerzoną ochronę, aby upewnić się, że odpowiedzi na żądanie poświadczeń zawierają informacje specyficzne dla usługi, takie jak główna nazwa usługi (SPN). Dzięki tym informacjom w wymianach poświadczeń usługi są w stanie lepiej chronić przed złośliwym użyciem odpowiedzi na żądanie poświadczeń, które mogły zostać nieprawidłowo użyte.

Projekt rozszerzonej ochrony to rozszerzenie protokołów uwierzytelniania zaprojektowanych w celu wyeliminowania ataków przekazywania uwierzytelniania. Koncentruje się on na koncepcji informacji o powiązaniach kanałów i usług.

Ogólne cele są następujące:

  1. Jeśli klient zostanie zaktualizowany w celu zapewnienia rozszerzonej ochrony, aplikacje powinny dostarczyć informacje o powiązaniu kanału i powiązaniu usługi do wszystkich obsługiwanych protokołów uwierzytelniania. Informacje o powiązaniu kanału można podać tylko wtedy, gdy istnieje kanał (TLS) do powiązania. Należy zawsze podać informacje o powiązaniu usługi.

  2. Zaktualizowane serwery, które są prawidłowo skonfigurowane, mogą zweryfikować informacje o kanale i powiązaniu usługi, gdy są obecne w tokenie uwierzytelniania klienta i odrzucić próbę uwierzytelniania, jeśli powiązania kanału nie są zgodne. W zależności od scenariusza wdrażania serwery mogą weryfikować powiązanie kanału, powiązanie usługi lub oba te elementy.

  3. Zaktualizowane serwery mają możliwość akceptowania lub odrzucania żądań klientów na poziomie podrzędnym, które nie zawierają informacji o powiązaniu kanału na podstawie zasad.

Informacje używane przez rozszerzoną ochronę składają się z jednej lub obu następujących części:

  1. Token powiązania kanału lub CBT.

  2. Informacje o powiązaniu usługi w postaci głównej nazwy usługi lub nazwy SPN.

Informacje o powiązaniu usługi to wskazanie intencji klienta do uwierzytelniania w określonym punkcie końcowym usługi. Jest on przekazywany z klienta do serwera z następującymi właściwościami:

  • Wartość nazwy SPN musi być dostępna dla serwera wykonującego uwierzytelnianie klienta w postaci zwykłego tekstu.

  • Wartość głównej nazwy usługi jest publiczna.

  • Nazwa SPN musi być kryptograficznie chroniona podczas przesyłania, tak aby atak typu man-in-the-middle nie mógł wstawić, usunąć ani zmodyfikować jego wartości.

CBT jest właściwością zewnętrznego bezpiecznego kanału (takiego jak TLS) używanego do wiązania (powiązania) z konwersacją za pośrednictwem wewnętrznego kanału uwierzytelnionego przez klienta. CbT musi mieć następujące właściwości (zdefiniowane również przez IETF RFC 5056):

  • Gdy istnieje kanał zewnętrzny, wartość CBT musi być właściwością identyfikującą kanał zewnętrzny lub punkt końcowy serwera, niezależnie docierając zarówno przez strony klienta, jak i serwera konwersacji.

  • Wartość CBT wysłanego przez klienta nie może mieć wpływu na osobę atakującą.

  • Nie ma żadnych gwarancji dotyczących tajemnicy wartości CBT. Nie oznacza to jednak, że wartość powiązania usługi, a także informacje o powiązaniu kanału mogą być zawsze analizowane przez inne, ale serwer wykonujący uwierzytelnianie, ponieważ protokół obsługujący CBT może je szyfrować.

  • CbT musi być kryptograficznie integralność chroniona podczas przesyłania, tak aby osoba atakująca nie może wstawić, usunąć ani zmodyfikować jego wartości.

Powiązanie kanału jest realizowane przez klienta przekazującego nazwę SPN i CBT do serwera w sposób odporny na naruszenia. Serwer weryfikuje informacje o powiązaniu kanału zgodnie z jego zasadami i odrzuca próby uwierzytelniania, dla których nie uważa się za zamierzony cel. W ten sposób dwa kanały stają się powiązane kryptograficznie.

Aby zachować zgodność z istniejącymi klientami i aplikacjami, można skonfigurować serwer tak, aby zezwalał na próby uwierzytelniania przez klientów, którzy jeszcze nie obsługują rozszerzonej ochrony. Jest to nazywane konfiguracją "częściowo wzmocnioną" w przeciwieństwie do konfiguracji "w pełni wzmocnionej".

Wiele składników w przestrzeniach nazw i System.Net.Security wykonuje zintegrowane uwierzytelnianie systemu Windows w System.Net imieniu aplikacji wywołującej. W tej sekcji opisano zmiany składników System.Net w celu dodania rozszerzonej ochrony w ich użyciu zintegrowanego uwierzytelniania systemu Windows.

Rozszerzona ochrona jest obecnie obsługiwana w systemie Windows 7. Udostępniono mechanizm, aby aplikacja mogła określić, czy system operacyjny obsługuje rozszerzoną ochronę.

Zmiany w zakresie rozszerzonej ochrony

Proces uwierzytelniania używany z zintegrowanym uwierzytelnianiem systemu Windows, w zależności od używanego protokołu uwierzytelniania, często obejmuje wyzwanie wystawione przez komputer docelowy i wysyłane z powrotem do komputera klienckiego. Rozszerzona ochrona dodaje nowe funkcje do tego procesu uwierzytelniania

System.Security.Authentication.ExtendedProtection Przestrzeń nazw zapewnia obsługę uwierzytelniania przy użyciu rozszerzonej ochrony aplikacji. Klasa ChannelBinding w tej przestrzeni nazw reprezentuje powiązanie kanału. Klasa ExtendedProtectionPolicy w tej przestrzeni nazw reprezentuje rozszerzone zasady ochrony używane przez serwer do sprawdzania poprawności przychodzących połączeń klientów. Inne składowe klasy są używane z rozszerzoną ochroną.

W przypadku aplikacji serwerowych te klasy obejmują następujące elementy:

Element ExtendedProtectionPolicy , który ma następujące elementy:

  • Właściwość wskazująca OSSupportsExtendedProtection , czy system operacyjny obsługuje zintegrowane uwierzytelnianie systemu Windows z rozszerzoną ochroną.

  • Wartość wskazująca PolicyEnforcement , kiedy należy wymusić rozszerzone zasady ochrony.

  • ProtectionScenario Wartość wskazująca scenariusz wdrożenia. Ma to wpływ na sposób sprawdzania rozszerzonej ochrony.

  • Opcjonalnie ServiceNameCollection , która zawiera niestandardową listę spN, która jest używana do dopasowania do nazwy SPN dostarczonej przez klienta jako docelowego celu uwierzytelniania.

  • Opcjonalnie ChannelBinding , który zawiera niestandardowe powiązanie kanału do użycia na potrzeby walidacji. Ten scenariusz nie jest typowym przypadkiem

System.Security.Authentication.ExtendedProtection.Configuration Przestrzeń nazw zapewnia obsługę konfiguracji uwierzytelniania przy użyciu rozszerzonej ochrony aplikacji.

Wprowadzono szereg zmian funkcji w celu zapewnienia rozszerzonej ochrony w istniejącej System.Net przestrzeni nazw. Są to m.in. następujące zmiany:

Wprowadzono zmianę funkcji w celu zapewnienia rozszerzonej ochrony aplikacji klienckich SMTP w istniejącej System.Net.Mail przestrzeni nazw:

  • TargetName Właściwość w SmtpClient klasie, która reprezentuje nazwę SPN do użycia do uwierzytelniania podczas korzystania z rozszerzonej ochrony dla aplikacji klienckich SMTP.

Wprowadzono szereg zmian funkcji w celu zapewnienia rozszerzonej ochrony w istniejącej System.Net.Security przestrzeni nazw. Są to m.in. następujące zmiany:

Dodano SmtpNetworkElement właściwość do obsługi konfiguracji rozszerzonej ochrony dla klientów SMTP w System.Net.Security przestrzeni nazw.

Rozszerzona ochrona aplikacji klienckich

Rozszerzona obsługa ochrony dla większości aplikacji klienckich odbywa się automatycznie. Klasy HttpWebRequest i SmtpClient obsługują rozszerzoną ochronę za każdym razem, gdy podstawowa wersja systemu Windows obsługuje rozszerzoną ochronę. Wystąpienie HttpWebRequest wysyła nazwę SPN skonstruowaną z klasy Uri. Domyślnie SmtpClient wystąpienie wysyła nazwę SPN skonstruowaną z nazwy hosta serwera poczty SMTP.

W przypadku uwierzytelniania niestandardowego aplikacje klienckie mogą używać HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) metod lub HttpWebRequest.GetRequestStream(TransportContext) w HttpWebRequest klasie, które umożliwiają pobieranie TransportContext i CBT przy użyciu GetChannelBinding metody .

Nazwa SPN używana do zintegrowanego uwierzytelniania systemu Windows wysyłanego HttpWebRequest przez wystąpienie do danej usługi może zostać zastąpiona przez ustawienie CustomTargetNameDictionary właściwości .

Za TargetName pomocą właściwości można ustawić niestandardową nazwę SPN do użycia na potrzeby zintegrowanego uwierzytelniania systemu Windows dla połączenia SMTP.

Rozszerzona ochrona aplikacji serwera

HttpListener automatycznie udostępnia mechanizmy sprawdzania poprawności powiązań usługi podczas przeprowadzania uwierzytelniania HTTP.

Najbezpieczniejszym scenariuszem jest włączenie rozszerzonej ochrony prefiksów HTTPS:// . W tym przypadku ustaw HttpListener.ExtendedProtectionPolicyExtendedProtectionPolicy parametr na wartość z ustawioną PolicyEnforcement wartością WhenSupported lub Alwaysi ProtectionScenario ustaw TransportSelected wartość WhenSupported A w HttpListener trybie częściowo ze wzmocnionymi zabezpieczeniami, natomiast Always odpowiada trybowi z pełnym wzmocnionym zabezpieczeniami.

W tej konfiguracji, gdy żądanie jest kierowane do serwera za pośrednictwem zewnętrznego bezpiecznego kanału, kanał zewnętrzny jest odpytywane pod kątem powiązania kanału. To powiązanie kanału jest przekazywane do wywołań SSPI uwierzytelniania, które sprawdzają, czy powiązanie kanału w obiekcie blob uwierzytelniania jest zgodne. Istnieją trzy możliwe wyniki:

  1. Podstawowy system operacyjny serwera nie obsługuje rozszerzonej ochrony. Żądanie nie zostanie ujawnione aplikacji, a do klienta zostanie zwrócona nieautoryzowana odpowiedź (401). Komunikat zostanie zarejestrowany w HttpListener źródle śledzenia, określając przyczynę błędu.

  2. Wywołanie SSPI kończy się niepowodzeniem wskazującym, że klient określił powiązanie kanału, które nie jest zgodne z oczekiwaną wartością pobraną z kanału zewnętrznego, lub klient nie może podać powiązania kanału, gdy rozszerzone zasady ochrony na serwerze zostały skonfigurowane dla programu Always. W obu przypadkach żądanie nie zostanie ujawnione aplikacji, a do klienta zostanie zwrócona nieautoryzowana odpowiedź (401). Komunikat zostanie zarejestrowany w HttpListener źródle śledzenia, określając przyczynę błędu.

  3. Klient określa prawidłowe powiązanie kanału lub może nawiązać połączenie bez określania powiązania kanału, ponieważ rozszerzone zasady ochrony na serwerze są skonfigurowane z WhenSupported żądaniem jest zwracane do aplikacji do przetwarzania. Sprawdzanie nazwy usługi nie jest wykonywane automatycznie. Aplikacja może zdecydować się na przeprowadzenie własnej weryfikacji nazwy usługi przy użyciu ServiceName właściwości , ale w tych okolicznościach jest ona nadmiarowa.

Jeśli aplikacja wykonuje własne wywołania SSPI w celu przeprowadzenia uwierzytelniania na podstawie obiektów blob przekazanych tam i z powrotem w treści żądania HTTP i chce obsługiwać powiązanie kanału, musi pobrać oczekiwane powiązanie kanału z zewnętrznego bezpiecznego kanału przy użyciu polecenia HttpListener w celu przekazania go do natywnej funkcji Win32 AcceptSecurityContext . W tym celu użyj TransportContext właściwości i wywołaj GetChannelBinding metodę , aby pobrać cbt. Obsługiwane są tylko powiązania punktów końcowych. Jeśli zostanie określona inna Endpoint wartość, zostanie zgłoszony element NotSupportedException . Jeśli bazowy system operacyjny obsługuje powiązanie kanału, GetChannelBinding metoda zwróci zawijanie ChannelBindingSafeHandle wskaźnika do powiązania kanału odpowiedniego do przekazania funkcji AcceptSecurityContext jako elementu członkowskiego pvBuffer struktury SecBuffer przekazanej w parametrze pInput . Właściwość Size zawiera długość w bajtach powiązania kanału. Jeśli podstawowy system operacyjny nie obsługuje powiązań kanału, funkcja zwróci wartość null.

Innym możliwym scenariuszem jest włączenie rozszerzonej ochrony prefiksów, HTTP:// gdy serwery proxy nie są używane. W tym przypadku ustaw HttpListener.ExtendedProtectionPolicyExtendedProtectionPolicy parametr na wartość z ustawioną PolicyEnforcement wartością WhenSupported lub Alwaysi ProtectionScenario ustaw TransportSelected wartość WhenSupported A w HttpListener trybie częściowo ze wzmocnionymi zabezpieczeniami, natomiast Always odpowiada trybowi z pełnym wzmocnionym zabezpieczeniami.

Domyślna lista dozwolonych nazw usług jest tworzona na podstawie prefiksów zarejestrowanych w obiekcie HttpListener. Tę listę domyślną DefaultServiceNames można zbadać za pomocą właściwości . Jeśli ta lista nie jest kompleksowa, aplikacja może określić niestandardową kolekcję nazw usług w konstruktorze dla ExtendedProtectionPolicy klasy, która będzie używana zamiast domyślnej listy nazw usług.

W tej konfiguracji po wysłaniu żądania do serwera bez zewnętrznego uwierzytelniania bezpiecznego kanału odbywa się normalnie bez sprawdzania powiązania kanału. Jeśli uwierzytelnianie zakończy się pomyślnie, kontekst zostanie zapytany o nazwę usługi podaną przez klienta i zweryfikowaną na liście dopuszczalnych nazw usług. Istnieją cztery możliwe wyniki:

  1. Podstawowy system operacyjny serwera nie obsługuje rozszerzonej ochrony. Żądanie nie zostanie ujawnione aplikacji, a do klienta zostanie zwrócona nieautoryzowana odpowiedź (401). Komunikat zostanie zarejestrowany w HttpListener źródle śledzenia, określając przyczynę błędu.

  2. Podstawowy system operacyjny klienta nie obsługuje rozszerzonej ochrony. WhenSupported W konfiguracji próba uwierzytelnienia zakończy się pomyślnie, a żądanie zostanie zwrócone do aplikacji. W konfiguracji próba uwierzytelnienia zakończy się niepowodzeniem Always . Żądanie nie zostanie ujawnione aplikacji, a do klienta zostanie zwrócona nieautoryzowana odpowiedź (401). Komunikat zostanie zarejestrowany w HttpListener źródle śledzenia, określając przyczynę błędu.

  3. Podstawowy system operacyjny klienta obsługuje rozszerzoną ochronę, ale aplikacja nie określiła powiązania usługi. Żądanie nie zostanie ujawnione aplikacji, a do klienta zostanie zwrócona nieautoryzowana odpowiedź (401). Komunikat zostanie zarejestrowany w HttpListener źródle śledzenia, określając przyczynę błędu.

  4. Klient określił powiązanie usługi. Powiązanie usługi jest porównywane z listą dozwolonych powiązań usługi. Jeśli jest ono zgodne, żądanie zostanie zwrócone do aplikacji. W przeciwnym razie żądanie nie zostanie ujawnione aplikacji, a do klienta zostanie automatycznie zwrócona nieautoryzowana odpowiedź (401). Komunikat zostanie zarejestrowany w HttpListener źródle śledzenia, określając przyczynę błędu.

Jeśli takie proste podejście przy użyciu dozwolonej listy dopuszczalnych nazw usług jest niewystarczające, aplikacja może zapewnić własną walidację nazwy usługi, wysyłając ServiceName zapytanie do właściwości. W przypadkach 1 i 2 powyżej właściwość zwróci nullwartość . W przypadku 3 zwróci pusty ciąg. W przypadku 4 zostanie zwrócona nazwa usługi określona przez klienta.

Te rozszerzone funkcje ochrony mogą być również używane przez aplikacje serwera do uwierzytelniania z innymi typami żądań i gdy są używane zaufane serwery proxy.

Zobacz też