Configurar a autenticação do Windows no servidor de relatórios

Por padrão, o Reporting Services aceita solicitações que especificam autenticação Negotiate ou NTLM. Se sua implantação incluir aplicativos clientes e navegadores que utilizam esses provedores de segurança, você pode usar os valores padrão sem outra configuração. Digamos que você queira usar outro provedor de segurança para a segurança integrada do Windows, ou se você modifica os valores padrão e quer restaurar as configurações originais. Você pode usar as informações deste artigo para especificar configurações de autenticação no servidor de relatórios.

Para usar a segurança integrada ao Windows, cada usuário que precisa de acesso a um servidor de relatórios deve ter uma conta local ou de domínio do Windows válida. Ou, eles devem ser membros de uma conta local ou de grupo de domínio do Windows. Você pode incluir contas de outros domínios, desde que esses domínios sejam confiáveis. As contas devem ter acesso ao computador do servidor de relatórios e, em seguida, devem ser atribuídas a funções para obter acesso a operações específicas do servidor de relatórios.

Os seguintes requisitos também devem ser atendidos:

  • Os arquivos RSReportServer.config devem ter AuthenticationType definido como RSWindowsNegotiate, RSWindowsKerberos, ou RSWindowsNTLM. Por padrão, o arquivo RSReportServer.config inclui a configuração RSWindowsNegotiate se a conta de serviço do Servidor de Relatórios for NetworkService ou LocalSystem; caso contrário, a configuração RSWindowsNTLM será usada. Você pode adicionar RSWindowsKerberos se tiver aplicativos que usam apenas autenticação Kerberos.

    Importante

    Quando você usa RSWindowsNegotiate, ocorre um erro de autenticação Kerberos se você configurou o serviço do Servidor de Relatórios para rodar sob uma conta de usuário de domínio e não registrou um Nome Principal de Serviço (SPN) para a conta. Para mais informações, veja Resolver erros de autenticação Kerberos ao se conectar a um servidor de relatórios neste tópico.

  • ASP.NET deve ser configurado para Autenticação Windows. Por padrão, os arquivos Web.config do serviço Web do Servidor de Relatórios incluem a <authentication mode="Windows"> configuração. Se você alterar para <authentication mode="Forms">, a Autenticação do Windows no Reporting Services deixa de funcionar.

  • Os arquivos Web.config do serviço Web do Servidor de Relatórios devem ter <identity impersonate= "true" />.

  • O aplicativo cliente ou navegador deve suportar segurança integrada ao Windows.

  • O portal web não precisa de mais configuração.

Para alterar as configurações de autenticação do servidor de relatório, edite os elementos e valores XML no arquivo RSReportServer.config. Você pode copiar e colar os exemplos deste artigo para implementar combinações específicas.

As configurações padrão funcionam melhor se todos os computadores cliente e servidor estiverem no mesmo domínio ou em um domínio confiável. Além disso, o servidor de relatórios é implantado para acesso à intranet atrás de um firewall corporativo. Domínios confiáveis e únicos são requisitos para passar credenciais do Windows. As credenciais podem ser passadas mais de uma vez se você ativar o protocolo Kerberos versão 5 para seus servidores. Caso contrário, as credenciais podem ser aprovadas apenas uma vez antes de expirarem. Para mais informações sobre como configurar credenciais para múltiplas conexões de computador, veja Especificar informações de credenciais e conexão para fontes de dados de relatório.

As instruções a seguir são válidas para um servidor de relatório no modo nativo. Se o servidor de relatório for implantado no modo integrado do SharePoint, use as configurações de autenticação padrão que especificam a segurança integrada do Windows. O servidor de relatórios utiliza recursos internos na extensão padrão de Autenticação do Windows para suportar servidores de relatórios no modo integrado SharePoint.

Proteção Estendida para autenticação

A partir do SQL Server 2008 R2 (10.50.x), o suporte para Proteção Estendida para Autenticação está disponível. O recurso do SQL Server oferece suporte ao uso de associação de canal e associação de serviço para aprimorar a proteção da autenticação. Os recursos do Reporting Services precisam ser usados com um sistema operacional que suporte a Proteção Estendida. Você pode determinar a configuração do Reporting Services para proteção estendida por meio de configurações específicas no arquivo RSReportServer.config. Você pode atualizar o arquivo editando o arquivo ou usando APIs de WMI. Para mais informações, veja Proteção Estendida para autenticação com Reporting Services.

