Konfigurera Windows authentication på rapportservern

Som standard accepterar Reporting Services förfrågningar som specificerar Negotiate- eller NTLM-autentisering. Om din distribution inkluderar klientapplikationer och webbläsare som använder dessa säkerhetsleverantörer kan du använda standardvärdena utan annan konfiguration. Låt oss säga att du vill använda en annan säkerhetsleverantör för Windows integrerad säkerhet, eller om du ändrar standardvärdena och vill återställa de ursprungliga inställningarna. Du kan använda informationen i denna artikel för att specificera autentiseringsinställningar på rapportservern.

För att använda Windows integrerad säkerhet måste varje användare som behöver tillgång till en rapportserver ha ett giltigt lokalt eller domänanvändarkonto för Windows. Eller så måste de vara medlemmar i ett lokalt Windows- eller domängruppskonto. Du kan inkludera konton från andra domäner så länge dessa domäner är betrodda. Kontona måste ha tillgång till rapportserverns dator och måste sedan tilldelas roller för att få tillgång till specifika rapportserveroperationer.

Följande krav måste också uppfyllas:

De RSReportServer.config filerna måste ha satt AuthenticationType till RSWindowsNegotiate, RSWindowsKerberos, eller RSWindowsNTLM. Som standard innehåller RSReportServer.config-filen inställningen RSWindowsNegotiate om Report Server-tjänstekontot är antingen NetworkService eller LocalSystem; annars används inställningen RSWindowsNTLM . Du kan lägga till RSWindowsKerberos om du har applikationer som bara använder Kerberos-autentisering.

Important

När du använder RSWindowsNegotiate, uppstår ett Kerberos-autentiseringsfel om du konfigurerade Report Server-tjänsten att köras under ett domänanvändarkonto och du inte registrerade ett Service Principal Name (SPN) för kontot. För mer information, se Lösning av Kerberos-autentiseringsfel vid anslutning till en rapportserver i detta ämne.
ASP.NET måste konfigureras för Windows-autentisering. Som standard innehåller de Web.config filerna för Report Server Web Service inställningen <authentication mode="Windows"> . Om du ändrar det till <authentication mode="Forms">, misslyckas Windows Authentication for Reporting Services.
De Web.config filerna för Report Server Web Service måste ha <identity impersonate= "true" />.
Klientapplikationen eller webbläsaren måste stödja Windows-integrerad säkerhet.
Webbportalen behöver inte mer konfiguration.

För att ändra autentiseringsinställningarna för rapportservern, redigera XML-elementen och värdena i RSReportServer.config-filen. Du kan kopiera och klistra in exemplen i denna artikel för att implementera specifika kombinationer.

Standardinställningarna fungerar bäst om alla klient- och serverdatorer är i samma domän eller i en betrodd domän. Och rapportservern är distribuerad för intranätåtkomst bakom en företagsbrandvägg. Betrodda och enskilda domäner är ett krav för att skicka Windows-inloggningsuppgifter. Inloggningsuppgifter kan skickas mer än en gång om du aktiverar Kerberos version 5-protokollet för dina servrar. Annars kan behörigheter bara skickas ut en gång innan de går ut. För mer information om att konfigurera inloggningsuppgifter för flera datoranslutningar, se Specificera legitimations- och anslutningsinformation för rapportdatakällor.

Följande instruktioner är avsedda för en rapportserver i inbyggt läge. Om rapportservern distribueras i sharepoint-integrerat läge måste du använda standardinställningarna för autentisering som anger integrerad Säkerhet i Windows. Rapportservern använder interna funktioner i standardtillägget Windows Autentisering för att stödja rapportservrar i SharePoint-integrerat läge.

Utökat skydd för autentisering

Från och med SQL Server 2008 R2 (10.50.x) finns stöd för utökat skydd för autentisering tillgängligt. SQL Server-funktionen stöder användning av kanalbindning och tjänstbindning för att förbättra skyddet av autentisering. Reporting Services-funktionerna måste användas med ett operativsystem som stöder Extended Protection. Du kan bestämma Reporting Services konfiguration för utökat skydd genom specifika inställningar i RSReportServer.config-filen. Du kan uppdatera filen antingen genom att redigera den eller använda WMI-API:er. För mer information, se Utökat skydd för autentisering med Reporting Services.

Konfigurera en rapportserver för att använda Windows integrerad säkerhet

