IIS古いユーザー名をアプリケーションに返す
これが私のシナリオです。動作するために統合Windows認証を使用するアプリケーションを作成しました。 Application_AuthenticateRequest()では、HttpContext.Current.User.Identityを使用して、自分のWebサイトのユーザーの現在のWindowsPrincipalを取得します。
これが面白い部分です。一部のユーザーは最近結婚し、名前が変わりました。 （つまり、ユーザーのNTログインがjsmithからjjonesに変更されます）そして、アプリケーションがそれらを認証すると、IISは古いログインを渡します。サーバーを再起動するまで、jsmithがアプリケーションに渡されます！クライアントからのログオフは機能しません。アプリプールの再起動は機能しません。完全な再起動のみです。
ここで何が起こっているのか誰か知っていますか？この問題を引き起こしているキャッシュをフラッシュするために使用できるコマンドはありますか？サーバーが正しく構成されていませんか？
注：IIS、アプリケーションプール、またはマシンを再起動したくありません。これはプロダクションボックスであるため、これらは実際には実行可能なオプションではありません。
AviD-
はい、UPNはログイン名とともに変更されました。そしてMark/Nick ...これは本番エンタープライズサーバーです...単に再起動したり、IIS再起動したりすることはできません。
フォローアップ（後世のために）：
Grhmの答えは的を射たものでした。この問題は、アプリケーションを使用する人があまりいない少量のサーバーで発生しますが、ユーザーのIDをキャッシュに保持するのに十分な要求が行われます。 [〜＃〜] kb [〜＃〜] の重要な部分は、デフォルトの10分後にキャッシュアイテムが更新されない理由を説明しているようです。
キャッシュエントリはタイムアウトしますが、アプリケーションによるクエリが繰り返されると、キャッシュエントリの最大存続期間中、既存のキャッシュエントリが存続する可能性があります。
コードの何がこれを引き起こしているのか（繰り返しのクエリ）は正確にはわかりませんが、私たちのために働いた解決策は、LsaLookupCacheExpireTime値を一見わいせつなデフォルトの1週間からほんの数時間に減らすことでした。これにより、ユーザーが現実の世界で影響を受ける可能性が実質的にゼロになりますが、同時に、ディレクトリサーバーに対して極端な数のSID-Nameルックアップが発生することはありません。 IMOのさらに優れたソリューションは、アプリケーションがユーザーデータをテキストのログイン名にマッピングする代わりにSIDでユーザー情報を検索することです。 （ベンダーに注意してください！アプリケーションでAD認証に依存している場合は、認証データベースにSIDを配置することをお勧めします！）
最近同様の問題が発生しました。RobertMacLeanの answer で述べたように、ユーザーとしてログインしていない場合、AviDのグループポリシーの変更は機能しません。
説明されているようにLSAルックアップキャッシュのサイズを変更すると、MS KB946358 アプリプールやサービスを再起動またはリサイクルせずに機能することがわかりました。
私はこれをこの同様の質問への答えとして見つけました： ユーザーのログオン名を変更した後の間違った認証 。
次のような次のシステムコールを調べることをお勧めします。
LookupAccountName()
LookupAccountSid()
LsaOpenPolicy()
それらを使用して、LSAキャッシュに問い合わせるC++/CLI（/ Managed-C++）アプリを作成できます。
ここでも過去にIISで認証情報のキャッシュの問題が発生したことがあります。数日間グーグルした後、キャッシュを表示およびクリアするために使用できるあいまいな（少なくとも私たちにとっては）コマンドに遭遇しました。資格情報。
スタート->実行（またはWinKey + R）と入力control keymgr.dll
これにより、クライアントマシンの問題が修正されました。サーバーで試したことはありませんが、サーバーが資格情報をキャッシュしている場合は、試してみる価値があるかもしれません。私たちの問題は、古い資格情報を取得していたが、クライアントマシンベースでしか取得できなかったことでした。ユーザーが別のクライアントマシンにログインした場合はすべて問題ありませんでしたが、自分のデスクで通常作業している自分のマシンを使用した場合は、古い資格情報がキャッシュされていました。
AviD で識別される問題は、 レジストリ を介して制御できるActiveDirectoryキャッシュです。ソリューションに応じて、Avidのグループポリシーオプションは、実際にユーザーをログオンしているかどうかに応じて失敗または機能します。
キャッシュされる方法は、IISでの認証方法によって異なります。 Kerberosの可能性があると思われるので、Kerberosが原因である場合はクリアを行うには、kerberosチケットをパージするパージオプションを指定して klist を試してください。これにより、ADのADへの再認証が強制されます。次の試行と詳細の更新。
また、少し複雑ですがエラーが発生しにくい this の実装を検討することをお勧めします。
NTユーザー名のみを変更する問題ではない場合、認証サービスが古いユーザー名をキャッシュしているように見えます。
これを無効に定義し、（管理ツールの）ローカルセキュリティ設定に移動します。バージョン/エディション/構成に応じて、（メモリから）関連する可能性のある設定は「以前のログオン数キャッシュ」および「資格情報の保存を許可しない...」。
考慮すべき追加の要因：
- メンバーサーバーがドメイン設定を継承する可能性があるため、ドメインメンバーシップがこれに影響を与える可能性があります
- これを有効にするには、サーバー全体を1回再起動する必要がある場合があります（ただし、将来の更新について心配する必要はありません）。
- ログオンパフォーマンスが影響を受ける可能性があります。
そのため、本番環境にデプロイする前に、まずこれをテストすることをお勧めします（もちろん）。
これらのユーザーの名前が変更されたとき、NTログイン名のみを変更しましたか、それともUPN名も変更しましたか？ UPN名は固有名詞であり、Kerberosによって使用されます。これはIWAのデフォルトプロトコルです。ただし、クリックしてActiveDirectoryで名前を変更すると、NTログイン名のみが変更されます。これは、ログインに使用するものです（デフォルトのWindows GINAを使用）。裏で、ウィンドウは（新しい）NTログイン名を（古い）Kerberos名に変換します。これは、ADがNTログイン名に従ってKerberos名を更新するように強制されるまで続きます。
マシン全体ではなく、IISを再起動することでうまくいくはずです。
このリンク "IISでのユーザートークンのデフォルト間隔の変更" Microsoftサポートからのリンクが役立つはずです。
問題の新しいログイン名を使用してIISを実行しているサーバーにログインします。これにより、IISを再起動したり、サーバーを再起動したりせずに、資格情報が更新されます。
参考までに、まったく同じ問題が発生しました。私たちにとってうまくいったように見えたのは、ActiveDirectoryにアクセスして「更新」を実行することです。この直後、この問題が発生していたイントラネットサイトのアプリケーションプールをリサイクルする必要がありました。