Este es mi escenario. He creado una aplicación que utiliza la Autenticación Integrada de Windows para trabajar. En Application_AuthenticateRequest(), yo uso HttpContext.Current.User.Identity para obtener la corriente WindowsPrincipal de que el usuario de mi sitio web.

Ahora aquí está la parte divertida. Algunos de nuestros usuarios han recientemente casado, y su cambio de nombres. (es decir, el usuario de inicio de Sesión de los cambios de jsmith a jjones) y cuando mi aplicación autentica ellos, IIS me pasa su EDAD de inicio de SESIÓN . Sigo viendo jsmith pasa a mi solicitud hasta reiniciar mi SERVIDOR! Sesión en el cliente no funciona. El reinicio de la aplicación de la piscina no funciona. Sólo un completo reinicio.

¿Alguien sabe qué está pasando aquí? ¿Hay algún tipo de comando puedo utilizar para vaciar lo de la caché me está dando este problema? Es mi servidor mal configurado?

Nota: yo definitivamente NO desea reiniciar IIS, mi aplicación de las piscinas, o de la máquina. Como este es un cuadro de producción, estos en realidad no son opciones viables.


AviD –

Sí, su UPN fue cambiado junto con su nombre de inicio de sesión. Y Marca/Nick… Esta es una empresa de producción de servidor… no puede ser simplemente reinicia o se han reiniciar IIS.


De seguimiento (para la posteridad):

Grhm, fue la respuesta de spot-on. Este problema aparece bajo volumen de servidores, donde usted no tiene un montón de personas que utilizan sus aplicaciones, pero suficientes peticiones están hechas para mantener la identidad de los usuarios en la caché. La parte clave de la KB que parece describir por qué el elemento de caché no se actualiza después de que el valor predeterminado de 10 minutos es:

Las entradas de la caché hacer tiempo, sin embargo las posibilidades son que la recurrente
consultas por aplicaciones de mantener el actual entrada de la caché de vida para la
duración máxima de la entrada de la caché.

No estoy exactamente seguro de lo que en nuestro código fue el causante de que este (el recurrente consultas), pero la resolución que ha trabajado para nosotros fue a cortar el LsaLookupCacheExpireTime valor de la aparentemente obsceno predeterminado de 1 semana a sólo un par de horas. Esto, para nosotros, cortar la probabilidad de que un usuario se verían afectados en el mundo real a la esencia de cero, y sin embargo, al mismo tiempo, no causa un número extremo de SID-Nombre de búsquedas en contra de nuestros servidores de directorio. Una solución aún mejor IMO sería si las aplicaciones miró información del usuario por SID en lugar de la asignación de datos de usuario textuales nombre de inicio de sesión. (Tome nota, vendedores! Si usted confía en los ANUNCIOS de autenticación en la aplicación, usted querrá poner el SID en su base de datos de autenticación!)

InformationsquelleAutor Dave Markle | 2008-10-03