Öppna RSReportServer.config i en textredigerare.
Hitta <Authentication>.
Kopiera en av följande XML-strukturer som bäst passar dina behov. Du kan specificera RSWindowsNegotiate, RSWindowsNTLM, och RSWindowsKerberos i valfri ordning. Du bör aktivera autentiseringspersistens om du vill autentisera anslutningen istället för varje enskild förfrågan. Under autentiseringspersistens tillåts alla förfrågningar som kräver autentisering under anslutningen.

Den första XML-strukturen är standardkonfigurationen när Report Server-tjänstekontot är antingen NetworkService eller LocalSystem:
```
<Authentication>
    <AuthenticationTypes>
        <RSWindowsNegotiate />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
```
Den andra XML-strukturen är standardkonfigurationen när Report Server-tjänstekontot inte är NetworkService eller LocalSystem:
```
<Authentication>
    <AuthenticationTypes>
            <RSWindowsNTLM />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
```
Den tredje XML-strukturen specificerar alla säkerhetspaket som används i Windows integrerad säkerhet:
```
<AuthenticationTypes>
    <RSWindowsNegotiate />
    <RSWindowsKerberos />
    <RSWindowsNTLM />
</AuthenticationTypes>
```
Den fjärde XML-strukturen specificerar NTLM endast för distributioner som inte stöder Kerberos eller för att kringgå Kerberos-autentiseringsfel:
```
<AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>
```
Klistra in det över de befintliga posterna för <Authentication>.

Du kan inte använda Custom med typerna RSWindows .
Modifiera inställningarna för utökat skydd efter behov. Utökat skydd är inaktiverat som standard. Om dessa poster inte finns kan den nuvarande datorn inte köra en version av Reporting Services som stödjer utökat skydd. För mer information, se Utökat skydd för autentisering med Reporting Services
```
<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
```
Spara filen.
Om du har konfigurerat en skalningsutbyggnad, upprepa dessa steg för andra rapportservrar i distributionen.
Starta om rapportservern för att rensa eventuella sessioner som för närvarande är öppna.

Lös Kerberos-autentiseringsfel när du ansluter till en rapportserver

På en rapportserver som är konfigurerad för Negotiate- eller Kerberos-autentisering misslyckas en klientanslutning till rapportservern om det uppstår ett Kerberos-autentiseringsfel. Kerberos-autentiseringsfel är kända för att inträffa när:

Report Server-tjänsten körs som ett Windows-domänanvändarkonto och du registrerade inte ett Service Principal Name (SPN) för kontot.
Rapportservern är konfigurerad med inställningen RSWindowsNegotiate .
Webbläsaren väljer Kerberos framför NTLM i autentiseringsheadern i den förfrågan den skickar till rapportservern.

Du kan upptäcka felet om du aktiverade Kerberos-loggning. Ett annat symptom på felet är att du blir ombedd att ange inloggningsuppgifter flera gånger och sedan ser ett tomt webbläsarfönster.

Du kan bekräfta att du stöter på ett Kerberos-autentiseringsfel genom att ta bort <RSWindowsNegotiate> det från din konfigurationsfil och försöka ansluta igen.

Efter att du har bekräftat problemet kan du åtgärda det på följande sätt:

Registrera ett SPN för Report Server-tjänsten under domänanvändarkontot. Mer information finns i Registrera ett tjänsthuvudnamn (SPN) för en rapportserver.
Ändra tjänstekontot så att det körs under ett inbyggt konto som Network Service. Inbyggda konton mappar HTTP SPN till Host SPN, vilket definieras när du ansluter en dator till ditt nätverk. Mer information finns i Konfigurera ett tjänstkonto (Report Server Configuration Manager).
Använd NTLM. NTLM fungerar generellt i fall där Kerberos-autentisering misslyckas. För att använda NTLM, ta bort RSWindowsNegotiate från RSReportServer.config filen och kontrollera att endast RSWindowsNTLM är specificerad. Om du väljer detta tillvägagångssätt kan du fortsätta använda ett domänanvändarkonto för Report Server-tjänsten även om du inte definierar ett SPN för den.

Sammanfattningsvis bör du köra kommandon liknande följande exempel. Byt ut värdena efter behov.

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>

Logginformation

Det finns flera källor till loggningsinformation som kan hjälpa till att lösa Kerberos-relaterade problem.

