Configurar la autenticación de Windows en el servidor de informes

Por defecto, Reporting Services acepta solicitudes que especifican la autenticación Negotiate o NTLM. Si tu despliegue incluye aplicaciones cliente y navegadores que usan estos proveedores de seguridad, puedes usar los valores predeterminados sin otra configuración. Supongamos que quieres usar otro proveedor de seguridad para la seguridad integrada de Windows, o si modificas los valores por defecto y quieres restaurar la configuración original. Puedes usar la información de este artículo para especificar la configuración de autenticación en el servidor de informes.

Para utilizar la seguridad integrada de Windows, cada usuario que requiera acceso a un servidor de informes debe tener una cuenta de usuario local o de dominio de Windows válida. O bien, deben ser miembros de una cuenta local o de grupo de dominio de Windows. Puedes incluir cuentas de otros dominios siempre que esos dominios sean de confianza. Las cuentas deben tener acceso al ordenador del servidor de informes y luego deben ser asignadas a roles para acceder a operaciones específicas del servidor de informes.

También deben cumplirse los siguientes requisitos:

  • Los archivos RSReportServer.config deben haber AuthenticationType establecido como RSWindowsNegotiate, RSWindowsKerberos, o RSWindowsNTLM. Por defecto, el archivo RSReportServer.config incluye la RSWindowsNegotiate configuración si la cuenta del servicio del Servidor de Informes es NetworkService o LocalSystem; en caso contrario, se utiliza la RSWindowsNTLM configuración. Puedes añadir RSWindowsKerberos si tienes aplicaciones que solo usan autenticación Kerberos.

    Important

    Cuando usas RSWindowsNegotiate, se produce un error de autenticación Kerberos si configuraste el servicio del Servidor de Informes para que se ejecutara bajo una cuenta de usuario de dominio y no registraste un Nombre Principal de Servicio (SPN) para la cuenta. Para más información, consulte Resolver errores de autenticación Kerberos al conectarse a un servidor de informes en este tema.

  • ASP.NET debe configurarse para la autenticación de Windows. Por defecto, los archivos Web.config del servicio web del Servidor de Informes incluyen la <authentication mode="Windows"> configuración. Si lo cambias a <authentication mode="Forms">, falla la autenticación de Windows para Reporting Services.

  • Los archivos Web.config del servicio web del Servidor de Informes deben tener <identity impersonate= "true" />.

  • La aplicación cliente o navegador debe soportar seguridad integrada en Windows.

  • El portal web no necesita más configuración.

Para cambiar la configuración de autenticación del servidor de informes, edita los elementos y valores XML en el archivo RSReportServer.config. Puedes copiar y pegar los ejemplos de este artículo para implementar combinaciones específicas.

La configuración predeterminada funciona mejor si todos los ordenadores cliente y servidor están en el mismo dominio o en un dominio confiable. Además, el servidor de informes se implementa para el acceso a la intranet detrás de un firewall corporativo. Los dominios confiables y únicos son un requisito para pasar las credenciales de Windows. Las credenciales pueden pasarse más de una vez si activas el protocolo Kerberos versión 5 para tus servidores. De lo contrario, las credenciales solo pueden aprobarse una vez antes de que expiren. Para más información sobre cómo configurar credenciales para múltiples conexiones de ordenador, consulte Especificar información de credenciales y conexión para fuentes de datos de informes.

Las instrucciones siguientes están pensadas para un servidor de informes en modo nativo. Si el servidor de informes se implementa en modo integrado de SharePoint, debe usar la configuración de autenticación predeterminada que especifique la seguridad integrada de Windows. El servidor de informes utiliza funciones internas en la extensión predeterminada de autenticación de Windows para soportar servidores de informes en modo integrado de SharePoint.

Protección Extendida para la autenticación

A partir de SQL Server 2008 R2 (10.50.x), se admite la protección ampliada para la autenticación. La característica de SQL Server admite el uso del enlace de canal y del enlace de servicio para mejorar la protección de la autenticación. Las funciones de Reporting Services deben usarse con un sistema operativo que soporte Protección Extendida. Puede determinar la configuración de Reporting Services para la protección extendida mediante valores de configuración específicos en el archivo RSReportServer.config. Puedes actualizar el archivo editándolo o usando las APIs de WMI. Para más información, consulte Protección Extendida para la autenticación con Reporting Services.

