10

相互に通信する必要がある 2 つの個別の自家製アプリケーションがあります。1 つはフロントエンド アプリケーション (実際には asp.net) で、もう 1 つは会計アプリケーションへのバックエンド インターフェイスです。バックエンド インターフェイスは、このフロントエンド専用に作成されたものではありません。これは、他の多くのアプリケーションが製品と統合するために使用する汎用インターフェイスです。

ユーザーの利便性のために、フロントエンド アプリケーションで Windows 認証を提供したいと考えています。ただし、これは、認証情報を確認する必要があるバックエンド アプリケーションに認証情報を渡す必要があることを意味します。

フロントエンドを、自分自身を任意のユーザーとして認証できるバックエンドへの「信頼できる」アプリケーションとして設定したくありません。フロントエンドがハッキングされると、バックエンド システムも侵害されます。

私が理解しているように、Windows 認証でそれを行う 1 つの方法は Kerberos 委任です。ただし、これは、委任されるユーザーと、委任を行うマシン (フロントエンドを備えたサーバー) に対して明示的に有効にする必要があります。デフォルトでは、これらのオプションは Active Directory で無効になっています。多くのシステム管理者は、すべてのユーザーに対してこれらのオプションを有効にすることに躊躇していると思います。

また、これが Kerberos Delegation の意図したものであるかどうかはよくわかりません。接続しているユーザーを偽装するためにフロントエンドは必要ありません。このユーザーが自分自身を認証したことを証明する必要があるだけです。

これをどのように行いますか？

4

3 に答える 3

8

ユースケースで何ができて何ができないかはわかりませんが、Kerberos Delegation が何を意図していたのかという質問には答えることができます。

最初に、委任の前に Kerberos が行うことについて話しましょう。この部分は微妙なのでよく理解しておくことが重要です。

Kerberosは、ネットワーク上の 2 つのエンドポイント間の通信の両端の ID を認証します。これらのエンドポイントは、コンピューター上で実行されている対話型ユーザーまたはサービスである可能性があります。

これは強力な認証であるため、いかなる形式の中間者攻撃も許可しません。エンドポイントが正しく設定されていれば、侵害されないことが保証されます。サービス名のレベルまで (マシン上の II に接続している場合は、同じマシン上の SQL Server に接続する場合とは異なります)。最新の暗号化技術を多用し、安全な証明書を使用する必要があります。認証プロトコルの詳細は複雑で、ここで説明する価値はありませんが、2 つの認証エンドポイントと認証サーバー (Windows ではドメイン コントローラーが認証サーバー) の間で約 20 の異なる確認手順が必要です。

では、委任とは一体何なのでしょうか。

委任は、信頼できるソースが別のエンドポイントへの認証を続行できるようにする、Kerberos 標準に対する Microsoft の拡張機能です。

これにより、「中間者」として行動できますが、これを機能させるには、多くの設定を明示的にセットアップしたり、証明書をインストールしたりする必要があります。それは単純ではありません。（編集：詳細に関する別のSO回答があります- https://stackoverflow.com/a/954154/215752）

したがって、たとえば、誰かが Web サイトに対して認証を行い、.NET コードを SQL Server AS THE SAME USERに接続して、そのユーザーの権限でデータを読み取ることができます。

あなたの質問に答えるために、あなたが何をしたいのかわからないので、3つの選択肢を提示します。

1) Web サイトで認証しているユーザーと同じユーザーとしてバックエンド システムに接続したい。

  • この場合、Kerberos 委任は完璧です。それはまさにあなたが望むことを行います。

2) Web サイトで認証するユーザー (サービス アカウントなど) とは異なるユーザーとしてバックエンド システムに接続する場合。

  • この場合、委任は必要ありません。Web サイトへの Kerberos とバックエンドへの (別のユーザーとしての) Kerberos はうまく機能します。

3) ある時は同じユーザーとして、別の時は別のユーザーとしてバックエンド システムに接続したい。(たとえば、これがバックエンド システムの正当なユーザーであることを検証する必要がありますが、それ以外の場合はシステム アカウントとして信頼できるアクションを実行したい場合があります。これは (私の経験では) 最も一般的な使用例です。)

  • この場合、両方を使用します。ユーザー ID を検証し、バックエンドへのシステム アクセスが必要なときにサービス アカウント ID に戻す必要がある接続の委任。(私の以前の質問では、.NET プラットフォームでシステム ID に戻す方法の詳細について説明しました。How to "un-impersonate" (un-delegate?) in Kerberos を参照してください。)
于 2013-09-30T21:00:25.037 に答える
0

これは、Kerberos の仕組みと設定方法を説明した投稿です。

Windows 認証資格情報を渡す ASP.NET

于 2009-10-22T12:08:53.100 に答える
0

実際、Kerberos 委任は、まさにこのユース ケース向けに設計されています。しかし、ここでの課題は、変更したくない AD の設定を使用して、レガシー システムでこれを作成することです。

考えられるハックの 1 つは、フロント エンドがユーザーと認証時刻を送信するだけで、バックエンドが Active Directory イベント ログを照会して、そのユーザーがフロント エンドに対して認証されているかどうかを判断することです。これには、Windows イベント ログ API を使用する必要があります。また、AD のイベント ログ設定をいじって、サービス チケットの問題をログに記録する必要があります。(私の記憶では、これがデフォルトです) -

于 2012-08-06T05:32:49.207 に答える