32

これが私のシナリオです。機能するために統合 Windows 認証を使用するアプリケーションを作成しました。では、自分の Web サイトのユーザーの現在の情報を取得するためApplication_AuthenticateRequest()に使用します。HttpContext.Current.User.IdentityWindowsPrincipal

ここが面白い部分です。一部のユーザーは最近結婚し、名前が変わりました。(つまり、ユーザーの NT ログインが からjsmithに変わりますjjones)、アプリケーションがユーザーを認証すると、IIS はユーザーの OLD LOGIN を渡します。jsmithサーバーを再起動するまで、アプリケーションに渡されたままです。クライアントのログオフは機能しません。アプリ プールを再起動しても機能しません。完全な再起動のみ。

ここで何が起こっているか知っている人はいますか？この問題を引き起こしているキャッシュをフラッシュするために使用できるコマンドはありますか? サーバーの構成が間違っていますか?

注: IIS、アプリケーション プール、またはマシンを再起動したくありません。これは生産用のボックスであるため、これらは実際には実行可能なオプションではありません。

アビッド -

はい、ログイン名とともに UPN が変更されました。Mark/Nick... これは運用エンタープライズ サーバーです... ただ再起動したり、IIS を再起動したりすることはできません。

フォローアップ（後世のために）：

Grhm の答えは的を射ていました。この問題は、アプリケーションを使用する人が多くない低ボリュームのサーバーで発生しますが、ユーザーの ID をキャッシュに保持するために十分な要求が行われます。デフォルトの 10 分後にキャッシュ項目が更新されない理由を説明しているように見えるKBの重要な部分は次のとおりです。

キャッシュ エントリはタイムアウトしますが、アプリケーションによるクエリの繰り返しにより、既存のキャッシュ エントリがキャッシュ エントリの最大有効期間にわたって存続する可能性があります。

私たちのコードの何がこれを引き起こしているのか (繰り返しのクエリ) は正確にはわかりませんが、私たちにとってうまくいった解決策はLsaLookupCacheExpireTime、一見わいせつなデフォルトの 1 週間からわずか数時間に値を削減することでした。これにより、ユーザーが現実の世界で影響を受ける可能性が実質的にゼロになり、同時に、ディレクトリ サーバーに対して極端な数の SID-Name ルックアップが発生することもありません。IMO のさらに優れたソリューションは、ユーザー データをテキストのログイン名にマッピングする代わりに、アプリケーションが SID でユーザー情報を検索することです。(ベンダーの皆さん、注意してください! アプリケーションで AD 認証に依存している場合は、認証データベースに SID を配置する必要があります!)

4

8 に答える 8

25

最近、同様の問題が発生しました。Robert MacLean の回答に記載されているように、ユーザーとしてログインしていない場合、AviD のグループ ポリシーの変更は機能しません。

説明されているようにLSA ルックアップ キャッシュのサイズを変更すると、MS KB946358が再起動やアプリケーション プールやサービスのリサイクルなしで機能することがわかりました。

これは、同様の質問に対する回答として見つかりました:ユーザーのログオン名を変更した後の認証が間違っています。

次のようなシステム コールを調べることができます。

LookupAccountName()

LookupAccountSid()

LsaOpenPolicy()

それらを使用して C++/CLI (/Managed-C++) アプリを記述し、LSA キャッシュを調べることができます。

于 2011-10-07T09:49:53.523 に答える
4

AviDが特定した問題は、レジストリから制御できる Active Directory キャッシュです。ソリューションによっては、ユーザーが実際にログオンしているかどうかに応じて、Avid のグループ ポリシー オプションが失敗するか機能します。

どのようにキャッシュされるかは、IIS での認証方法によって異なります。Kerberos である可能性があるため、Kerberos が原因である場合にクリアを行うには、kerberos チケットをパージするパージ オプションを使用してklistを試してください。これにより、次の試行で AD への再認証が強制され、詳細が更新されます。

また、これを実装することを検討することをお勧めします。これは、少し複雑ですが、エラーが発生しにくいものです。

于 2009-02-24T11:01:04.257 に答える
3

NT ユーザー名だけを変更するだけの問題ではない場合、認証サービスが古いユーザー名をキャッシュしているように見えます。
これを無効に定義し、ローカル セキュリティ設定 (管理ツール内) に移動します。バージョン/エディション/構成に応じて、(メモリから) 関連する可能性のある設定は、「キャッシュへの以前のログオン数」と「実行」です。資格情報の保存を許可しない...".

考慮すべきその他の要因:

  • メンバーサーバーがドメイン設定を継承する可能性があるため、ドメインメンバーシップがこれに影響を与える可能性があります
  • これを有効にするには、サーバー全体を一度再起動する必要がある場合があります (ただし、将来の更新について心配する必要はありません)。
  • ログオンのパフォーマンスが影響を受ける可能性があります。

そのため、本番環境にデプロイする前に、まずこれをテストすることをお勧めします (もちろん)。

于 2009-02-23T13:13:14.790 に答える
1

マシン全体ではなく、IISを再起動することでうまくいくはずです。

于 2008-10-03T21:38:47.957 に答える
1

これらのユーザーの名前が変更されたとき、NT ログイン名だけを変更しましたか、それとも UPN 名も変更しましたか? UPN 名は適切な名前であり、IWA の既定のプロトコルである Kerberos によって使用されます。ただし、クリックして ActiveDirectory で名前を変更すると、NT ログイン名だけが変更されます。たとえそれがログインに使用されるものであっても (デフォルトの Windows GINA を使用)。内部では、Windows は (新しい) NT ログイン名を (古い) Kerberos 名に変換します。これは、AD が NT ログイン名に従って Kerberos 名を強制的に更新するまで続きます...

于 2008-10-05T01:08:50.730 に答える
0

問題の新しいログイン名を使用して、IISを実行しているサーバーにログインします。これにより、IISを再起動したり、サーバーを再起動したりせずに、資格情報が更新されます。

于 2009-03-20T18:05:43.113 に答える
0

参考までに、まったく同じ問題がありました。私たちにとってうまくいくように見えたのは、Active Directory に移動して「更新」を行うことです。この直後に、この問題が発生していたイントラネット サイトのアプリケーション プールをリサイクルする必要がありました。

于 2011-06-02T12:36:58.457 に答える