La aplicación IIS que usa la identidad del grupo de aplicaciones pierde el token primario?

(Esta es una pregunta sobre un problema vago. Intento presentar todos los datos relevantes, con la esperanza de que alguien tenga información útil; disculpas por la descripción larga).

Nuestra aplicación web

Tenemos una aplicación web .NET 4 ejecutándose en IIS 7.5 accediendo a Active Directory y una base de datos SQL Server.

Esta aplicación web se ejecuta con una ‘identidad de grupo de aplicaciones’ virtual, estableciendo la identidad del grupo de aplicaciones de la aplicación en ApplicationPoolIdentity . Puede encontrar una descripción concisa de identidades virtuales en una respuesta de StackOverflow y la publicación de blog a la que hace referencia: una identidad de grupo de aplicaciones es simplemente un grupo adicional que se agrega a los procesos de trabajo de la aplicación web que se ejecuta como ‘servicio de red’. Sin embargo, una fuente sugiere vagamente que “Network Service y ApplicationPoolIdentity tienen diferencias que los documentos del sitio de IIS.net no publican”. Entonces, una identidad virtual podría ser más que solo un grupo adicional.

Elegimos usar ApplicationPoolIdentity, a diferencia de NetworkService, porque se convirtió en el valor predeterminado en IIS 7.5 (ver, por ejemplo, aquí ), y por recomendación de Microsoft: “Esta identidad permite a los administradores especificar permisos que pertenecen solo a la identidad bajo la cual la aplicación grupo se está ejecutando, lo que aumenta la seguridad del servidor “. (desde processModel Element para agregar para applicationPools [IIS 7 Settings Schema] ) “Application Pool Identities es una poderosa nueva característica de aislamiento” que “hace que ejecutar aplicaciones IIS sea aún más seguro y confiable.” (del artículo de IIS.net “Application Pool Identities” )

La aplicación usa Autenticación integrada de Windows, pero con , de modo que no se usa la identidad del usuario final, sino la identidad del grupo de aplicaciones virtuales para ejecutar nuestro código.

Esta aplicación consulta Active Directory utilizando las clases System.DirectoryServices , es decir, la API ADSI. En la mayoría de los lugares esto se hace sin especificar un nombre de usuario / contraseña adicional u otras credenciales.

Esta aplicación también se conecta a una base de datos de SQL Server usando Integrated Security=true en la cadena de conexión. Si la base de datos es local, entonces vemos que IIS APPPOOL\OurAppPoolName se usa para conectarse a la base de datos; si la base de datos es remota, se OURDOMAIN\ourwebserver$ cuenta de máquina OURDOMAIN\ourwebserver$ .

Nuestros problemas

Con regularidad tenemos problemas donde una instalación en funcionamiento comienza a fallar de una de las siguientes maneras.

  • Cuando la base de datos está en un sistema remoto, la conexión de la base de datos comienza a fallar: “Inicio de sesión fallido para el usuario ‘NT AUTHORITY \ ANONYMOUS LOGON’. Motivo: la validación de acceso al servidor basada en tokens falló con un error de infraestructura. Verifique los errores previos.” El error anterior es “Error: 18456, Gravedad: 14, Estado: 11.” Parece que ahora OURDOMAIN\ourwebserver$ ya no se usa, sino que se intenta el acceso anónimo. (Tenemos evidencia anecdótica de que este problema ocurrió cuando el UAC se apagó, y que desapareció después de encender el UAC. Pero tenga en cuenta que cambiar el UAC requiere un reinicio …) Un problema similar se informa en el hilo de IIS.net “use ApplicationPoolIdentity para conectarse a SQL ” , específicamente en una respuesta .

  • Las operaciones de Active Directory a través de ADSI (System.DirectoryServices) comienzan a fallar con el error 0x8000500C (“Error desconocido”), 0x80072020 (“Ocurrió un error de operaciones”) o 0x200B (“El atributo o valor del servicio de directorio especificado no existe”) .

  • Iniciar sesión en la aplicación desde Internet Explorer comienza a fallar, con errores HTTP 401. Pero si en IIS ponemos NTLM antes de Negociar, entonces funciona de nuevo. (Tenga en cuenta que se necesita acceso a AD para Kerberos, pero no para NTLM). Se informa un problema similar en el hilo de IIS.net “Falló la autenticación de la ventana con la identidad de AppPool” .

Nuestra hipótesis y solución

Al menos, los problemas de AD y de inicio de sesión siempre parecen desaparecer al cambiar el grupo de aplicaciones de ApplicationPoolIdentity a NetworkService. (Encontramos un informe que confirma esto).

La página “Solución de problemas de autenticación en páginas ASP” tiene algunas sugerencias relacionadas con tokens primarios y secundarios, y lo que encuentro alentador es que vincula los primeros dos de nuestros errores: menciona el acceso NT AUTHORITY\ANONYMOUS LOGON , y los errores AD 0x8000500C y “El atributo o valor del servicio de directorio especificado no existe”.

(La misma página también menciona problemas de caché de esquema de ADSI, pero todo lo que podemos encontrar sobre ese tema es antiguo. Por ahora, consideramos que no está relacionado).

En base a lo anterior, nuestra hipótesis de trabajo actual es que, solo cuando se ejecuta bajo una identidad de grupo de aplicaciones virtual, nuestra aplicación web (proceso de trabajo IIS?) Pierde de repente su token primario , de modo que IIS solo tiene un token secundario, de modo que todo el acceso a Active Directory y SQL Server se realiza de forma anónima, dando lugar a todos los errores anteriores.

Por ahora, tenemos la intención de cambiar de ApplicationPoolIdentity a NetworkService. Con suerte, esto hace que todos los problemas anteriores desaparezcan. Pero no estamos seguros; y nos gustaría volver atrás si es posible.

Nuestra pregunta

¿Es correcta la hipótesis anterior y, de ser así, se trata de un error en IIS / Windows / .NET? ¿Bajo qué circunstancias ocurre esta pérdida de token primario?

A través del Soporte de Microsoft descubrí que nos topamos con el problema descrito en el artículo KB2545850 de Microsoft Knowledge Base . Esto solo ocurre cuando se usa ApplicationPoolIdentity. Ocurre muy fácilmente, es decir, después de que se cambia la contraseña de la cuenta del equipo (que de forma predeterminada se produce automáticamente cada 30 días), y luego se reinicia el IIS (por ejemplo, a través de iisreset ). Tenga en cuenta que el problema desaparece después de un reinicio, según Microsoft y nuestras observaciones.

Según Microsoft, no es posible verificar si su Windows / IIS ha llegado a este estado.

Microsoft tiene una revisión adjunta a este artículo de KB. No hay ninguna indicación de cuándo esa revisión se transferirá a una entrega oficial, y la revisión ya tiene 10 meses. En nuestro caso específico, decidimos cambiar a NetworkService en su lugar.

Vea https://serverfault.com/a/403534/126432 para mis comentarios sobre el mismo problema / solución.

El uso de la revisión que enlazó me permitió hacer que ApplicationPoolIdentity funcionara como los médicos dicen que debería. Esta revisión no describe específicamente una solución para acceder a recursos de red como NT AUTHORITY \ ANONYMOUS LOGON, pero está relacionada con el cambio de contraseña de la computadora. La conclusión es que funcionó para mí, al menos hasta ahora.

Esto también es relevante para Umbraco que usa la autenticación de Active Directory. De vez en cuando, puede obtener esta excepción:

Error de configuración

El atributo o valor del servicio de directorio especificado no existe

Esto aparentemente es causado por el problema descrito aquí. Un reinicio lo arregla invariablemente.