Como configurar a autenticação do Windows no Reporting Services

Por padrão, o Reporting Services aceita solicitações que especificam a autenticação Negotiate ou NTLM. Se sua implantação incluir aplicativos cliente e navegadores que usam esses provedores de segurança, use os valores padrão sem nenhuma configuração adicional. Se desejar usar um provedor de segurança diferente para a segurança integrada do Windows (por exemplo, se desejar usar Kerberos diretamente) ou se tiver modificado os valores padrão e desejar restaurar as configurações originais, use as informações deste tópico para especificar configurações de autenticação no servidor de relatório.

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

Os requisitos adicionais a seguir também devem ser satisfeitos:

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

    Observação importanteImportante

    O uso de RSWindowsNegotiate resultará em um erro de autenticação se o serviço Servidor de Relatório for configurado para ser executado em uma conta de usuário de domínio e um nome da entidade de serviço (SPN) não tiver sido registrado para a conta. Para obter mais informações, consulte Resolvendo erros da autenticação Kerberos ao se conectar a um servidor de relatório neste tópico.

  • O ASP.NET deve ser configurado para a Autenticação do Windows. Por padrão, os arquivos Web.config do serviço Web Servidor de Relatórios e do Gerenciador de Relatórios incluem a configuração <modo de autenticação="Windows">. Se você alterar essa configuração para <modo de autenticação="Formulários">, a Autenticação do Windows para o Reporting Services falhará. 

  • Os arquivos Web.config do serviço Web Servidor de Relatórios e do Gerenciador de Relatórios devem ter <representação da identidade="verdadeiro" />.

  • O aplicativo cliente ou navegador deve dar suporte à segurança integrada do Windows.

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

As configurações padrão funcionam melhor se todos os computadores cliente e de servidor estiverem no mesmo domínio ou em um domínio confiável e se o servidor de relatório for implantado para acessar a intranet por trás de um firewall corporativo. Os domínios únicos e confiáveis são um requisito para passar as 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, elas podem ser passadas apenas uma vez antes de expirarem. Para obter mais informações sobre como configurar credenciais para várias conexões de computador, consulte Especificando informações de credencial e conexão para fontes de dados do 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ório usa recursos internos na extensão padrão da Autenticação do Windows para dar suporte a servidores de relatório no modo integrado do SharePoint.

Proteção estendida para autenticação

A partir do SQL Server 2008 R2, 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 oferece suporte à Proteção Estendida. A configuração do Reporting Services para proteção estendida é determinada pelas configurações no arquivo RSReportServer.config. O arquivo pode ser atualizado editando o arquivo ou usando APIs do WMI. Para obter mais informações, consulte Proteção Estendida para Autenticação com Reporting Services e Solução de problemas de proteção estendida (Reporting Services).

Para configurar um servidor de relatório para usar a segurança integrada do Windows

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

  2. Localize <Authentication>.

  3. Copie uma das estruturas XML a seguir que seja mais adequada para as suas necessidades. Você pode especificar RSWindowsNegotiate, RSWindowsNTLM e RSWindowsKerberos em qualquer ordem. Você deve habilitar a persistência de autenticação se desejar autenticar a conexão em vez de cada solicitação individual. Com a persistência de autenticação, todas as solicitações que precisam de autenticação serão permitidas durante a conexão.

    A primeira estrutura XML será a configuração padrão quando a conta de serviço do Servidor de Relatório for NetworkService ou LocalSystem:

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

    A segunda estrutura XML será a configuração padrão quando a conta de serviço do Servidor de Relatório não for nem NetworkService nem LocalSystem:

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

    <Autenticação>

    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 somente para implantações que não dão suporte a Kerberos ou como solução alternativa para erros de autenticação do Kerberos:

          <AuthenticationTypes>
                 <RSWindowsNTLM />
          </AuthenticationTypes>
    
  4. Cole-a nas entradas existentes para <Authentication>.

    Observe que você não pode usar Custom com os tipos RSWindows.

  5. Modifique as configurações para proteção estendida conforme o necessário. A proteção estendida é desabilitada por padrão. Se estas entradas não estiverem presentes, o computador atual poderá não estar executando uma versão do Reporting Services que oferece suporte à proteção estendida. Para obter mais informações, consulte 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 em expansão, repita essas etapas para outros servidores de relatório na implantação.

  8. Reinicie o servidor de relatório para terminar as sessões que estão atualmente abertas.

Resolvendo erros da autenticação Kerberos ao se conectar a um servidor de relatório

Em um servidor de relatório configurado para a autenticação Negotiate ou Kerberos, uma conexão cliente com o servidor de relatório falhará se houver um erro da autenticação Kerberos. Os erros da autenticação Kerberos normalmente ocorrem quando:

  • O serviço Servidor de Relatório é executado como uma conta de usuário de domínio do Windows e um nome da entidade de serviço (SPN) não tiver sido registrado para a conta.

  • O servidor de relatório está configurado com a definição RSWindowsNegotiate.

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

