0

アプリケーションにエラーがあります。誰かが助けてくれることを願っています。何が起こっているかの要約は次のとおりです。

1) アプリケーションには、Silverlight アプリケーション、Web 層、およびバックエンド ビジネス ロジック層の 3 層アーキテクチャがあります。

  • ビジネス ロジック層 (大部分はレガシ コード) は、Windows サービスとして実行されます。
  • お客様ごとに1つのサービスがあります。
  • システムには複数のビジネス ロジック サーバーがあり、それぞれがクライアント用に複数の Windows サービスを実行しています。
  • Silverlight ブラウザー アプリケーションは一連の WCF Web サービスを介して Web 層と通信し、Web 層は .NET Remoting を介してビジネス ロジックと通信します。
  • 各クライアントの Windows サービスは、起動時にリモート エンドポイント用の TCP ポートを確立します。
  • Web 層の役割は、着信要求を取得し、それを正しいサービスにルーティングすることです。

2) SilverLight アプリケーションに散発的な問題があります。インターフェイスに、「ソース 'ExceptionManagerInternalException' のログを開けません。書き込みアクセス権がない可能性があります」または「SSPI の呼び出しに失敗しました。内部例外を参照してください。」どちらのエラーも同じ問題が原因で発生します。システムの管理者権限を持つユーザーには 2 番目のメッセージが表示され、「通常の」クライアント ユーザーには最初のメッセージが表示されます。

3) エラーの詳細は、Web サーバーのイベント ログで確認できます。システム イベント ログには、次のように表示されます。

Kerberos クライアントは、aaa$ から KRB_AP_ERR_MODIFIED エラーを受け取りました。使用されたターゲット名は HOST/bbb.cab.local でした。これは、ターゲット サーバーがクライアントから提供されたチケットの復号化に失敗したことを示します。これは、ターゲット サーバー プリンシパル名 (SPN) が、ターゲット サービスが使用しているアカウント以外のアカウントに登録されている場合に発生する可能性があります。ターゲット SPN がサーバーによって使用されるアカウントに登録されていること、およびそのアカウントにのみ登録されていることを確認してください。このエラーは、ターゲット サービスが、Kerberos キー配布センター (KDC) がターゲット サービス アカウントに対して持っているものとは異なるパスワードをターゲット サービス アカウントに使用している場合にも発生する可能性があります。サーバー上のサービスと KDC の両方が最新のパスワードを使用するように更新されていることを確認してください。サーバー名が完全修飾されていない場合、ターゲット ドメイン (domain.

4) このバグが発生したときに発生するイベントを確認できるトレース ファイルをキャプチャしました。

  • SOAP 呼び出しが Web API (WCF) に入ってくる
  • クライアント ID は http ヘッダーから復元されます。クライアント ID を使用すると、ブラウザーのインスタンスで作業しているユーザーを一意に識別でき、クライアントが最初にシステムにログオンしたときにヘッダーに挿入されます。彼らがログオンしたとき、接続先のサービスとともにクライアント ID も Web サーバーにキャッシュしました。これは、エンドポイントの WCF 動作に実装されています。
  • このルックアップを使用して、システムのアドレス (つまり、サーバーの名前と tcp ポート) とサービスの SPN (HOST\) がスレッド ストレージに配置されます。
  • ロギング (NLOG) を使用して、このプロセスが正常に行われていることを確認しました
  • Web 層のコードは、サーバーに対して .NET Remoting 呼び出しを行います。
  • 次に、Web 層のコードは、ビジネス ロジック層に対して .NET Remoting 呼び出しを行います。ClientChannelSink では、サーバーのアドレスと SPN をスレッド ストレージから取得し、正しい宛先に移動するようにリモート呼び出しを構成します。NLOG トレースにより、正しい詳細がスレッド ストレージから取得され、呼び出しの構成に使用されることが確認されました。UserA@domain.local が HOST\aaa の SPN を使用して aaa にアクセスするように要求したトレースを確認しました。
  • ネットワーク モニター トレースから、DNS パッケージを確認でき、サーバー名に対して正しい IP アドレスが返されます。
  • ネットワーク モニター トレースから、DC に対して Kerberos チケット要求が行われていることがわかります。
  • この要求には、予想とは異なるサーバーの SPN が含まれます (トレースでは、要求は HOST\bbb を要求しました)。
  • Kerberos チケット サービスは、要求されたサービス (HOST\bbb) のユーザー (UserA@domain.local) の有効な Kerberos チケットを返します。
  • 間違ったサービスの有効な Kerberos チケットを使用して、予期されるサービス (サーバー aaa) に要求が送信されます。
  • サービス (サーバー aaa 上) は要求を拒否します。Kerberos チケットは HOST\aaa ではなく HOST\bbb 用であるため、これは正当です。

イベント ログの「アドバイス」のいずれもがこの問題の原因であるとは思いません。メッセージに記載されている問題は、常に完全な障害を引き起こすように見えます。

asp.net スレッドの俊敏性について読みましたが、これがこの問題の原因であるとは思いません。常に正しいサーバーに要求を送信しますが、間違った Kerberos チケットを使用しているためです。スレッド ストレージの「間違った」設定を使用していた場合、そのサーバーの一致する Kerberos チケットを使用して、間違ったサーバーに要求を送信します。原因またはこれをさらに調査する方法についての助けをいただければ幸いです。

4

1 に答える 1

0

あなたのバックエンド インターフェイスについてはわかりませんが、Kerberos チケット自体を明示的に渡す必要はありません。Windows プリンシパルを作成し、サーバーで偽装を許可するかどうかを決定するだけです。その場合は、ドメインに SPN を作成して、委任のために特定のサービスを信頼する必要があります。

ドメイン内のビジネス層/データ層の HOST\aaa サーバーのアカウントとアドレスに SPN が定義されていますか?

ここでの他のオプションは、ビジネス ロジック内で委任を完全にバイパスし、フロント エンドでログインを実行してから、それを使用してアプリ内に独自のセキュリティ権限を作成することです。そうすれば、ビジネス/データレイヤー内で kerberos トークンを渡す必要がまったくなくなります。

于 2012-04-26T13:18:45.003 に答える