¿Por qué suser_name () no refleja un cambio de nombre de cuenta AD?

Uno de los nombres de nuestros usuarios fue cambiado legalmente, por lo que cambiamos su nombre de usuario de Active Directory para que coincida, desde dominio \ nombre antiguo a dominio \ nombre nuevo. Sin embargo, cuando este usuario llama a suser_sname () en un procedimiento almacenado, devuelve el nombre antiguo, no el nuevo.

Buscar en Google me llevó a KB 946358, que sugiere que su nombre se está almacenando en caché en el servidor y no se actualiza, presumiblemente porque suser_name () está llamando a LsaLookupSids. Sin embargo, la solución en ese artículo implica reiniciar el servidor, e incluso si fuera así, me gustaría entender el problema.

Si cambio mi contexto por el de ellos, vuelve el nombre correcto:

EXECUTE AS LOGIN = 'domain\newname'
GO
SELECT suser_name()   --returns 'domain\newname'

... Supuse que esto también llamaría a LsaLookupSids, por lo que devolvería el nombre incorrecto. Parece probable que realmente no entiendo los mecanismos que funcionan aquí.

Algunas observaciones que pueden importar:

Este usuario no tiene un inicio de sesión explícito en el servidor. Pero son miembros de un grupo de AD que lo hace. El nombre cambiado (dominio \ nuevo nombre) aparece en el conjunto de resultados para exec xp_logininfo 'domain\ADGroupName', 'members'; dominio \ nombre antiguo no.
El usuario está llamando a suser_name () desde un procedimiento almacenado, llamado desde una consulta de paso en un MDB de Access 2003.
Hemos cambiado muchos nombres de cuentas de usuarios en el pasado, pero solo hemos observado este problema en la última semana (se hicieron dos cambios la semana pasada, ambos parecen exhibir el problema).
El servidor ejecuta Sql Server 2008 SP3 x64 en Windows 2008 R2 Datacenter edition.

¿Que esta pasando? Como DBA, ¿qué podría hacer o dónde podría buscar para resolver esto?

— Guerrero Bob
fuente

¿El servicio MSSQLSERVER (o cualquiera que sea el nombre de la instancia) está iniciando sesión como sistema local o un inicio de sesión real? El valor puede almacenarse en caché en el registro de la cuenta que ejecuta la búsqueda. En su caso, inició sesión y realizó la solicitud. Estoy pensando que tal vez si está utilizando una cuenta regular para ejecutar SQL Server (como debería hacerlo), entonces tal vez inicie sesión en SQL Server como el inicio de sesión "SQL Server", luego ejecute su EXECUTE ASy SELECT SUSER_NAME()pruebe. Además, ¿has probado SUSER_SNAME()alguna de las otras 100 variaciones?

— Solomon Rutzky

Intente crear un inicio de sesión en la instancia con el nuevo nombre. Esto no tendrá ningún efecto en sus permisos. Ejecutar SUSER_SNAME(), debería arreglarse en ese punto. Luego puede intentar soltar el inicio de sesión y ver si conserva el nuevo nombre.

— Kenneth Fisher

@srutzky Es una instancia predeterminada de MSSQLSERVER que se ejecuta bajo una cuenta de dominio. Lamentablemente no tengo la contraseña para iniciar sesión. Todavía no he probado suser_sname () como usuario, creo que es lo mismo que suser_name () si no tengo argumentos. Sin embargo, vale la pena intentarlo, ¡gracias!

— Guerrero Bob

SQL Server coincide con todas las cuentas por el SID, ya sea SQL o dominio. Dado que los SID de dominio provienen del directorio activo, cambiar el nombre no cambia el SID. Si se almacenó en caché, se devolverá el nombre anterior. Si ya existe un inicio de sesión, se devolverá el nombre del inicio de sesión si sigue siendo el mismo nombre o no, siempre que los SID coincidan. Esto es lo mismo para los usuarios de bases de datos.

— Sean Gallardy el

Puede intentar ejecutar ipconfig /flushdnsy ipconfig /registerdnsdesde una línea de comandos para ver si eso soluciona el problema.

— RLF

¿Podría esto estar relacionado con el almacenamiento en caché con Kerberos? (aunque solo una suposición podría no estar relacionada) http://blogs.technet.com/b/tspring/archive/2014/06/23/viewing-and-purging-cached-kerberos-tickets.aspx

— Normoe
fuente

No puedo decir con certeza que este sea el problema, pero creo que esto o algo así es. Reiniciar el servidor (que sucedió por razones separadas) parece haberlo solucionado, al menos en este caso. No está claro si volverá a aparecer.

— Guerrero Bob

Esa es una buena sugerencia, ¡debería haber pensado en eso! :-) Eso fue lo que hicimos antes para aclarar los problemas de kerberos en caché. Me alegro de que hayas tenido éxito!

— Normoe