Configura un servidor de informes para usar la seguridad integrada de Windows

  1. Abre RSReportServer.config en un editor de texto.

  2. Busque <Authentication>.

  3. Copia una de las siguientes estructuras XML que mejor se adapte a tus necesidades. Puedes especificar RSWindowsNegotiate, RSWindowsNTLM, y RSWindowsKerberos en cualquier orden. Deberías activar la persistencia de autenticación si quieres autenticar la conexión en lugar de cada solicitud individual. Bajo persistencia de autenticación, todas las solicitudes que requieren autenticación están permitidas durante la conexión.

    La primera estructura XML es la configuración predeterminada cuando la cuenta del servicio del Servidor de Informes es NetworkService o LocalSystem:

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

    La segunda estructura XML es la configuración predeterminada cuando la cuenta del servicio del Servidor de Informes no es NetworkService ni LocalSystem:

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

    La tercera estructura XML especifica todos los paquetes de seguridad que se utilizan en la seguridad integrada de Windows:

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

    La cuarta estructura XML especifica NTLM solo para despliegues que no soportan Kerberos o para evitar errores de autenticación de Kerberos:

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Pégalo sobre las entradas existentes para <Authentication>.

    No puedes usar Custom con los tipos RSWindows.

  5. Modifica según corresponda la configuración para una protección extendida. La protección extendida está desactivada por defecto. Si estas entradas no están presentes, el ordenador actual puede que no esté ejecutando una versión de Reporting Services que soporte protección extendida. Para más información, consulte Protección extendida para autenticación con Reporting Services

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

  6. Guarde el archivo.

  7. Si configuraste un despliegue escalable, repite estos pasos para otros servidores de informes en el despliegue.

  8. Reinicia el servidor de informes para borrar cualquier sesión que esté abierta en ese momento.

Resolver errores de autenticación de Kerberos al conectarte a un servidor de informes

En un servidor de informes configurado para autenticación Negotiate o Kerberos, la conexión del cliente al servidor de informes falla si hay un error de autenticación Kerberos. Se sabe que ocurren errores de autenticación con kerberos cuando:

  • El servicio del Servidor de Informes funciona como una cuenta de usuario de dominio de Windows y no registraste un Nombre Principal de Servicio (SPN) para la cuenta.

  • El servidor de informes está configurado con esta RSWindowsNegotiate configuración.

  • El navegador elige Kerberos en lugar de NTLM en la cabecera de autenticación de la solicitud que envía al servidor de informes.

Puedes detectar el error si activaste el registro de Kerberos. Otro síntoma del error es que te piden las credenciales varias veces y luego ves una ventana vacía del navegador.

Puedes confirmar que estás experimentando un error de autenticación de Kerberos eliminando <RSWindowsNegotiate> de tu archivo de configuración y intentando de nuevo la conexión.

Después de confirmar el problema, puedes abordarlo de las siguientes maneras:

  • Registra un SPN para el servicio del Servidor de Informes bajo la cuenta de usuario del dominio. Para más información, consulte Registrar un nombre principal de servicio (SPN) para un servidor de informes.

  • Cambia la cuenta de servicio para que funcione bajo una cuenta integrada como Network Service. Las cuentas integradas asignan el SPN HTTP al SPN del anfitrión, que se define cuando conectas un ordenador a tu red. Para más información, consulta Configurar una cuenta de servicio (Administrador de configuración del servidor de informes).

  • Usa NTLM. NTLM generalmente funciona en casos donde falla la autenticación Kerberos. Para usar NTLM, quite RSWindowsNegotiate del archivo RSReportServer.config y compruebe que solo se especifica RSWindowsNTLM. Si eliges este enfoque, puedes seguir usando una cuenta de usuario de dominio para el servicio del Servidor de Informes aunque no definas un SPN para él.

En resumen, deberías ejecutar comandos similares al siguiente ejemplo. Sustituye los valores según corresponda.

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>

Información de registro

Existen varias fuentes de información de registro que pueden ayudar a resolver problemas relacionados con Kerberos.

atributo de Control de cuentas de usuario