Configure um servidor de relatórios para usar segurança integrada ao Windows

  1. Abra RSReportServer.config em um editor de texto.

  2. Encontre <Authentication>.

  3. Copie uma das seguintes estruturas XML que melhor se encaixam nas suas necessidades. Você pode especificar RSWindowsNegotiate, RSWindowsNTLM, e RSWindowsKerberos em qualquer ordem. Você deve ativar a persistência de autenticação se quiser autenticar a conexão, em vez de cada requisição individual. Sob persistência de autenticação, todas as solicitações que exigem autenticação são permitidas durante a conexão.

    A primeira estrutura XML é a configuração padrão quando a conta do serviço do Servidor de Relatórios é NetworkService ou LocalSystem:

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

    A segunda estrutura XML é a configuração padrão quando a conta do serviço do Servidor de Relatórios não é NetworkService ou LocalSystem:

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

    A terceira estrutura XML especifica todos os pacotes de segurança usados na segurança integrada do Windows:

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

    A quarta estrutura XML especifica NTLM apenas para implantações que não suportam Kerberos ou para contornar erros de autenticação Kerberos:

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Cole sobre as entradas já existentes para <Authentication>.

    Você não pode usar Custom com os RSWindows tipos.

  5. Altere conforme apropriado as configurações para proteção estendida. A proteção estendida está desativada por padrão. Se essas entradas não estiverem presentes, o computador atual pode não estar rodando uma versão do Reporting Services que suporte proteção estendida. Para mais informações, veja Proteção Estendida para autenticação com Reporting Services

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

  6. Salve o arquivo.

  7. Se você configurou uma implantação escalonável, repita esses passos para outros servidores de relatório na implantação.

  8. Reinicie o servidor de relatórios para limpar quaisquer sessões que estejam abertas no momento.

Resolver erros de autenticação do Kerberos ao conectar a um servidor de relatórios

Em um servidor de relatório configurado para autenticação Negotiate ou Kerberos, a conexão do cliente com o servidor de relatório falha se houver um erro de autenticação Kerberos. Sabe-se que erros de autenticação Kerberos ocorrem quando:

  • O serviço do Servidor de Relatórios roda como uma conta de usuário do domínio Windows e você não registrou um Nome Principal de Serviço (SPN) para a conta.

  • O servidor de relatórios é configurado com essa RSWindowsNegotiate configuração.

  • O navegador escolhe Kerberos em vez de NTLM no cabeçalho de autenticação na requisição que envia ao servidor de relatórios.

Você pode detectar o erro se ativou o registro do Kerberos. Outro sintoma do erro é que você é solicitado várias vezes por credenciais e depois vê uma janela do navegador vazia.

Você pode confirmar que está encontrando um erro de autenticação Kerberos removendo <RSWindowsNegotiate> do seu arquivo de configuração e tentando a conexão novamente.

Depois de confirmar o problema, você pode resolvê-lo das seguintes maneiras:

  • Registre um SPN para o serviço do Servidor de Relatórios sob a conta de usuário do domínio. Para obter mais informações, confira Registrar um SPN (Nome da Entidade de Serviço) para um servidor de relatório.

  • Mude a conta de serviço para rodar sob uma conta embutida, como o Network Service. Contas integradas mapeiam o SPN HTTP para o SPN do Host, que é definido quando você conecta um computador à sua rede. Para obter mais informações, confira Configurar uma conta de serviço (Gerenciador de Configurações do Servidor de Relatório).

  • Use NTLM. O NTLM geralmente funciona em casos em que a autenticação Kerberos falha. Para usar NTLM, remova RSWindowsNegotiate do arquivo RSReportServer.config e verifique se apenas RSWindowsNTLM está especificado. Se você escolher essa abordagem, pode continuar usando uma conta de usuário de domínio para o serviço do Servidor de Relatórios mesmo que não defina um SPN para ele.

Para resumir, você deve executar comandos semelhantes ao exemplo a seguir. Substitua os valores conforme necessário.

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>

Informações do log

