password net lockout custom authorizeattribute asp adddefaultidentity asp.net security iis authentication kerberos

asp.net - lockout - authorizeattribute asp net core



IIS devuelve nombres de usuarios antiguos a mi aplicación (9)

Cuando se cambiaron los nombres de estos usuarios, ¿solo cambió sus nombres de inicio de sesión de NT o sus nombres de UPN? los nombres UPN son los nombres propios y utilizados por Kerberos, que es el protocolo predeterminado para IWA; sin embargo, si solo hace clic para cambiar su nombre en ActiveDirectory, solo cambia el nombre de inicio de sesión de NT, aunque eso es lo que usarían para iniciar sesión (usando el GINA predeterminado de Windows). Debajo de las carátulas, Windows traduciría el (nuevo) nombre de inicio de sesión de NT al nombre de Kerberos (antiguo). Esto persiste hasta que AD se ve obligado a actualizar el nombre de Kerberos de acuerdo con el nombre de inicio de sesión de NT ...

Aquí está mi escenario. Creé una aplicación que usa Autenticación de Windows integrada para funcionar. En Application_AuthenticateRequest() , uso HttpContext.Current.User.Identity para obtener el WindowsPrincipal actual del usuario de mi sitio web.

Ahora aquí está la parte divertida. Algunos de nuestros usuarios se han casado recientemente, y sus nombres cambian. (es decir, el inicio de sesión NT del usuario cambia de jsmith a jjones ) y cuando mi aplicación los autentica, IIS me pasa su OLD LOGIN. ¡Sigo viendo que jsmith pasó a mi aplicación hasta que reinicie mi SERVIDOR! Cerrar la sesión del cliente no funciona. Reiniciar el grupo de aplicaciones no funciona. Solo un reinicio completo.

¿Alguien sabe lo que está pasando aquí? ¿Hay algún tipo de comando que pueda usar para eliminar cualquier caché que me esté dando este problema? ¿Mi servidor está mal configurado?

Nota: definitivamente NO quiero reiniciar IIS, mis grupos de aplicaciones o la máquina. Como se trata de una caja de producción, estas no son opciones realmente viables.

AviD -

Sí, su UPN se modificó junto con su nombre de usuario. Y Mark / Nick ... Este es un servidor de producción empresarial ... No puede ser reiniciado o reiniciado IIS.

Seguimiento (para la posteridad):

La respuesta de Grhm fue puntual. Este problema aparece en servidores de bajo volumen donde no hay mucha gente que use sus aplicaciones, pero se realizan suficientes solicitudes para mantener la identidad de los usuarios en el caché. La parte clave de la KB que parece describir por qué el elemento de la memoria caché no se actualiza después del valor predeterminado de 10 minutos es:

Las entradas de caché agotarán el tiempo de espera, sin embargo, es probable que las consultas recurrentes de las aplicaciones mantengan activa la entrada de caché existente durante el tiempo de vida máximo de la entrada de caché.

No estoy exactamente seguro de qué en nuestro código estaba causando esto (las consultas recurrentes), pero la resolución que funcionó para nosotros fue reducir el valor de LsaLookupCacheExpireTime del predeterminado aparentemente obsceno de 1 semana a solo unas pocas horas. Esto, para nosotros, reduce la probabilidad de que un usuario se vea afectado en el mundo real a esencialmente cero, y al mismo tiempo no causa un número extremo de búsquedas de nombre de SID contra nuestros servidores de directorio. Una solución aún mejor sería IMO si las aplicaciones buscaran información de usuario por SID en lugar de asignar datos de usuario al nombre de inicio de sesión de texto. (¡Tome nota, proveedores! Si confía en la autenticación AD en su aplicación, ¡querrá poner el SID en su base de datos de autenticación!)

El problema que identifica AviD es el caché de Active Directory que puede controlar a través del registry . Dependiendo de su solución, las opciones de política de grupo de Avid fallarán o funcionarán dependiendo de si realmente está iniciando sesión en los usuarios o no.

La forma en que se almacena en caché depende de cómo se está autenticando en IIS. Sospecho que podría tratarse de Kerberos, por lo que para borrarlo si Kerberos lo está causando es posible que desee probar klist con la opción de purga que purgará los tickets kerberos, lo que forzará una reautorización a AD en el próximo intento y actualizará los detalles.

También sugiero que se busque implementar this que es un poco más complejo pero mucho menos propenso a errores.

He tenido problemas similares últimamente y, como se afirma en la answer Robert MacLean, los cambios de política de grupo de AviD no funcionan si no está iniciando sesión como usuarios.

Encontré cambiar el tamaño de la caché de búsqueda LSA como se describe en MS KB funcionó sin reiniciar ni reciclar ningún grupo de aplicaciones o servicios.

Encontré esto como una respuesta a esta pregunta similar: autenticación incorrecta después de cambiar el nombre de inicio de sesión del usuario .

Inicie sesión en el servidor que ejecuta IIS utilizando el nuevo nombre de inicio de sesión en cuestión. Esto actualizará la credencial sin reiniciar IIS ni reiniciar el servidor.

Reiniciar IIS, no toda la máquina, debería hacer el truco.

Sé que también tuvimos problemas de credenciales en caché en IIS en el pasado, y después de buscar en Google durante días nos encontramos con un comando poco claro (para nosotros, al menos) que puede usar para ver y borrar las credenciales almacenadas en caché.

Inicio -> Ejecutar (o WinKey + R) y escriba control keymgr.dll

Esto solucionó nuestros problemas para las máquinas del cliente. No lo he probado en servidores, pero podría valer la pena intentarlo si se trata de las credenciales del caché del servidor. Nuestro problema era que estábamos obteniendo credenciales antiguas, pero solo en una máquina cliente. Si el usuario inicia sesión en una máquina cliente separada, todo estaba bien, pero si usaban su propia máquina en su escritorio en la que normalmente trabajaban, tenía las credenciales antiguas almacenadas en la memoria caché.

Si no se trata de cambiar solo el nombre de usuario NT, parece que el servicio de autenticación está almacenando en caché el nombre de usuario anterior.
Puede definir esto como deshabilitado, vaya a Configuración de seguridad local (en Herramientas administrativas) y, según la versión / edición / configuración, las configuraciones que sean relevantes (desde la memoria) son "Número de inicios de sesión previos a la memoria caché" y "Hacer no permitir el almacenamiento de credenciales ... ".

Factores adicionales a tener en cuenta:

  • La membresía del dominio puede afectar esto, ya que los servidores miembros pueden heredar la configuración de dominio
  • Es posible que aún deba reiniciar todo el servidor una vez para que esto surta efecto (pero luego no tendrá que preocuparse por las actualizaciones en el futuro).
  • El rendimiento de inicio de sesión puede verse afectado.

Como tal, te recomiendo que pruebes esto primero antes de implementarlo en producción (por supuesto).

Solo como un FYI tuvimos exactamente el mismo problema. Lo que pareció funcionar para nosotros es ir a Active Directory y hacer un "Refresco". Inmediatamente después de esto, tuvimos que reciclar el grupo de aplicaciones en los sitios de la intranet que tenían este problema.