IIS devolviendo viejos nombres de usuario a mi aplicación

Question

Aquí está mi escenario. Creé una aplicación que utiliza la autenticación integrada de Windows 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, los cambios de inicio de sesión de NT del usuario de jsmith a jjones ) y cuando mi aplicación los autentica, IIS me pasa su OLD LOGIN. ¡Sigo viendo que se pasa jsmith a mi aplicación hasta que reinicio mi SERVIDOR! Cerrar la sesión del cliente no funciona. Reiniciar el grupo de aplicaciones no funciona. Sólo un reinicio completo.

¿Alguien sabe lo que está pasando aquí? ¿Hay algún tipo de comando que pueda usar para vaciar 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 esta es una caja de producción, estas no son realmente opciones viables.

---

AviD -

Sí, su UPN se cambió junto con su nombre de inicio de sesión. Y Mark / Nick ... Este es un servidor empresarial de producción ... No se puede simplemente reiniciar o reiniciar IIS.

---

Seguimiento (para posteridad):

La respuesta de Grhm fue acertada. 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 describe por qué el elemento de caché no se actualiza después del valor predeterminado de 10 minutos es:

  

Las entradas de caché se agotan, sin embargo, es probable que sean recurrentes   Las consultas por aplicaciones mantienen viva la entrada de caché existente para el   duración máxima de la entrada de caché.

No estoy exactamente seguro de qué causaba esto en nuestro código (las consultas recurrentes), pero la resolución que funcionó para nosotros fue reducir el valor LsaLookupCacheExpireTime del valor aparentemente obsceno de 1 semana A tan solo unas horas. Esto, para nosotros, reduce la probabilidad de que un usuario se vea afectado en el mundo real prácticamente a cero, y al mismo tiempo no cause un número extremo de búsquedas de nombres de SID en nuestros servidores de directorio. Una solución aún mejor que IMO sería si las aplicaciones buscaran la información del usuario por SID en lugar de asignar los datos del usuario al nombre de inicio de sesión textual. (¡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!)

Answer 1

Últimamente he tenido problemas similares y como se indica en respuesta , los cambios en la política de grupo de AviD no funcionan si no se está registrando como usuarios.

Encontré que cambiar el tamaño de LSA Lookup Cache como se describe es MS KB946358 funcionó sin reiniciar ni reciclar ningún conjunto de aplicaciones o servicios.

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

Es posible que desee ver las siguientes llamadas al sistema, como las siguientes:

LookupAccountName()

LookupAccountSid()

LsaOpenPolicy()

Puede usarlos para escribir una aplicación C ++ / CLI (/ Managed-C ++) para interrogar el caché LSA.

Answer 2

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

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

También sugeriría ver la implementación de este que es ligeramente más complejo pero mucho menos propenso a errores.

Answer 3

Sé que también hemos tenido problemas de credenciales en caché en IIS en el pasado aquí, y después de buscar en Google durante días encontramos un comando oscuro (para nosotros, al menos) que puedes usar para ver y borrar las credenciales en caché.

Iniciar - > Ejecute (o WinKey + R) y escriba control keymgr.dll

Esto solucionó nuestros problemas para las máquinas cliente. No lo he intentado en los servidores, pero podría valer la pena si se trata de las credenciales de almacenamiento en caché del servidor. Nuestro problema era que obteníamos credenciales antiguas pero solo en una máquina cliente. Si el usuario inició sesión en una máquina cliente separada, todo estaba bien, pero si usaban su propia máquina en su escritorio, normalmente trabajaban en ella y tenían las credenciales antiguas almacenadas en caché.

Answer 4

Si no se trata de cambiar solo el nombre de usuario de NT, entonces parece que el servicio de autenticación está almacenando en caché el nombre de usuario antiguo.
Puede definir que esto esté deshabilitado, ir a la Configuración de seguridad local (en Herramientas administrativas) y, dependiendo de la versión / edición / configuración, la configuración que sea posible (desde la memoria) es " Número de inicios de sesión anteriores en caché " y " No permitir el almacenamiento de credenciales ... " ;.

Factores adicionales a tener en cuenta:

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

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

Answer 5

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

Answer 6

Cuando se cambiaron los nombres de estos usuarios, ¿cambió solo sus nombres de inicio de sesión de NT o sus nombres de UPN también? los nombres UPN son los nombres propios y son utilizados por Kerberos, que es el protocolo predeterminado para IWA; sin embargo, si simplemente 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 la ventana predeterminada de GINA). Debajo de las cubiertas, Windows traduciría el nombre de inicio de sesión de NT (nuevo) al nombre de Kerberos (antiguo). Esto persiste hasta que AD se vea obligado a actualizar el nombre de Kerberos de acuerdo con el nombre de inicio de sesión de NT ...

Answer 7

Este enlace "Cambiar el intervalo predeterminado para los tokens de usuario en IIS " desde el soporte de MicroSoft  debería ayudar.

Answer 8

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

Answer 9

Igual que para tu información, tuvimos exactamente el mismo problema. Lo que parecía funcionar para nosotros es ir a Active Directory y hacer un " Actualizar ''. Inmediatamente después de esto tuvimos que reciclar el grupo de aplicaciones en los sitios de intranet que tenían este problema.