後でユーザーを偽装するためにKerberosチケットを保存することはできますか？後で偽装するためにKerberos認証を保存する
私は、ユーザーが外部システムを直接呼び出してデータを処理するシナリオを持っています。外部システムは、ADで偽装/認証されているユーザーに依存しています。
これで、キューがユーザーと外部システムの間にあり、キューからの作業がWindowsサービスによってそのキューから外部システムに引き渡されるように、呼び出しシステムを変更する必要があります。 このサービスは、外部システムがユーザー権利を正しく処理できるように、ユーザーを偽装する必要があります。
外部システムを変更できないため、ユーザー名とパスワードをキューに保存できないため、ユーザーがキューに新しい作業項目を追加した後にサービスでユーザーを偽装すると、Kerberosチケットを保存できますかそのデータを外部システムに渡すときに使用されます。 C＃でどうすればいいですか？
保存することは可能かもしれませんが、チケットは短期間で保存されると思います。残念ながら、ネットワーク上に適切な委任が設定されていない限り、サービスからサービスへの認証が失敗するKerberos double-hop issueに確実に入ります。これには、アクティブディレクトリにいくつかのSPN（サービスプリンシパル名）を設定して、サーバー間で相互に信頼するように指示する必要があります。
私は決してKerberosのチケットを保存しようとしたことはありません。そのため、委任とSPNを使って戦っても機能しない可能性があります。
ここには、IIS7 to handle double hop Kerberos ticketsとhandling it from the networks point of viewという別の記事を設定する簡単な記事があります。
私はもっと助けて記事を書くのではなく、記事を投稿することができればいいと思っていますが、あなたが調査したところでは、これがKerberos認証の悩みであることがわかります。がんばろう！
マイクロソフトの男は、「セキュリティは、アプリケーションを展開するときにアプリケーションを停止させるものです」と言いました。 （彼のポイントは、現実的なセキュリティ設定でテストすることでした）。
チケットの有効期間は10時間ですが、発行日からの時間です。ユーザーがリクエストを行うまでに残っている部分のほんの一部しかない場合があります。
基本的な問題を単純に別の方法で解決することをお勧めします。
なぜキューに入れなければならないのですか？ピーク時に外部サービスが停止するためですか？
実際の問題を知らずに、このようにしないと言っている以外に、アドバイスするのは難しいです。
キューは複数の要件/制限のために選択されました（サービスは24時間365日利用できませんが、アイテムはキューに追加する必要があります。キューは信頼できるものでなければなりません。クライアントは外部サービスの作業を追加する必要がありますが、作業が開始または終了する前にログオフすることができます） 外部サービスは自分の管理下にないため、「ふりをする」オプションを追加できません。 チケットの有効期間は短くても、最大10時間を超えて更新することができます。 TL：DR：キューが必要です。再起動後もすべての解決策が残っていなければなりません。 – GaussZ
@GaussZ：リブートに耐えられる解決策は、恐ろしいセキュリティホールです。それについて考える。これはやりにくい理由があります。それは良い考えではないからです。私はあなたがTL; DRを私の他の提案に言ったことを知っていますが、多分あなたは時間を取るべきです。提案1または2があなたのベストベットです。 – Ben
もちろん、すべてのアクセス権のセキュリティホールであってはいけません。そのため、Kerberosトークンのアプローチが好まれています。誰かがサーバーを侵害し、キューに格納されているKerberosトークンを使用している場合、彼はすでにWebサービスを危険にさらしてトークンを使用して送信します。 私は別のアプローチも使いたいと思いますし、あなたの提案には感謝していますが、制限がある（特に外部システムを変更できない）ので、このアイデアは私を最良の選択肢として襲いました。 – GaussZ
このソリューションは、巨大な警告が付属していますが、その代わりに、トークン/チケットを格納するので、あなたが資格情報を提供ずに偽装のトークンを取得するためにLsaLogonUser機能と制約付き委任を使用することができ、現時点では作業はする準備ができていますデキューされます。
これは、内部リソースへのアクセスを偽装されたドメインユーザーにWindows以外の資格情報（パブリックWebサイトなど）をマップできるプロトコルの移行方法です。
これは明らかに巨大な潜在的なセキュリティホールであり、LsaLogonUserを呼び出すプロセスを実行するアカウントにはSeTcbPrivilege（「オペレーティングシステムの一部として機能する」）を付与する必要があります。
チケットを保管する方法があれば、明らかにはるかに良いでしょうが、私が質問したときに最初に思ったのは、@ベンが述べた有効期限問題です。
編集： A coupleexcellent articlesexcellent articlesプロトコルの移行と制限された委任については、リスクの広範な範囲をカバーしています。
サービスで使用しているキューの種類はありますか？システムメッセージキュー、MSMQ？使用しているキューがRPCに基づいている場合、サービスがエンドユーザーを偽装する可能性があるためです。 – JPBlanc
SQL Service Brokerキュー。 – GaussZ