Compartilhar via

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

  • Artigo

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 outras configurações. Digamos que você quer usar um provedor de segurança diferente para segurança integrada do Windows ou se modificar os valores padrão e queira restaurar as configurações originais. É possível usar as informações neste artigo para especificar as configurações de autenticação no servidor de relatório.

Para usar a segurança integrada do Windows, cada usuário que necessita de acesso ao servidor de relatório deve ter uma conta de usuário de domínio ou local válida do Windows. Ou, eles devem ser membros de uma conta de grupo local ou de domínio 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 então ser atribuídas às funções para obter acesso a operações específicas do servidor de relatório.

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 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.

    Importante

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

  • 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 incluem a configuração <authentication mode="Windows">. Se você alterar essa configuração para <authentication mode="Forms">, a Autenticação do Windows para o Reporting Services falhará.

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

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

  • O portal da Web não precisa de mais configurações.

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 artigo 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. Além disso, o servidor de relatório é implantado para acesso à 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 poderão ser passadas mais de uma vez se você habilitar 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 as credenciais para várias conexões de computador, consulte Especificar informações de credenciais e de 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ó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 (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 ofereça suporte à Proteção Estendida. É possível determinar a configuração do Reporting Services para proteção estendida pelas configurações específicas no arquivo RSReportServer.config. Você pode atualizar o arquivo editando-o ou usando APIs do WMI. Para obter mais informações, consulte Proteção Estendida para autenticação com Reporting Services.

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 exigem autenticação sã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>
</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 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>.

    Não é possível 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 essas entradas não estiverem presentes, o computador atual poderá não estar executando uma versão do Reporting Services que dá 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 escalável, 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.

Resolver 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 do navegador vazia.

Você pode confirmar que está tendo um erro de autenticação Kerberos removendo <RSWindowsNegotiate> do arquivo de configuração e tentando 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, confira Registrar um 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, confira Configurar uma Conta de Serviço (Configuration Manager do Servidor de Relatório).

  • 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.

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

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

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 Reporting Services 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 artigo da MSDN que descreve o atributo de controle da conta de usuário.

  • A entrada do log de rastreamento de serviço do Reporting Services é semelhante ao exemplo a seguir:

    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 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 artigo Atributo de controle da conta de usuário para derivar o atributo para a conta de serviço.

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

Para registrar os SPNs no arquivo de log 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 Reporting Services .

Se você não quiser continuar a usar 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 provedores de autenticação diferentes forem usados para diferentes tipos de URL, algumas conexões podem ser bem-sucedidas mesmo que seja esperado que falhem.

É possível que encontre erros de conexão que você acha que são devidos a falhas de autenticação. Se for o caso, 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 disponíveis na caixa de diálogo Configurações de Rede Local (LAN), que é exibida ao selecionar Configurações de LAN na guia Conexão de Opções da Internet.

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

Conteúdo relacionado