Você pode detectar o erro se tiver habilitado o log de Kerberos. Outro sintoma do erro é a solicitação das credenciais várias vezes e a exibição de uma janela vazia do navegador.

Para confirmar se um erro da autenticação Kerberos está sendo exibido, remova < RSWindowsNegotiate /> do arquivo de configuração e tente estabelecer a conexão novamente.

Depois que você confirmar o problema, poderá solucioná-lo dos seguintes modos:

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

  • Altere a conta de serviço para ser executada em uma conta interna, como Serviço de Rede. As contas internas mapeiam o SPN HTTP ao SPN do host, o qual é definido quando um computador se une à sua rede. Para obter mais informações, consulte Como configurar uma conta de serviço para o Reporting Services.

  • Use NTLM. O NTLM geralmente funciona quando a autenticação Kerberos falha. Para usar NTLM, remova RSWindowsNegotiate do arquivo RSReportServer.config e verifique se somente RSWindowsNTLM está especificado. Se você optar por essa abordagem, poderá continuar usando uma conta de usuário de domínio para o serviço Servidor de Relatório, mesmo que não haja um SPN definido.

Registrando informações

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

Atributo de controle da conta de usuário

Determine se a conta de serviço do Reporting Services tem o atributo suficiente definido no Active Directory. Revise o arquivo de log de rastreamento do serviço de relatório para localizar o valor registrado em log para o atributo UserAccountControl. O valor registrado em log está em decimais. Você precisa converter o valor decimal para a forma hexadecimal e, em seguida, localizar o valor no tópico do MSDN que descreve o atributo de controle da conta de usuário.

  • A entrada do log de rastreamento do serviço de relatório será semelhante ao seguinte:

    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 decimal para a forma hexadecimal é, para nós, a Calculadora do Microsoft Windows. A Calculadora do Windows oferece suporte a vários modos que mostram as opções 'Dec' e 'Hex'. Selecione a opção 'Dec', cole ou digite no valor decimal encontrado no arquivo de log e, em seguida, selecione a opção 'Hex'.

  • Em seguida, consulte o tópico Atributo de controle da conta de usuário para derivar o atributo para a conta do serviço.

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

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

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

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel> 
    <RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>
    
  • Reinicie o serviço do Reporting Services e procure entradas semelhantes às seguintes no arquivo de log de rastreamento:

    rshost!rshost!e44!01/14/2010-14:43:51:: i INFO: Registered valid SPNs list for endpoint 2: rshost!rshost!e44!01/14/2010-14:43:52:: i INFO: SPN Whitelist Added <Explicit> - <HTTP/sqlpod064-13.w2k3.net>.
    
  • Os valores no item <Explicit> conterão os SPNs configurados no Active Directory para a conta de serviço do Reporting Services.

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

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

Para obter mais informações, consulte 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ório, Kerberos negociado ou NTLM negociado é especificado no cabeçalho de autenticação. NTLM é usado em vez de Kerberos quando:

  • A solicitação é enviada a um servidor de relatório local.

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

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

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

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

Além disso, o Internet Explorer pode optar entre Kerberos ou NTLM negociado dependendo da configuração de URL, LAN e proxy.

URL do servidor de relatório

Se o URL incluir um nome de domínio completamente qualificado, o Internet Explorer selecionará NTLM. Se o URL especificar localhost, o Internet Explorer selecionará NTLM. Se o URL especificar o nome de rede do computador, o Internet Explorer selecionará Negotiate, que será bem-sucedido ou falhará dependendo da existência de um SPN para a conta de serviço do Servidor de Relatório.

Configurações de LAN e proxy no cliente

As configurações de LAN e proxy que você definiu no Internet Explorer podem determinar a escolha de NTLM em vez de Kerberos. No entanto, como as configurações de LAN e proxy varia entre as organizações, não é possível determinar as configurações exatas que contribuem para os erros da autenticação Kerberos. Por exemplo, sua organização pode impor configurações de proxy que convertem URLs de intranet em URLs de nome completo de domínio resolvidas nas conexões da Internet. Se diferentes provedores de autenticação forem usados para diferentes tipos de URL, algumas conexões podem ser bem-sucedidas e outras podem falhar.

Se houver erros de conexão que, na sua opinião, ocorreram devido a falhas de autenticação, tente usar combinações diferentes de configurações de LAN e proxy para isolar o problema. No Internet Explorer, as configurações de LAN e proxy estão disponíveis na caixa de diálogo Configurações de Rede Local, que é exibida ao clicar em Configurações de LAN na guia Conexão de Opções da Internet.

Recursos externos