Attributet för användarkontokontroll

Ta reda på om Reporting Services-tjänstekontot har tillräckligt med attribut i služba Active Directory. Gå igenom loggfilen för Reporting Services-tjänsten för att hitta värdet som är loggat för attributet UserAccountControl. Det loggade värdet är i decimalform. Du behöver konvertera decimalvärdet till hexadecimalt och sedan hitta det värdet i MSDN-artikeln som beskriver User-Account-Control Attribute.

Posten i spårningsloggen för tjänsten Reporting Services ser ungefär ut som i följande exempel:

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

Ett alternativ för att omvandla decimalvärdet till hexadecimal form är för oss Microsoft Windows Kalkylator. Windows Calculator stöder flera lägen som visar Dec alternativet och Hex alternativen. Välj alternativet Dec , klistra in eller skriv in decimalvärdet du hittade i loggfilen och välj sedan alternativet 'Hex'.
Se sedan artikeln User-Account-Control Attribute för att härleda attributet för tjänstekontot.

SPN:er konfigurerade i služba Active Directory för Reporting Services-tjänstekontot

För att logga SPN:erna i Reporting Services service trace-loggfil kan du tillfälligt aktivera funktionen Reporting Services Extended Protection.

Ändra konfigurationsfilen rsreportserver.config genom att ange följande:

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

Starta om Reporting Services-tjänsten.

Om du inte vill fortsätta använda Extended Protection, sätt då tillbaka konfigurationsvärdena till standard och starta om Reporting Services Service-kontot.

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

För mer information, se Utökat skydd för autentisering med Reporting Services.

Hur webbläsaren väljer Kerberos eller NTLM via förhandling

När du använder Internet Explorer för att ansluta till rapportservern anges antingen Negotiate Kerberos eller NTLM i autentiseringshuvudet. NTLM används istället för Kerberos när:

Förfrågan skickas till en lokal rapportserver.
Förfrågan skickas till en IP-adress på rapportdatorn istället för en värdheader eller servernamn.
Brandväggsprogramvara blockerar portar som används för Kerberos-autentisering.
Operativsystemet på en viss server har inte Kerberos aktiverat.
Domänen inkluderar äldre versioner av Windows klient- och serveroperativsystem som inte stöder Kerberos-autentiseringsfunktionen som är inbyggd i nyare versioner av operativsystemet.

Dessutom kan Internet Explorer välja antingen Negotiated Kerberos eller NTLM beroende på hur du konfigurerade URL-, LAN- och proxyinställningar.

Rapportserver-URL

Om URL:en innehåller ett fullt kvalificerat domännamn väljer Internet Explorer NTLM. Om URL:en anger localhost väljer Internet Explorer NTLM. Om URL:en anger datorns nätverksnamn väljer Internet Explorer Negotiate, vilket lyckas eller misslyckas, beroende på om det finns ett SPN för Report Server-tjänstekontot.

LAN- och proxyinställningar på klienten

LAN- och proxyinställningar som du ställer in i Internet Explorer kan avgöra om NTLM väljs framför Kerberos. Eftersom LAN- och proxyinställningar varierar mellan organisationer är det dock inte möjligt att exakt fastställa exakt vilka inställningar som bidrar till Kerberos-autentiseringsfel. Till exempel kan din organisation upprätthålla proxyinställningar som omvandlar URL:er från intranät-URL:er till fullt kvalificerade domännamns-URL:er som löses över internetanslutningar. Om olika autentiseringsleverantörer används för olika typer av URL:er kan du upptäcka att vissa anslutningar lyckas när du förväntar dig att de ska misslyckas.

Du kan stöta på anslutningsfel som du tror beror på autentiseringsfel. Om så är fallet kan du prova olika kombinationer av LAN- och proxyinställningar för att isolera problemet. I Internet Explorer finns LAN- och proxyinställningar i dialogrutan Lokala nätverkets (LAN) inställningar, som du öppnar genom att välja LAN-inställningar under fliken Anslutning i Internetalternativ.

Ytterligare information för Kerberos och rapportservrar

För mer information om Kerberos och rapportservrar, se Deploying a Business Intelligence Solution Using SharePoint, Reporting Services, and PerformancePoint Monitoring Server with Kerberos.

Feedback

Var den här sidan till hjälp?

Uppdaterades senast 2026-08-24