Pourquoi suser_name () ne refléterait-il pas un changement de nom de compte AD?

L'un des noms de nos utilisateurs a été légalement modifié, nous avons donc changé leur nom d'utilisateur Active Directory pour qu'il corresponde - de domaine \ ancien nom à domaine \ nouveau nom. Cependant, lorsque suser_sname () est appelé par cet utilisateur dans une procédure stockée, il renvoie l'ancien nom, pas le nouveau.

La recherche sur Google m'a conduit à KB 946358 qui suggère que leur nom est mis en cache sur le serveur et non mis à jour, probablement parce que suser_name () appelle LsaLookupSids. Cependant, la solution de contournement dans cet article implique le redémarrage du serveur, et même si c'était le cas, j'aimerais toujours comprendre le problème.

Si je change mon contexte pour le leur, le nom correct revient:

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

... J'aurais supposé que cela appellerait également LsaLookupSids, et retournerait donc le nom incorrect. Il semble probable que je ne comprenne pas vraiment les mécanismes à l'œuvre ici.

Quelques observations qui peuvent être importantes:

Cet utilisateur n'a pas de connexion explicite sur le serveur. Mais ils sont membres d'un groupe AD qui le fait. Le nom modifié (domaine \ nouveau nom) apparaît dans le jeu de résultats pour exec xp_logininfo 'domain\ADGroupName', 'members'; le domaine \ oldname ne fonctionne pas.
L'utilisateur appelle suser_name () à partir d'une procédure stockée, appelée à partir d'une requête passthrough dans une MDB Access 2003.
Nous avons changé de nombreux noms de comptes d'utilisateurs dans le passé, mais nous n'avons observé ce problème que la semaine dernière (deux modifications ont été apportées la semaine dernière, les deux semblent présenter le problème).
Le serveur exécute Sql Server 2008 SP3 x64 sur l'édition Windows 2008 R2 Datacenter.

Que se passe-t-il? En tant que DBA, que puis-je faire ou où puis-je chercher à résoudre ce problème?

— Warrior Bob
source

Le service MSSQLSERVER (ou quel que soit le nom de l'instance) se connecte-t-il en tant que système local ou connexion réelle? La valeur peut être mise en cache dans le registre du compte exécutant la recherche. Dans votre cas, vous étiez connecté et faites la demande. Je pense que peut-être si vous utilisez un compte régulier pour exécuter SQL Server (comme il se doit), alors connectez-vous à SQL Server en tant que connexion "SQL Server", puis exécutez votre EXECUTE ASet SELECT SUSER_NAME()testez. Aussi, avez-vous essayé SUSER_SNAME()et l'une des 100 autres variantes?

— Solomon Rutzky

Essayez de créer une connexion sur l'instance en utilisant le nouveau nom. Cela n'aura aucun effet sur leurs autorisations. Exécutez SUSER_SNAME(), il devrait être fixé à ce point. Vous pouvez ensuite essayer de supprimer la connexion et voir si elle conserve le nouveau nom.

— Kenneth Fisher

@srutzky Il s'agit d'une instance MSSQLSERVER par défaut exécutée sous un compte de domaine. Malheureusement, je n'ai pas le mot de passe pour me connecter avec. Je n'ai pas encore essayé suser_sname () en tant qu'utilisateur, je pense que c'est la même chose que suser_name () si aucun argument n'est donné. Cela vaut la peine d'essayer - merci!

— Warrior Bob

SQL Server fait correspondre tous les comptes par le SID - qu'il s'agisse de SQL ou de domaine. Étant donné que les SID de domaine proviennent de Active Directory, la modification du nom ne modifie pas le SID. S'il a été mis en cache, l'ancien nom sera retourné. Si une connexion existe déjà, le nom de la connexion sera renvoyé, qu'il s'agisse toujours du même nom ou non, tant que les SID correspondent. C'est la même chose pour les utilisateurs de bases de données.

— Sean Gallardy

Vous pouvez essayer d'exécuter ipconfig /flushdnset à ipconfig /registerdnspartir d'une ligne de commande pour voir si cela résout le problème.

— RLF

Cela pourrait-il être lié à la mise en cache avec Kerberos? (juste une supposition bien que cela ne soit pas lié) http://blogs.technet.com/b/tspring/archive/2014/06/23/viewing-and-purging-cached-kerberos-tickets.aspx

— Normoe
source

Je ne peux pas dire avec certitude que c'est le problème, mais je crois que c'est quelque chose comme ça. Le redémarrage du serveur (qui s'est produit pour des raisons distinctes) semble l'avoir clarifié, du moins pour ce cas. Il n'est pas clair si cela se reproduira.

— Warrior Bob

C'est une bonne suggestion, j'aurais dû y penser! :-) C'est ce que nous avons fait avant pour résoudre les problèmes de kerberos mis en cache. Heureux que vous ayez réussi!

— Normoe