iis-7.5 - para - publicar sitio web en iis
Suplantar usuario de dominio con canalización integrada (2)
Esta es una pregunta que me persigue ...
En un entorno de Intranet local, estamos condenados a usar el modo de canalización "Clásico" en nuestro Grupo de aplicaciones si queremos usar Suplantar a nuestros usuarios de dominio de Windows, o si hay una nueva forma de declararlos como "ejecutarlos" (por así decirlo )?
Mi objetivo es usar la autenticación de Windows para aplicaciones web locales en mi Intranet para que los usuarios puedan autenticar y ejecutar aplicaciones bajo su cuenta de directorio activo (principio). Cada vez que intento esto (usando la identidad de NetworkService, por supuesto), obtengo este error:
¡Gracias! ;)
No, pero la canalización "Integrada" requiere que se haga pasar por el usuario autenticado de Windows. Al menos en IIS8.5, eso es.
¿Por qué? La suplantación clásica rompe las características asincrónicas de .NET . Específicamente, es difícil administrar la identidad de Windows de un subproceso cuando está siendo utilizado por varios usuarios al mismo tiempo.
¿Cómo? Use un WindowsImpersonationContext por ejemplo
// Start with identity assigned by IIS Application Pool
var current = System.Security.Principal.WindowsIdentity.GetCurrent();
// Enable Windows Authentication in ASP.NET *and* IIS, which ensures
// User.Identity is a WindowsIdentity
WindowsIdentity clientId = (WindowsIdentity)User.Identity;
// When ''using'' block ends, the thread reverts back to previous Windows identity,
// because under the hood WindowsImpersonationContext.Undo() is called by Dispose()
using (WindowsImpersonationContext wic = clientId.Impersonate())
{
// WindowsIdentity will have changed to match clientId
current = System.Security.Principal.WindowsIdentity.GetCurrent();
}
// Back to the original identity
current = System.Security.Principal.WindowsIdentity.GetCurrent();
¿Problemas? A veces es necesario utilizar la delegación en lugar de la suplantación.
Escribí una pequeña aplicación para mostrar el nombre de usuario de la red del usuario actual, tomado de varios lugares diferentes, como Page.User.Identity.Name . También obtuve información sobre el usuario del dominio mediante un par de métodos diferentes para consultar ActiveDirectory. Todo esto para validar lo siguiente.
He encontrado dos modos principales para ejecutar su aplicación utilizando la autenticación de Windows, que se utiliza principalmente en un entorno de Intranet según mi investigación. Aquí están los elementos esenciales mínimos de las configuraciones:
Modo clásico
- AppPool - Pipeline administrado configurado en modo clásico.
- AppPool - Identidad configurada para servicio de red.
- Autenticación - Deshabilitado: Autenticación anónima
- Autenticación - Habilitada: Suplantación de ASP.NET
- Autenticación - Habilitada: Autenticación de Windows
- Proveedores - Inhabilitados: Kerberos
- Configuraciones Avanzadas - Modo Kernel: O bien
Modo integrado
- AppPool - Pipeline administrado configurado en modo integrado.
- AppPool - Identidad configurada para servicio de red.
- Autenticación - Deshabilitado: Autenticación anónima
- Autenticación - Deshabilitado: Suplantación de ASP.NET
- Autenticación - Habilitada: Autenticación de Windows
- Proveedores - Habilitados: Kerberos
- Configuraciones Avanzadas - Modo Kernel: Deshabilitado
Ahora aquí está el kicker !!
Si desea usar el modo Integrado (que es ideal, ya que proporciona mucha más funcionalidad y, además, integración), deberá tener habilitada la Delegación. Aquí hay un par de artículos que deben leerse para comprender los conceptos básicos de la Delegation y, por extensión, el registro dinámico de SPN . Ya que esto incluye más Kerberos y las consideraciones de seguridad en las que probablemente te interese profundizar, podría ser más fácil seguir con el modo Clásico, donde todo lo que tienes que hacer es habilitar la personificación y llamar a un día; o bien engañar y deshabilitar validateIntegratedModeConfiguration . :PAG
Espero que esto ayude a alguien por ahí en el interwebz. ¡Aclamaciones! :)