問題タブ [kerberos-delegation]

次の状況があるとします: チケットを取得したマシンがあり、このチケットは別のマシンに転送されました。その別のマシンは、受け取ったチケットを更新できますか?

他の質問 - チケットを取得したマシンがそれを更新する場合、そのチケットが転送された他のマシンは、自分でこのチケットを更新する必要がありますか? または、最初のマシンが更新するとすぐに無効になりますか?

WindowsIdentity の ImpersonationLevel は、SPN を使用し、マシンで Kerberos 委任を許可している場合でも、委任ではなく偽装のままです。

私は開発サーバーにダブルホップする開発環境でもまったく同じ設定をしています。これをライブサーバーに公開しようとしていますが、偽装レベルを「委任」にすることができない偽装エラーが発生し続けます

他に何をする必要がありますか？Kerberos のデバッグは不可能のようです -- チェックしている SPN を確認する方法はありますか?

Windows Server 2012 の新機能である C++ でのリソース ベースの制約付き委任を実装しようとしています。

編集:これを行う IIS モジュールのコードも素晴らしいでしょう。

アカウントが特定の SPN に委任できる従来の KCD ではなく、ここでは、特定のユーザー アカウントによって実行されているすべてのプログラムにアカウントを委任できます。権限は、委任されているサービスを実行しているユーザーの "-PrincipalsAllowedToDelegateToAccount" プロパティを変更することによって付与されます。

詳細については、これを参照してください:リソース ベースの制約付き委任

これまたは有用なリソースを実装するコード サンプルを提供してくれる人はいますか?

この新機能を使用する商用製品への参照も役立ちます。

ありがとう、

デイブ

ランタイム偽装を機能させるのに苦労しています。

シナリオ：

• すべてのサーバーで匿名アクセスが無効になっており、Windows 認証が有効になっています
• クライアントが Web API 1 を呼び出す
• Web Api 1 は Web Api 2 または oData サービスを呼び出すことができます
• Web Api 1 から Web Api 2 への呼び出しは、クライアント資格情報で偽装する必要があります
• Web Api 1 から oData Service への呼び出しは偽装してはなりません
• Web Api 1 は、Web リクエストを使用して両方のサービスを呼び出します
• Kerberos 委任が適切に構成されている

何が機能するか（ちょっと）：

Web.config を使用して Web Api 1 で偽装を有効にすると、

• すべての通話が偽装されています。Web Api 1 --> Web Api 2、および Web Api 1 --> oData サービス

これは私たちが望んでいるものではありません。アプリケーション プール アカウントを介してのみ oData サービスにアクセスできるようにします。したがって、Web Api 1 からのすべての発信呼び出しを偽装したくありません。

プログラムによるなりすまし

次のコードを使用して、Web Api 1 から Web Api 2 への呼び出しのみを偽装しようとしました。

Web.config で偽装を無効にする

Web Api 1 から Web Api 2 への呼び出しを偽装します。

結果：

• Web Api 1 から oData への呼び出しは偽装されません (予想どおり)
• Web API 1 から Web API 2 への呼び出しも偽装されません。これが問題です。

質問：

• これは Web サービスで実行時の偽装を実装する方法ですか?
• 私たちは何を間違っていますか？

どんなポインタも役に立ちます。

モジュールは Kerberos 認証 (および委任) をサポートすると主張していpymssqlますが、有効にできないようです。

私が実行しているクライアントは Windows 上にあります。リバース データベース プロキシを介してダブルホップで接続する必要があります。クライアント、プロキシ、およびデータベースはすべてドメインの一部です。SQL Server Manager に接続しようとすると、成功します。しかしpymssql、Python でモジュールに接続しようとすると、うまくいきません。クライアントからデータベースに直接接続すると、Kerberos 認証を機能させることができます。しかし、プロキシを経由しようとすると失敗します。

これにより、Kerberos 認証は機能するが、委任 (ダブルホップ) は機能しないと思われます。

FreeTDSのセクションによると、ファイルを作成できるはずでC:/freetds.conf、そこから接続情報を読み取る必要があります。意味のある方法でこれを確認することはできないようです。さらに、freetds スキーマenable gssapi delegationによると、有効 (デフォルトではオフ) のときに Kerberos 委任を許可するパラメーターを追加できるはずです。

結論: Windows でpymssql の Kerberos 委任を有効にする (ダブルホップが機能するようにする) ことを検討しています。

現時点では、でファイルを作成し、C:/freetds.confそれを構成する方法をいくつか試しました。

と

サーバー A に対して Enter-PSSession を実行し、サーバー B 上の共有のディレクトリの内容を一覧表示したいと考えています。

サーバー A の Active Directory プロパティで Kerberos Constrained Delegation を設定して、サーバー B の CIFS (SMB) サービスへの Kerberos Constrained Delegation を有効にすることで、これを実現したいと考えていました。サーバー AI 上の PSSession からのサーバー B 上の共有は、PermissionDenied を取得します...