Existem várias fontes de informações de registro que podem ajudar a resolver problemas relacionados ao Kerberos.

atributo User-Account-Control

Determine se a conta do serviço Reporting Services possui o atributo suficiente definido no Active Directory. Revise o arquivo de registro de rastreamento do serviço Reporting Services para encontrar o valor registrado para o atributo UserAccountControl. O valor registrado está em forma decimal. Você precisa converter o valor decimal para hexadecimal e depois localizar esse valor no artigo da MSDN que descreve o atributo User-Account-Control.

  • A entrada do registro de rastreamento do serviço Reporting Services se assemelha ao seguinte exemplo:

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

  • Uma opção para converter o valor Valor Decimal para forma hexadecimal é, para nós, a Calculadora Microsoft Windows. A Calculadora do Windows oferece suporte a vários modos que mostram a opção Dec e as opções Hex. Selecione a Dec opção, cole ou digite o valor decimal que encontrou no arquivo de log e então selecione a opção 'Hex'.

  • Depois, consulte o artigo atributo User-Account-Control para determinar o atributo da conta de serviço.

SPNs configurados no Active Directory para a conta de serviço do Reporting Services

Para registrar os SPNs no arquivo de rastreamento do serviço Reporting Services, você pode ativar temporariamente o recurso de Proteção Estendida do Reporting Services.

  • Modifique o arquivo de configuraçãorsreportserver.config definindo o seguinte:

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

  • Reinicie o serviço Reporting Services .

Se você não quiser continuar usando a Proteção Estendida, então defina os valores de configuração de volta para os padrões e reinicie a conta do Reporting Services Service.

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

Para mais informações, veja Proteção Estendida para autenticação com Reporting Services.

Como o navegador escolhe Kerberos Negociado ou NTLM Negociado

Quando você usa o Internet Explorer para se conectar ao servidor de relatórios, ele especifica Kerberos negociado ou NTLM no cabeçalho de autenticação. NTLM é usado em vez de Kerberos quando:

  • A solicitação é enviada para um servidor local de relatórios.

  • A solicitação é enviada para um endereço IP do computador servidor de relatório, em vez de um cabeçalho de host ou nome do servidor.

  • O software do firewall bloqueia portas usadas para autenticação Kerberos.

  • O sistema operacional de um servidor específico não tem o Kerberos ativado.

  • O domínio inclui versões antigas dos sistemas operacionais Windows cliente e servidor que não suportam o recurso de autenticação Kerberos embutido nas versões mais recentes do sistema operacional.

Além disso, o Internet Explorer pode escolher entre Kerberos Negociado ou NTLM, dependendo de como você configurou URL, LAN e configurações de proxy.

URL do servidor de relatório

Se a URL incluir um nome de domínio totalmente qualificado, o Internet Explorer seleciona NTLM. Se a URL especificar localhost, o Internet Explorer seleciona NTLM. Se a URL especificar o nome da rede do computador, o Internet Explorer seleciona Negociar, que tem sucesso ou falha, dependendo se existe um SPN para a conta do serviço do Servidor de Relatórios.

Configurações de LAN e proxy no cliente

As configurações de LAN e proxy que você definir no Internet Explorer podem determinar se o NTLM é escolhido em vez do Kerberos. No entanto, como as configurações de LAN e proxy variam entre organizações, não é possível determinar com precisão quais configurações exatas contribuem para erros de autenticação no Kerberos. Por exemplo, sua organização pode aplicar configurações de proxy que convertem URLs da intranet em URLs de nomes de domínio totalmente qualificados (FQDNs), que são resolvidos por conexões com a Internet. Se diferentes provedores de autenticação forem usados para diferentes tipos de URLs, você pode perceber que algumas conexões têm sucesso quando você espera que falhem.

Você pode encontrar erros de conexão que acha que são causados por falhas de autenticação. Se sim, você pode tentar diferentes combinações de configurações de LAN e proxy para isolar o problema. No Internet Explorer, as configurações de LAN e proxy estão na caixa de diálogo Configurações de Rede Local (LAN), que você abre selecionando configurações de LAN na aba Conexão das Opções de Internet.

Informações adicionais para Kerberos e servidores de relatórios

Conteúdo relacionado

  • Last updated on