6

何らかの理由で、クライアントは2つのKerberosレルムにログインする必要があります。たとえば、REALM1とREALM2とします。私のプリンシパルは両方のレルムで署名されており、2つの異なるキータブが作成されています（principal / host@REALM1とkeytab1およびprincipal/host @ REALM2とkeytab2）。言い換えれば、2つの異なるレルムに対してプリンシパルをkinitおよびklistすることができます。

次に、最初にいくつかのタスクをrealm1で実行する必要があり、次に他のタスクをrealm2で実行する必要があるアプリケーションを実行する必要があるため、最初にrealm1にログインし、いくつかの作業を終了してからログインする必要があります。 realm2。プログラムの途中でシステムプロパティ「java.security.krb5.conf」をリセットして実行しようとしましたが、realm1からrealm2に切り替えることができませんでした（ログインに失敗しました。デフォルトのレルムは同じままであるようです）。

検索して、関連する投稿の回答（JAASと複数のレルムを使用したKerberos認証）を確認しました。キータブがレルムにバインドされていることを理解しています。理解できないのは、2つのレルムに対して2つのキータブを生成した理由です。その結果、2つのレルムにログインしませんか？クロスレルム認証を介してそれを行う唯一の方法です。

4

5 に答える 5

3

そうしないでください。レルム間の信頼を確立すると、クライアントの元のキータブを使用して、外部レルムのすべてのタスクを実行できます。ここには少なくとも30のレルムがあり、私のUnixマシンはもちろん1つのレルムに参加しています。これはかなりうまく機能します。

于 2013-02-28T11:56:34.920 に答える
2

あなたの場合、JAASlogin.confのKRB5LoginModuleのrefreshKrb5Config=trueオプションを使用して、使用する前に構成を強制的にリロードするだけで解決できる場合があります（JVMを再起動せずにJAVAでKerberos構成をリロードするを参照）。

ただし、この共有リソースへのアクセスをシリアル化する必要があるため、これはマルチスレッドアプリケーションではうまく機能しません。Java Kerberos実装がシステムプロパティ（および単一の構成ファイル）を使用するという事実は、不必要な制限であり、おそらくバグですらあります。

クロスドメインの信頼を使用するという一般に認められた答えは、常にではありませんが、良い場合があります。たとえば、ネットワーク管理者がすべてのサービスに他のドメインを信頼させたくない場合、この1つの特定のサービスだけでは、運が悪いことになります。Javaで記述され、複数のレルムからチケットを受け入れたいサービスを提供するマルチスレッドアプリケーションがある場合、レルムごとにこのアプリケーションの1つのインスタンスを実行する必要があります（krb5.confホスト名は静的であり、keytabとkdcの変更のみです） ）。この特定のアプリケーションがSPNEGOを使用してポート443で実行されているWebサービスである場合、これは大きな頭痛の種になります。次に、異なるポートに2つのアプリケーションサーバーインスタンスが必要ですか？痛い。

于 2015-06-17T18:25:07.673 に答える
0

oVirtオープンソースプロジェクトをご覧になることをお勧めします。

oVirtエンジンのJavaコードを確認し、認証コードのbllモジュール（ovirt-engine / backend / modules / bll）を確認します（を参照DirectorySearcher.java）。いくつかのKerberosレルムへのログインをサポートしています。

ドメインの「ドメインユーザー」（主に追加されたレルム内のユーザーとグループの検索に使用）を追加できるengine-manage-domainsというツールがあります。例：

ActiveDirectoryであるドメイン「example.com」からユーザー「aaa」を追加できます。これにより、で保持され、ovirt-engineが使用するkrb5.conf定義が変更されます。/etc/ovirt-engine/krb5.conf

JAASログインオブジェクトを作成してログインを実行するコード内の場所を確認します（レルムへの有効なチケットがない場合は、明示的なログインを実行します）。

クロスレルム認証の方が良い解決策だと思いますが、そのような信頼を築くことができないシナリオに直面するかもしれません。たとえば、oVirtの場合、これはオープンソースの仮想化管理システムであり、ユーザーの組織にインストールされている他のシステムのセットアップを「妨害」したり、強制的に変更したりしてはなりません。

于 2013-05-15T17:52:26.887 に答える
0

私はパーティーに遅れていますが、これは検索でこの質問を見つけた他の人々を助けるかもしれません。

クロスレルム認証を使用するのが最適ですが、常に可能であるとは限りません。たとえば、ある組織から別の組織にデータをコピーするために信頼できるサードパーティとして行動している可能性があり、どちらもその組織に対してオープンではない可能性があります。

javax.security.auth.login.LoginContextクラスは通常、複数のエントリをサポートできる外部構成ファイルを使用します。devopsがサポートしている場合は良いアプローチですが、アプリケーションサーバーに.warファイルとしてデプロイされている場合など、それが不可能な環境はたくさんあります。（典型的な例：アプリケーションはAWS Elastic Beanstalkで自動スケーリングされます。）

この例では、Configurationオブジェクトを受け取るLoginContextコンストラクターを使用しました。必要な情報は自分で管理する必要がありますが、ほとんどすべてを自分で処理できます。（keytabファイルをダウンロードして一時ディレクトリに書き込み、Configurationオブジェクトでポイントすることができます。アプリケーションが終了するときにそのファイルを削除することを忘れないでください！）

この場合、Configurationオブジェクトはバッグであり、AppConfigurationEntryは単一のサービスの情報であることを覚えておくと役立ちます。

編集して追加：オプションで別のクレデンシャルキャッシュファイル（ccache）の場所を指定したい場合があります。ccacheファイルが複数のエントリをサポートしているかどうかは思い出せませんが、別のファイルを指定しても問題はありません。

于 2017-03-13T20:55:55.010 に答える
0

それが他の人を助ける場合：

krb5.confで、どのレルムをどのドメインに使用するかを指定できます。例：

[libdefaults]
  default_realm = A.COM

[realms]
  A.COM = {
    kdc = ...
  }
  B.COM = {
    kdc = ...
  }

[domain_realm]
  .b.com = B.COM

次に、*。b.comに接続すると、A.COMの代わりにB.COMレルムが使用され、それ以外の場合はデフォルトでA.COMになります。

詳細はこちら：https ：//web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html#domain-realm

于 2021-04-22T18:24:41.797 に答える