ユーザーのWindowsログイン名がADで変更されましたが、SQL 2008プロファイラーのセッションで古いWindowsログイン名が表示されます
背景：Active Directoryでユーザーの名前がDomain\oldnameからDomain\newnameに変更され、Domain\newnameでネットワークに正常にログインしましたが、ProfilerのLoginName列とNTUserName列にDomain\oldnameが表示されます。
ユーザーのSQL Server権限は、SQL Serverセキュリティで設定されたグループを介して付与されます。
質問：この動作を誰かが観察し、SQL ServerがまだDomain\oldnameを取得している理由を知っていますか（sp_who2は同じ情報を示します）？
ところで、ここに質問を投稿する前に調査にかなりの時間を費やしてきましたが、Profiler/SQL 2008 R2には本当の問題はないようです。
私がスタック交換を使用したのはこれが初めてなので、質問にコメントできないと思いますが、これはユーザーが参加しているADグループですか？ SQLの役割を意味する場合、人々はグループと言うことがあるので、私はいくつかの明確化を得たいと思いました。
私が尋ねる理由は、ADの名前をdomain\newuserに変更するときにユーザーがdomain\olduserのサーバーにログインしている場合、SQLに移動してログインをdomain\newuserに変更する必要があるためです。私はこれを実行しましたが、それは完全に正常に機能し、SQLを再起動するほど大胆なことをする必要はありません。最終的にアカウント名が新しい名前に変わるかどうかはわかりませんが、私はそうは思いません。
ただし、ユーザーがアクセス許可を持つADグループの一部であり、実際にサーバーにログインしていない場合はどうなるかわかりません。したがって、私はそれを調べることができるように明確にする必要があります。
SQL Server 2012インスタンス（SP2適用済み）で同じ問題が発生しました。根本的な原因はまだわかりませんが、StanleyJohnsによって提案されたADキャッシュメカニズムを調べます。
偶然、サーバーを再起動しなくても機能する簡単な解決策を見つけました。私はWindows Authenticatedログインを作成しました古いユーザー名用（はい、うまくいきました）を削除しました-問題は解決しました。
作成/ドロップ後、同じログインを2回作成できなかったため、「ドロップログイン」は古いユーザー名をADキャッシュから強制的に削除するもう1つの方法のようです。
SQL Serverは、変更が完了するまでに時間がかかる場合があります
変更されていない「sid」に基づいてキャッシュします。害はありません。
正確なルールはわかりませんが、それが起こるのを見てきました。極端な場合は、SQL Serverの再起動後にwillクリアすることが重要です。
また、sys.server_principalsと関連するsys.database_principalsにエントリがないか確認してください。これは、ユーザーがオブジェクトを所有している場合に発生する可能性があります（スキーマ修飾子なしのCREATE TABLEなど）。
私の場合、機能したのはユーザーを削除してユーザーを再度追加することだけです。 SQLジョブの所有権を確認し、データベースからDBOを削除する必要があることに注意してください。
彼女はADグループのメンバーなので、引き続きアクセスできます。 SQL Serverに表示される彼女の古いユーザー名は、ログインキャッシュからのものである可能性があります。
ログインのSIDをキャッシュする可能性があるため、古いログイン名の接続をすべて閉じてみてください。ログインはADで名前が変更されただけなので、SIDが変更されるとは思わないため、SQL Serverが古い名前で機能するためのマッピングはまだ存在しています。
ADの変更が反映されるまでにはしばらく時間がかかります。また、キャッシュされた認証トークンは、古いログイン名を表示したままアクセスを提供します。
キャッシュのパージを試すことができます：Net Use * /delete /yコマンドラインで。
または、AD資格情報を強制的に更新してみてください：control userpasswords2コマンドラインで。次に、[詳細設定]タブに移動して[パスワードの管理]を選択します。これにより、保存されたネットワークパスワードを変更できます。
これにより、サーバーを再起動する必要がなくなります。