Determina si la cuenta de servicio de Reporting Services tiene el atributo suficiente establecido en Active Directory. Revisa el archivo de registro de rastreo del servicio Reporting Services para encontrar el valor registrado para el atributo UserAccountControl. El valor registrado es decimal. Necesitas convertir el valor decimal a forma hexadecimal y luego encontrar ese valor en el artículo de MSDN que describe el atributo Usuario-Account-Control.

  • La entrada del registro de rastreo del servicio Reporting Services se parece al siguiente ejemplo:

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

  • Una opción para convertir el valor Decimal a forma hexadecimal es para nosotros la Calculadora Microsoft Windows. La Calculadora de Windows admite varios modos que muestran la opción Dec y las opciones Hex. Selecciona la Dec opción, pega o escribe el valor decimal que encontraste en el archivo de registro y luego selecciona la opción 'Hex'.

  • Luego, consulta el artículo Atributo User-Account-Control para determinar el atributo de la cuenta de servicio.

SPN configurados en Active Directory para la cuenta de servicio de Reporting Services

Para registrar los SPN en el archivo de registro de rastreo de servicio de Reporting Services, puedes activar temporalmente la función de Protección Extendida de Reporting Services.

  • Modifica el archivo de configuraciónrsreportserver.config configurando lo siguiente:

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

  • Reinicia el servicio de Reporting Services.

Si no quieres seguir usando Protección Extendida, entonces vuelve a poner los valores de configuración en valores predeterminados y reinicia la cuenta de Reporting Services Service.

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

Para más información, consulte Protección Extendida para la autenticación con Reporting Services.

Cómo el navegador elige la autenticación Kerberos negociada o la autenticación NTLM negociada

Cuando se utiliza Internet Explorer para conectarse al servidor de informes, se especifica Kerberos negociado o NTLM negociado en el encabezado de autenticación. NTLM se utiliza en lugar de Kerberos cuando:

  • La solicitud se envía a un servidor de informes local.

  • La solicitud se envía a una dirección IP del ordenador del servidor de informes en lugar de a una cabecera de host o nombre de servidor.

  • El software del cortafuegos bloquea los puertos usados para la autenticación de Kerberos.

  • El sistema operativo de un servidor en particular no tiene Kerberos activado.

  • El dominio incluye versiones antiguas de los sistemas operativos cliente y servidor de Windows que no soportan la función de autenticación Kerberos integrada en las versiones más recientes del sistema operativo.

Además, Internet Explorer puede elegir Kerberos Negociado o NTLM dependiendo de cómo hayas configurado la URL, la LAN y la configuración del proxy.

Dirección URL del servidor de informes

Si la URL incluye un nombre de dominio totalmente cualificado, Internet Explorer selecciona NTLM. Si la URL especifica localhost, Internet Explorer selecciona NTLM. Si la URL especifica el nombre de red del ordenador, Internet Explorer selecciona Negociar, que tiene éxito o falla, dependiendo de si existe un SPN para la cuenta de servicio del Servidor de Informes.

Configuración de LAN y proxy en el cliente

La configuración LAN y proxy que configures en Internet Explorer puede determinar si se elige NTLM en lugar de Kerberos. Sin embargo, dado que las configuraciones de LAN y proxy varían entre organizaciones, no es posible determinar con precisión los ajustes exactos que contribuyen a los errores de autenticación de Kerberos. Por ejemplo, tu organización podría aplicar configuraciones de proxy que transformen las URL de intranet en URL con nombres de dominio completos que se resuelven mediante conexiones a Internet. Si se utilizan diferentes proveedores de autenticación para distintos tipos de URL, puede que observes que algunas conexiones se realicen correctamente cuando se espera que fallen.

Podrías encontrarte con errores de conexión que creas que se deben a fallos de autenticación. Si es así, puedes probar diferentes combinaciones de configuración LAN y proxy para aislar el problema. En Internet Explorer, la configuración de LAN y proxy está en el cuadro de diálogo Configuración de la Red de Área Local (LAN), que se abre seleccionando Configuración LAN en la pestaña de Conexión de Opciones de Internet.

Información adicional para Kerberos y los servidores de informes

Contenido relacionado

  • Last updated on