2013-08-14 13 views
5

Kolega zapytał mnie dzisiaj, jak skonfigurować usługi IIS 7.5 do korzystania ze zintegrowanego uwierzytelniania systemu Windows z podszywaniem się pod prostą stronę intranetową z tylko statyczną zawartością, która jest ograniczone do określonej grupy w Active Directory (np. "Administratorzy").Skonfiguruj uwierzytelnianie systemu Windows II, aby zwracał HTTP 403 zamiast HTTP 401, aby odmówić zgody użytkownikowi uwierzytelnionemu.

Okazuje się, że usługi IIS wysyłają odpowiedź HTTP 401, gdy uwierzytelniony użytkownik nie ma uprawnień do zasobu żądania. Odmowa uprawnień może wynikać z ACL pliku NTFS lub z listy ACL system.webServer/security/authorization zdefiniowanej w konfiguracji IIS.

Wszystkie najważniejsze przeglądarki wydają się interpretować to 401 jako oznaczające, że użytkownik końcowy podał niepoprawne dane logowania do nazwy użytkownika/hasła systemu Windows, a tym samym prosi użytkownika o podanie nazwy użytkownika/hasła. IE wydaje się monitować do 3 razy przed wyświetleniem treści/treści odpowiedzi 401. Wydaje się, że Chrome i Safari wielokrotnie monitują użytkownika.

Może to być mylące dla użytkowników końcowych, którzy wielokrotnie wprowadzają prawidłową nazwę użytkownika/hasło systemu Windows, aby ponownie uzyskać monit.

Lepszym sposobem byłoby dla IIS zwraca HTTP 403 zamiast HTTP 401:

403 Forbidden

Serwer rozumieć żądanie, ale odmawia go wypełnić. Autoryzacja nie będzie musiała być powtarzana, ani nie będzie udzielana pomoc ani żądanie.

Źródło: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4

Jak skonfigurować IIS zintegrowane uwierzytelnianie systemu Windows do wysyłania HTTP 401 niepowodzeń logowania i HTTP 403 o zezwolenie odmawia?

Odpowiedz

6

Co nie działa

Próbowałem prawie każdy permutacji konfiguracji IIS bez powodzenia. Sprawdziłem ustawienia dostawcy uwierzytelniania systemu Windows, takie jak NTLM, Negotiate i Negotiate: Kerberos. Żaden z nich nie robił tego. Nie jest to zbyt zaskakujące, ponieważ przeglądarki decydują się ponownie spróbować uwierzytelnienia, mimo że prawdopodobnie nie powinny.

401 Nieuprawnione

Żądanie wymaga uwierzytelnienia użytkownika. Odpowiedź MUSI zawierać pole nagłówka WWW-Authenticate (sekcja 14.47) zawierające wyzwanie dotyczące żądanego zasobu. Klient MOŻE powtórzyć żądanie z odpowiednim polem nagłówka Authorization (rozdział 14.8). Jeśli żądanie zawiera już poświadczenia autoryzacji, , wówczas odpowiedź 401 wskazuje, że autoryzacja została odrzucona dla tych poświadczeń.

Źródło: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Co nie działa

postanowiłem wykorzystać niektóre ASP.NET i brudne, aby to naprawić.Poniżej implementuje przepisywanie odpowiedzi za pomocą kilku plików tekstowych na serwerze i dynamicznej kompilacji ASP.NET. (Nigdy wcześniej nie używałam kompilacji dynamicznej, ale kompilacja wydawała się przesadzona w przypadku witryny statycznej.)

Poniższy plik Global.asax przechwytuje zdarzenie EndRequest, przepisując odpowiedź HTTP 401 na HTTP 403, jeśli użytkownik pomyślnie uwierzytelniony jako użytkownik Windows, ale z jakiegoś innego powodu odmawia się żądania (zakładam, że powodem musi być awaria autoryzacji).

Plik web.config zawiera wpisy do trasowania wszystkich żądań za pośrednictwem potoku ASP.NET i odmawia dostępu każdemu uwierzytelnionemu użytkownikowi, który nie jest członkiem grupy "Sprzedaż" systemu Windows.

W tym rozwiązaniu założono, że aplikacja działa w trybie zintegrowanego potoku usług IIS (to znaczy nie w trybie klasycznym), włączono uwierzytelnianie systemu Windows i wyłączono wszystkie inne schematy uwierzytelniania.

/Global.asax:

<Script language="C#" runat="server"> 
    void Application_EndRequest() { 
      // rewrite HTTP 401s to HTTP 403s if the user is authenticated using 
      // integrated Windows auth with impersonation, but, 
      // the user lacks permissions to the requested URL 
      if (Context.User != null && 
        Context.User.Identity != null && 
         Context.User.Identity.IsAuthenticated && 
          Context.User is System.Security.Principal.WindowsPrincipal && 
           Context.Response.StatusCode == 401) 
      { 
       Context.Response.Clear(); 
       Context.Response.StatusCode = 403; 
      } 
     } 
</script> 

/web.config:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
     <security> 
      <authorization> 
       <remove users="*" roles="" verbs="" /> 
       <add accessType="Allow" roles="Sales" /> 
      </authorization> 
     </security> 
     <modules runAllManagedModulesForAllRequests="true" /> 
    </system.webServer> 
</configuration> 

Na przyszłość, stworzyłem GIST @ https://gist.github.com/steve-jansen/6234700

+0

Wygląda to odpowiedź na problem Mam. Czy ktoś może wyjaśnić, gdzie są te pliki i/lub jak sprawdzić tryb potoku. Także jeśli chcę pozwolić na to wszystkim, zamiast tylko Sprzedaż, jak to zrobić, czy mogę po prostu zostawić tę część off ... – Rothrock

+0

@Rothrock Po prostu to z IIS 8.5. Zużyłem 1,5 h, aby dowiedzieć się, dlaczego IIS odrzucił mój crossbranżowy bilet Kerberos z 401 zamiast dać mi 403. To jest błąd, czy istnieje lepszy sposób na rozwiązanie tego problemu? 401 jest oczywiście nieprawidłowym kodem statusu. Wygląda mi na typowy żart z MS. –

Powiązane problemy