Konfiguruj Windows authentication na serwerze raportów

Domyślnie usługa Reporting Services akceptuje żądania określające typ uwierzytelniania jako Negotiate lub NTLM. Jeśli Twoje wdrożenie obejmuje aplikacje klienckie i przeglądarki korzystające z tych dostawców zabezpieczeń, możesz używać wartości domyślnych bez innych konfiguracji. Załóżmy, że chcesz użyć innego dostawcy zabezpieczeń dla zintegrowanego zabezpieczenia Windows albo jeśli zmienisz domyślne wartości i chcesz przywrócić oryginalne ustawienia. Możesz wykorzystać informacje zawarte w tym artykule, aby określić ustawienia uwierzytelniania na serwerze raportów.

Aby korzystać z zintegrowanego zabezpieczenia Windows, każdy użytkownik potrzebujący dostępu do serwera raportów musi mieć ważne lokalne lub domenowe konto użytkownika Windows. Albo muszą być członkiem lokalnego konta lub grupy domenowej Windows. Możesz uwzględnić konta z innych domen, o ile te domeny są zaufane. Konta muszą mieć dostęp do komputera serwera raportów, a następnie muszą być przypisane do ról, aby uzyskać dostęp do konkretnych operacji serwera raportów.

Należy również spełnić następujące wymagania:

  • Pliki RSReportServer.config muszą mieć AuthenticationType ustawione na , RSWindowsNegotiateRSWindowsKerberos, lub RSWindowsNTLM. Domyślnie plik RSReportServer.config zawiera RSWindowsNegotiate ustawienie, jeśli konto usługi Report Server jest NetworkService lub LocalSystem; w przeciwnym razie to RSWindowsNTLM ustawienie jest używane. Możesz dodać RSWindowsKerberos , jeśli masz aplikacje korzystające wyłącznie z uwierzytelniania Kerberos.

    Important

    Gdy używasz RSWindowsNegotiate, pojawia się błąd uwierzytelniania Kerberos, jeśli skonfigurowałeś usługę Report Server tak, aby działała pod kontem użytkownika domeny i nie zarejestrowałeś nazwy Zasady Usługi (SPN) dla tego konta. Więcej informacji można znaleźć w artykule Rozwiązywanie błędów uwierzytelniania Kerberos podczas łączenia z serwerem raportów w tym temacie.

  • ASP.NET musi być skonfigurowany do uwierzytelniania Windows. Domyślnie pliki Web.config usługi sieci Web serwera raportów zawierają ustawienie <authentication mode="Windows">. Jeśli zmienisz to na <authentication mode="Forms">, Windows Authentication for Reporting Services nie działa.

  • Pliki Web.config dla usługi Web Report Server muszą zawierać <identity impersonate= "true" />.

  • Aplikacja kliencka lub przeglądarka musi wspierać zintegrowane zabezpieczenia Windows.

  • Portal internetowy nie wymaga dodatkowej konfiguracji.

Aby zmienić ustawienia uwierzytelniania serwera raportów, edytuj elementy i wartości XML w pliku RSReportServer.config. Możesz kopiować i wklejać przykłady z tego artykułu, aby zaimplementować konkretne kombinacje.

Domyślne ustawienia działają najlepiej, jeśli wszystkie komputery klient i serwer znajdują się w tej samej domenie lub zaufanej domenie. A serwer raportów jest wdrożony na potrzeby dostępu z intranetu za firmową zaporą sieciową. Zaufane i pojedyncze domeny są wymagane do przekazania poświadczeń Windows. Poświadczenia mogą być przekazywane więcej niż raz, jeśli włączysz protokół Kerberos wersji 5 dla swoich serwerów. W przeciwnym razie dane uwierzytelniające mogą zostać przesłane tylko jeden raz, zanim wygasną. Aby uzyskać więcej informacji o konfiguracji poświadczeń dla wielu połączeń komputerowych, zobacz Określ informacje o poświadczeniach i połączeniach dla źródeł danych raportów.