サーバー A で、サーバー B へのチケットを取得しようとしていることを示す Kerberos トラフィックも表示されません。

私が間違っていることを知っている人はいますか？

すべてのコンピューターは Windows Server 2012 R2 を実行しています。

ありがとう！

JAAS を備えたスタンドアロンの Java クライアントを使用して、SSO に WAFFLE を使用しようとしています。jaas.conf で waffle.jaas.WindowsLoginModule について言及しましたが、SSO の理想的なソリューションではないと思われるユーザー名とパスワードの入力を求められます。これを回避する方法を提案できる人はいますか?

参考までに - ウェブ/アプリ サーバーは使用していません。

次の図は、展開する必要があるアーキテクチャを示しており、問題を説明しています。

Apache Tomcat にデプロイされた一連のアプリケーション (Web サービス、Web アプリケーション) を含むサブシステムを既に設計しました。サブシステムに SSO 機能を提供するために、WSO2 Identity Server と SAML2.0 を使用してユーザーを認証し、すべてのサブシステム アプリケーションにアクセスしました。

このサブシステムは、エンタープライズ環境に統合され、エンタープライズ コンポーネントと連携する予定です。ここで、エンタープライズ ユーザーが (サブシステムの) 私のアプリケーションにアクセスできるようにする必要があります。2 つのケースがあります。

1. WSO2 Identity Server をエンタープライズ LDAP に接続します。WSO2 IS は、エンタープライズ LDAP を要求してユーザーを認証します。これはお勧めできません。

2. WSO2 IS をエンタープライズ認証サーバー (Kerberos、Radius、CAS など)、WSO2 : Brokred Authenticationと連携するようにします。

Kerberos を使用して wso2 IS に自動的に認証する方法。kerberos 認証 (または Radius) から取得したチケット?

標準の IIS サーバーに展開されるカスタムのコンパイル済み .net 4.0 dll ライブラリを開発しました。このライブラリは、ベンダーが作成したアプリケーションである Spotfire Web Player によって使用されます。このアプリケーションは、IIS サーバー上の独自のアプリケーション プールで実行されます。プラグインは、Web 要求を介してデータを取得する目的で、Tomcat を実行している別のサーバーに接続します。この要求を行うために、プラグインは、ネゴシエート セキュリティを使用して認証トークンを生成し、それを base64 文字列に変換して、パス スルー認証を容易にするために他のサーバーに渡します。IIS のアプリケーション レベルでは、Spotfire Web Player アプリケーションは Windows 認証を使用するように構成されており、さらに Windows 認証のプロバイダーでは、ネゴシエートを指定しています。Kerberos が唯一の認証方法であり、詳細設定でカーネル モード認証を無効にする (NTLM を削除するときに必要)。これは、NTLM ダブル ホップの制限を克服するために行われたものであり、これが問題である可能性があると考えられていました。アプリケーション プールは、標準の .net 4.0 統合パイプライン プールであり、システムの NetworkService アカウントで実行されます。

セキュリティの問題または IIS 構成が適切な認証方法に干渉していることを示すいくつかのシナリオを次に示します。

障害シナリオ (ダブル ホップ)
状態
• サーバーは上記のように実行されており、リモートまたは対話的にログインしているユーザーはいません。
アクション
• リモート ラップトップのユーザーが Internet Explorer ブラウザを開き、プラグインを利用するドキュメントを開こうとします。
結果
• 認証失敗の結果。

機能シナリオ (シングル ホップ)
状態
• サーバーは、リモート デスクトップ経由でログインした管理者によって上記のように実行されています。
アクション• 管理者はサーバー セッションで Internet Explorer
を開き、プラグインを利用するドキュメントを開くことに進みます 。管理者の資格情報が Zema サーバーに正常に渡され、認証されました。

機能シナリオ (ダブル ホップ)の
状態
• サーバーは上記のように実行されており、管理者はリモート デスクトップ経由でログインしており、管理者はプラグインを利用して認証に成功したドキュメントを (リモート デスクトップの IE 経由で) 正常に開いています。
アクション
• ラップトップから chrome または IE の他の標準ユーザーが、プラグインを使用するドキュメントを開こうとします。
結果
• すべてのユーザーが認証されます。ドキュメントが最初にサーバー自体で開かれた後でのみ。

機能シナリオ (シングル ホップ)の
状態
• 上記の IIS サーバーとは異なり、このプラグインは、ユーザーのローカル ラップトップで実行されるクライアント側の .net アプリケーションでも利用できます。このデスクトップ アプリケーション (Spotfire アナリスト ソフトウェア) で使用されるものとまったく同じ DLL ライブラリが IIS で使用されます。
アクション
• ユーザーは、プラグインを使用するラップトップでドキュメントを開きます。
結果
• このシナリオでは、ユーザーのラップトップはプラグインを実行し、認証トークンを生成して、Zema サーバーに直接送信します。IIS サーバーはまったく写っていません。このシナリオでは、常に認証が成功します。

ありがとう！