9 Comentarios

  1. 25

    He tenido problemas similares últimamente y como se indica en Robert Maclean’s respuesta, Ávido de cambios de directiva de grupo no funcionan si no estás registrarse como usuarios.

    He encontrado cambiando el LSA de Caché de Búsqueda tamaño como se describe, es MS KB946358 trabajado sin necesidad de reiniciar o de reciclaje de cualquier grupo de aplicaciones o servicios.

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

    Es posible que desee buscar en el siguiente sistema de llamadas tales como los siguientes:

    LookupAccountName()
    
    LookupAccountSid()
    
    LsaOpenPolicy()

    Usted podría utilizar para escribir una C++/CLI (/Managed-C++) aplicación de interrogar a la LSA caché.

    • Eso es impresionante. Que tiene que ser. Yo había estado buscando este artículo de KB para siempre, y sólo podría nunca encontrar.
  2. 4

    El problema como AviD identificado es el Active Directory de la caché que se puede controlar a través de la registro. Dependiendo de la solución de Avid opciones de directiva de grupo se producirá un error o de trabajo en función de si en realidad el registro de los usuarios o no.

    Cómo es que se almacenan en caché depende de cómo se la autenticación en IIS. Sospecho que podría ser Kerberos para hacer la limpieza si es causada por Kerberos puede que desee probar klist con la purga de la opción, la cual debe purgar tickets de kerberos, que obligará a un reauth a AD en el siguiente intento y actualización de los detalles.

    También sugiero buscar en la implementación de este que es un poco más complejo, pero mucho menos propenso a errores.

  3. 4

    Sé que hemos tenido en caché las credenciales de los problemas en IIS en el pasado aquí, también, y después de Googlear para los días nos llegó a través de un desconocido (para nosotros, al menos) de comandos que puede utilizar para ver y borrar las credenciales almacenadas en caché.

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

    Esta solucionado nuestros problemas para los equipos cliente. No lo he probado en servidores, pero podría ser vale la pena un tiro si es el servidor de almacenamiento en caché de credenciales. Nuestro problema era que estaban haciendo viejos credenciales, pero sólo en un equipo de cliente de base. Si el usuario ha iniciado sesión en un cliente independiente de la máquina, todo fue bien, pero si utiliza su propio equipo en su escritorio que trabajan habitualmente en él había almacenado en caché las credenciales anteriores.

  4. 3

    Si no es una cuestión de cambiar sólo el nombre de Usuario de NT, entonces parece que el servicio de autenticación es el almacenamiento en caché el viejo nombre de usuario.

    Se puede definir esta debe ser desactivada, vaya a la Configuración de Seguridad Local (en Herramientas Administrativas), y dependiendo de la versión/edición/configuración de los ajustes que son posibles pertinentes (de la memoria) «Número de inicios de sesión anteriores a cache» y «no permitir el almacenamiento de credenciales…».

    Factores adicionales a tener en cuenta:

    • La pertenencia al dominio podría afectar a este, como miembro de servidores puede heredar la configuración de dominio de
    • Aún puede ser necesario reiniciar el servidor una vez para que esto surta efecto (pero entonces usted no tiene que preocuparse de las actualizaciones en el futuro).
    • De inicio de sesión podría verse afectado el rendimiento.

    Como tal, te recomiendo probar esto primero antes de realizar la implementación en la producción (por supuesto).

  5. 1

    Reiniciar IIS, no el conjunto de la máquina, debe hacer el truco.

    • El servidor tiene el nombre de usuario antiguo en caché desde el servicio de autenticación. Esto debería funcionar.
    • -1: Él claramente que él no desea reiniciar IIS
  6. 1

    Cuando estos usuarios’ los nombres fueron cambiados, cambio sólo sus NT nombres de inicio de Sesión, o sus nombres de UPN también? los nombres de UPN son los nombres propios, y utilizado por Kerberos – que es el protocolo predeterminado para la IWA; sin embargo, si usted simplemente haga clic en cambiar su nombre en ActiveDirectory, sólo el inicio de Sesión de los cambios de nombre, aunque eso es lo que iba a usar para iniciar sesión (utilizando el valor predeterminado de windows GINA). Debajo de las mantas, windows podría traducirse en la (nueva) NT nombre de inicio de Sesión para el (antiguo) de Kerberos nombre. Esta situación persiste hasta que el ANUNCIO está obligado a actualizar la Kerberos nombre según el NT nombre de inicio de Sesión…

  7. 0

    De inicio de sesión para el servidor que ejecuta IIS utilizando el nuevo nombre de inicio de sesión en cuestión. Esta será la actualización de la credencial sin tener que reiniciar el IIS o reiniciar el servidor.

  8. 0

    Sólo como un FYI hemos tenido exactamente el mismo problema. Lo que parecía a trabajar para nosotros es ir en Active Directory y hacer un «Refresh». Inmediatamente después de esto, hemos tenido que reciclar el grupo de aplicaciones en los sitios de intranet que estaban teniendo este problema.

Dejar respuesta

Please enter your comment!
Please enter your name here