Poniższe instrukcje są przeznaczone dla serwera raportów w trybie natywnym. Jeśli serwer raportów jest wdrożony w trybie zintegrowanym programu SharePoint, należy użyć domyślnych ustawień uwierzytelniania określających zintegrowane zabezpieczenia systemu Windows. Serwer raportów wykorzystuje wewnętrzne funkcje domyślnego rozszerzenia Windows Authentication, aby wspierać serwery raportów w trybie zintegrowanym SharePoint.

Rozszerzona Ochrona dla uwierzytelniania

Począwszy od programu SQL Server 2008 R2 (10.50.x), dostępna jest obsługa rozszerzonej ochrony na potrzeby uwierzytelniania. Funkcja programu SQL Server obsługuje użycie powiązania kanału i powiązania usługi w celu zwiększenia ochrony uwierzytelniania. Funkcje Reporting Services muszą być używane z systemem operacyjnym obsługującym Extended Protection. Możesz określić konfigurację usługi Reporting Services dla rozszerzonej ochrony na podstawie określonych ustawień w pliku RSReportServer.config. Możesz aktualizować plik, edytując go lub korzystając z API WMI. Więcej informacji można znaleźć w artykule Rozszerzona Ochrona uwierzytelniania z Reporting Services.

Konfiguruj serwer raportów tak, aby korzystał z zabezpieczeń zintegrowanych z systemem Windows

  1. Otwórz RSReportServer.config w edytorze tekstu.

  2. Znajdź <Authentication>.

  3. Skopiuj jedną z poniższych struktur XML, która najlepiej odpowiada Twoim potrzebom. Możesz określić RSWindowsNegotiate, RSWindowsNTLM, oraz RSWindowsKerberos w dowolnej kolejności. Powinieneś włączyć utrwalanie uwierzytelniania, jeśli chcesz uwierzytelnić połączenie, a nie każde pojedyncze żądanie. W trybie utrwalania uwierzytelniania wszystkie żądania wymagające uwierzytelnienia są dozwolone podczas połączenia.

    Pierwsza struktura XML to domyślna konfiguracja, gdy konto usługi Report Server jest albo NetworkService, albo LocalSystem:

    <Authentication>
    <AuthenticationTypes>
        <RSWindowsNegotiate />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    Druga struktura XML jest domyślną konfiguracją, gdy konto usługi Report Server nie jest NetworkService ani LocalSystem:

    <Authentication>
    <AuthenticationTypes>
            <RSWindowsNTLM />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    Trzecia struktura XML określa wszystkie pakiety bezpieczeństwa używane w zintegrowanym systemie bezpieczeństwa Windows:

    <AuthenticationTypes>
    <RSWindowsNegotiate />
    <RSWindowsKerberos />
    <RSWindowsNTLM />
</AuthenticationTypes>

    Czwarta struktura XML określa NTLM tylko dla wdrożeń, które nie obsługują Kerberos lub do obejścia błędów uwierzytelniania Kerberos:

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Wklej to zamiast istniejących wpisów dla <Authentication>.

    Nie możesz używać Custom z typami RSWindows .

  5. Dostosowuj ustawienia do wydłużonej ochrony. Rozszerzona ochrona jest domyślnie wyłączona. Jeśli te wpisy nie występują, obecny komputer może nie uruchamiać wersji Reporting Services, która obsługuje rozszerzoną ochronę. Więcej informacji można znaleźć w artykule Rozszerzona ochrona uwierzytelniania z Reporting Services

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

  6. Zapisz plik.

  7. Jeśli skonfigurowałeś wdrożenie skalowalne, powtórz te kroki dla innych serwerów raportów w tym wdrożeniu.

  8. Zrestartuj serwer raportów, aby wyczyścić sesje, które są obecnie otwarte.

Napraw błędy uwierzytelniania Kerberos podczas łączenia z serwerem raportów

