web-services - services - soapheader c#
Usar DefaultCredentials y DefaultNetworkCredentials (3)
¿El problema es que no puede autenticarse en IIS o no puede autenticarse en SSRS? Puede ser necesario otorgar permiso a la cuenta DOMAIN / MachineName $ en SSRS para ejecutar el informe que está intentando automatizar.
SSRS generalmente hace un buen trabajo al configurar IIS correctamente, por lo que no debería tener que meterse con esas configuraciones. Comprobé dos veces mi instalación (que es SSRS 2005, las cosas pueden haber funcionado de manera diferente en SSRS 2000 y no me dijiste qué versión estás ejecutando), y está configurada para usar la autenticación de Windows y se ha habilitado la suplantación. Eso significa que IIS debería básicamente autenticar sus credenciales (validar un nombre de usuario / contraseña correcto), no autorizar (determinar si ese usuario tiene permiso para ejecutar el informe en cuestión). A continuación, IIS pasa las credenciales a SSRS, que tiene su propia configuración para determinar qué cuentas tienen permiso para ver los informes.
Además, puede automatizar el envío de informes de forma programada directamente en SSRS, por lo que es posible que no necesite el servicio de Windows en absoluto si su programación es bastante básica (es decir, diaria, semanal, etc.).
Estamos teniendo dificultades para calcular cómo funcionan estos objetos de credenciales. De hecho, es posible que no funcionen cómo esperábamos que funcionaran. Aquí hay una explicación del problema actual.
Tenemos 2 servidores que necesitan hablar entre ellos a través de los servicios web. El primero (llamémoslo Server01
) tiene un servicio de Windows que se ejecuta como la cuenta NetworkService. El otro Server02
tiene ReportingServices ejecutándose con IIS 6.0. El Servicio de Windows en el Server01
está tratando de usar el Servicio Server02
ReportingServices de Server02
para generar informes y enviarlos por correo electrónico.
Entonces, esto es lo que probamos hasta ahora.
Establecer las credenciales en tiempo de ejecución ( Esto funciona perfectamente bien ):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Ahora, si pudiéramos usar un usuario genérico, todo estaría bien, sin embargo ... no estamos autorizados. Por lo tanto, estamos intentando usar DefaultCredetials o DefaultNetworkCredentials y pasarlo al servicio web RS:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
O:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
De cualquier manera, no funcionará. Siempre obtenemos 401 sin amenazas de IIS. Ahora, lo que sabemos es que si queremos dar acceso a un recurso registrado como NetworkService, debemos otorgarlo a DOMAIN/MachineName$
( http://msdn.microsoft.com/en-us/library/ms998320.aspx )
Concesión de acceso a un servidor SQL remoto
Si está accediendo a una base de datos en otro servidor en el mismo dominio (o en un dominio de confianza), las credenciales de red de la cuenta de servicio de red se utilizan para autenticarse en la base de datos. Las credenciales de la cuenta de servicio de red son de la forma DomainName / AspNetServer $, donde DomainName es el dominio del servidor ASP.NET y AspNetServer es el nombre de su servidor web.
Por ejemplo, si su aplicación ASP.NET se ejecuta en un servidor llamado SVR1 en el dominio CONTOSO, el servidor SQL ve una solicitud de acceso a la base de datos de CONTOSO / SVR1 $.
Suponíamos que otorgar acceso de la misma manera con IIS funcionaría. Sin embargo, no es así. O al menos, algo no está configurado correctamente para que se autentique correctamente.
Entonces, aquí hay algunas preguntas:
Hemos leído sobre "Personificación de usuarios" en alguna parte, ¿tenemos que configurar esto en algún lugar del Servicio de Windows ?
¿Es posible otorgar acceso a la cuenta integrada de NetworkService a un servidor IIS remoto?
¡Gracias por leer!
Aquí hay algunas cosas que puede consultar: - establecer un SPN (Nombre principal del servicio) para el servicio de informes; puedes encontrar buenos ejemplos en google; - Permitir delegación (ClientCredentials.Windows.AllowImpersonationLevel)
Todos los detalles que necesita están incluidos en este artículo muy antiguo,
http://msdn.microsoft.com/en-us/library/ms998351.aspx
En resumen, cuando encuentre que es confuso solucionar problemas como este, primero debe revisar los detalles técnicos detrás de la suplantación ASP.NET cuidadosamente.