Na serwerze raportów skonfigurowanym do uwierzytelniania Negotiate lub Kerberos połączenie klienta z serwerem raportów kończy się niepowodzeniem, jeśli wystąpi błąd uwierzytelniania Kerberos. Błędy uwierzytelniania Kerberos są znane z występowania, gdy:

  • Usługa Report Server jest uruchamiana przy użyciu konta użytkownika domeny systemu Windows i nie zarejestrowano dla tego konta nazwy głównej usługi (SPN).

  • Serwer raportów jest skonfigurowany z ustawieniem RSWindowsNegotiate.

  • Przeglądarka wybiera Kerberos zamiast NTLM w nagłówku uwierzytelniania w żądaniu wysyłanym do serwera raportów.

Możesz wykryć błąd, jeśli włączyłeś logowanie Kerberos. Innym objawem błędu jest wielokrotne żądanie danych uwierzytelniających, a potem widzisz puste okno przeglądarki.

Możesz potwierdzić, że napotykasz błąd uwierzytelniania Kerberos, usuwając <RSWindowsNegotiate> z pliku konfiguracyjnego i próbując ponownie nawiązać połączenie.

Po potwierdzeniu problemu możesz rozwiązać go w następujący sposób:

  • Zarejestruj SPN dla usługi Report Server na konto użytkownika domeny. Aby uzyskać więcej informacji, zobacz Rejestrowanie głównej nazwy usługi (SPN) dla serwera raportów.

  • Zmień konto usługi, aby działało pod wbudowanym kontem, takim jak Network Service. Konta wbudowane mapują HTTP SPN na SPN hosta, który jest definiowany po podłączeniu komputera do sieci. Aby uzyskać więcej informacji, zobacz Konfigurowanie konta usługi (Menedżer konfiguracji serwera raportów).

  • Użyj NTLM. NTLM zazwyczaj działa w przypadkach, gdy uwierzytelnianie Kerberos zawodzi. Aby użyć NTLM, usuń RSWindowsNegotiate z pliku RSReportServer.config i sprawdź, czy tylko RSWindowsNTLM jest określona. Jeśli wybierzesz takie podejście, możesz nadal korzystać z domenowego konta użytkownika dla usługi Report Server, nawet jeśli nie zdefiniujesz dla niego SPN.

Podsumowując, powinieneś uruchamiać polecenia podobne do poniższego przykładu. Zamień wartości w odpowiednim miejscu.

setspn -S HTTP/<SSRS Server FDQN> <SSRS Service Account>
setspn -S HTTP/<host header for Report server web site> <SSRS Service Account>
setspn -S HTTP/<SharePoint Server FDQN> <SharePoint Application Pool Account>
setspn -S HTTP/<host header for SharePoint site>  <SharePoint Application Pool Account>
setspn -S HTTP/Dummy <Claims to Windows Taken Service Account>

Informacje o logach

Istnieje kilka źródeł informacji o logowaniu, które mogą pomóc rozwiązać problemy związane z Kerberosem.

Atrybut User-Account-Control użytkownika

Sprawdź, czy konto usługi Reporting Services ma odpowiedni zestaw atrybutów w Active Directory. Przejrzyj plik logu śledzenia usług Reporting Services, aby znaleźć wartość rejestrowaną dla atrybutu UserAccountControl. Wartość rejestrowana jest w formie dziesiętnej. Musisz przekonwertować wartość dziesiętną na postać szesnastkową, a następnie odszukać tę wartość w artykule MSDN opisującym atrybut User-Account-Control.

  • Wpis dziennika śledzenia usługi Reporting Services wygląda podobnie jak w poniższym przykładzie:

    appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336

  • Jedną z opcji konwersji wartości dziesiętnej na postać szesnastkową jest użycie Kalkulatora systemu Microsoft Windows. Windows Calculator obsługuje kilka trybów, które wyświetlają opcję Dec i opcje Hex. Wybierz opcję Dec, wklej lub wpisz wartość dziesiętną, którą znalazłeś w pliku dziennika, a następnie wybierz opcję „Hex”.

  • Następnie odwołaj się do artykułu User-Account-Control Atribut , aby wyprowadzić atrybut dla konta usługi.

SPN skonfigurowane w Active Directory dla konta usługi Reporting Services

Aby rejestrować identyfikatory SPN w pliku dziennika śledzenia usługi Reporting Services, można tymczasowo włączyć funkcję Reporting Services Extended Protection.

  • Zmodyfikuj rsreportserver.config pliku konfiguracyjnego, ustawiając następujące:

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>

  • Uruchom ponownie usługę Reporting Services.

Jeśli nie chcesz dalej korzystać z Extended Protection, ustaw wartości konfiguracyjne z powrotem na domyślne i zrestartuj konto Reporting Services Service.

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

Więcej informacji można znaleźć w artykule Rozszerzona Ochrona uwierzytelniania z Reporting Services.

Jak przeglądarka wybiera Negocjowanego Kerberosa lub Negocjowanego NTLM

Gdy używasz Internet Explorer do połączenia z serwerem raportu, w nagłówku uwierzytelniania podaje się albo Negotiated Kerberos, albo NTLM. NTLM jest używany zamiast Kerberos, gdy:

  • Żądanie jest wysyłane do lokalnego serwera raportów.

  • Żądanie jest wysyłane na adres IP komputera serwera raportu, a nie na nagłówek hosta czy nazwę serwera.

  • Oprogramowanie zapory blokuje porty używane do uwierzytelniania Kerberos.

  • System operacyjny danego serwera nie ma włączonego Kerberosa.

  • Domena obejmuje starsze wersje systemów Windows typu klient i serwer, które nie obsługują funkcji uwierzytelniania Kerberos wbudowanej w nowsze wersje systemu operacyjnego.

Dodatkowo Internet Explorer może wybrać Negotiated Kerberos lub NTLM, w zależności od konfiguracji URL, LAN i ustawień proxy.

Adres URL serwera raportów

Jeśli adres URL zawiera w pełni kwalifikowaną nazwę domeny, Internet Explorer wybiera NTLM. Jeśli adres URL wskazuje localhost, program Internet Explorer wybiera protokół NTLM. Jeśli adres URL podaje nazwę sieci komputera, Internet Explorer wybiera Negocjuj, co się powiodło lub nie powiodło, w zależności od tego, czy dla konta Report Server istnieje SPN.

Ustawienia LAN i proxy na kliencie

Ustawienia LAN i proxy, które ustawisz w Internet Explorer, mogą zdecydować, czy NTLM zostanie wybrany zamiast Kerberosa. Jednak ponieważ ustawienia LAN i proxy różnią się w zależności od organizacji, nie jest możliwe dokładne określenie dokładnych ustawień przyczyniających się do błędów uwierzytelniania Kerberos. Na przykład organizacja może wymuszać ustawienia serwera proxy, które przekształcają adresy URL intranetu w adresy URL z w pełni kwalifikowaną nazwą domenową, które są rozpoznawane za pośrednictwem połączeń internetowych. Jeśli dla różnych typów adresów URL używa się różnych dostawców uwierzytelniania, możesz zauważyć, że niektóre połączenia odnoszą sukces, gdy spodziewasz się ich niepowodzenia.

Możesz napotkać błędy połączenia, które uważasz za spowodowane błędami uwierzytelniania. Jeśli tak, możesz spróbować różnych kombinacji ustawień LAN i proxy, aby odizolować problem. W Internet Explorer ustawienia LAN i proxy znajdują się w oknie dialogowym Ustawienia sieci lokalnej (LAN), które otwierasz, wybierając ustawienia LAN na zakładce Połączenie w opcjach Internetu.

Dodatkowe informacje dotyczące technologii Kerberos i serwerów raportów

Treści powiązane

  • Last updated on