Virtual DataPort サーバーでの Kerberos 認証の設定

Virtual DataPort サーバーで Kerberos 認証を設定するには、まず『インストールガイド』に記載されている「 Kerberos に関するインストール後のタスク 」を行う必要があります。

その後、管理者ユーザーとして Administration Tool にログインし、以下の手順に従います。

  1. VQL シェルで以下のコマンドを実行します。

    CALL logcontroller('com.denodo.util.logging.JavaConsoleLogging', 'DEBUG');
    

    このコマンドを実行すると、 Kerberos のデバッグ情報 を確認できます。

  2. [Administration] メニュー > [Server configuration] をクリックします。次に [Server authentication] タブ、[Kerberos] の順にクリックします。

Kerberos configuration wizard

Kerberos 構成ウィザード

ウィザードで以下の情報を指定します。

  1. [Use Kerberos] を選択します。

  2. [Server principal] ボックスに、 keytab ファイルの作成に使用する「サービスプリンシパル名」 (SPN) を入力します。

    たとえば、次のコマンドを使用して SPN を作成したとします。

    setspn -S HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM CONTOSO.COM\denodo_server
    

    この場合、「 HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM 」と入力します。

  3. [Key tab file] ボックスに、 keytab ファイルのパスを入力します。

    重要

    相対パスではなく絶対パスを入力します。

  4. 現在の環境が次のいずれかの状況でない限り、[Kerberos configuration file] ボックスは空のままにしておきます。

    • Virtual DataPort が実行されているホストが Kerberos レルム (Windows Active Directory ドメインなど) に属して いない

    • Virtual DataPort が実行されているホストが Linux または Unix である。

    • クロスドメインシナリオを使用している。つまり、組織が複数のドメインを使用している。

    現在の環境がこのいずれかの状況にあてはまる場合は、ファイル krb5.conf または krb5.ini へのパスを入力します。

    通常、krb5 ファイルは Active Directory の管理者が提供できます。すでに Kerberos 認証を使用しているアプリケーションの 1 つを使用して、ファイルが正しいことを確認するようお勧めします。

  5. Kerberos を初めて設定する場合は、問題が生じた場合に備えて [Activate Kerberos debug mode] チェックボックスをチェックすることをお勧めします。Kerberos の設定が完了したら、これを無効にして、ログファイルが Kerberos のデバッグメッセージでいっぱいにならないようにします。

    手順 1 で、ログカテゴリ com.denodo.util.logging.JavaConsoleLogging を有効にしたので、Kerberos デバッグメッセージは <DENODO_HOME>/logs/vdp/vdp.log に格納されます。

    この変更を行い、Virtual DataPort の起動後直ちに変更が適用されるようにするには、 <DENODO_HOME>/conf/vdp/log4j2.xml ファイルを編集し、次の行を <Loggers> 行の 直下 に追加します。

    <Logger name="com.denodo.util.logging.JavaConsoleLogging" level="debug" />
    

    Kerberos デバッグメッセージは、 <DENODO_HOME>/logs/vdp/vdp.log にあります。

  6. Kerberos で認証されたユーザーに割り当てられているロールを取得するように、LDAP 構成を設定します。

    1. Database: 前のセクションで作成された LDAP データソースを格納した Virtual DataPort のデータベースを選択します。

    2. LDAP data source: データソースを選択します。

    3. User base: ユーザーを表すノードの検索スコープとして使用される Active Directory のノード。[User base] ボックスの横にある image1 ボタンをクリックすると、複数の「ユーザーベース」を入力することができます。複数の「ユーザーベース」が存在する場合、サーバーは最初の「ユーザーベース」スコープ内でユーザーのノードを検索します。ユーザーを表すノードが見つからなければ、2 番目の「ユーザーベース」スコープで検索します。それでも見つからなければ、3 番目のスコープを検索します (以降同様)。サーバーがユーザーを表すノードを見つけられなかった場合は、そのユーザーへのアクセスが拒否されます。

    4. Attribute with user name: ユーザーを表すノード内の、ユーザーのユーザー名を含む属性の名前。

      通常は「userPrincipalName」になります。

    5. User search pattern: サーバーに接続しようとしているユーザーを表すノードを取得するために実行される LDAP クエリの生成に使用されるパターン。

    6. Role base: LDAP サーバーのノード。このデータベースのユーザーが持つことのできるロールを表すノードを検索するためのスコープとして使用されます。[Role base] ボックスの横にある image1 ボタンをクリックすると、複数の「ロールベース」を入力することができます。「ロール検索」パターンで形成された LDAP クエリは、「ロールベース」スコープごとに実行されます。

    7. Attribute with role name: ロールを表すノード内の、ロールの名前を含む属性の名前。

    8. Role search pattern: ユーザーのロールを表すノードを取得するために実行される LDAP クエリの生成に使用されるパターン。このパターンには、トークン @{USERDN} または @{USERLOGIN} を含める必要があります (両方を含めることはできません)。

      • @{USERDN} は、このデータベースに接続しようとしているユーザーの識別名に置換されます (例: CN=john,CN=Users,DC=acme,DC=loc)。

      • @{USERLOGIN} は、このデータベースに接続しようとしているユーザーのログイン名に置換されます (例: john)。

    9. 正常にログインしたすべてのユーザーにロール「allusers」の権限を付与するには、[Assign "allusers" role for every connected user] を選択します。このロールが LDAP サーバーのユーザーに割り当てられていない場合も同様です。

      たとえば、特定のデータベースに対する読み取りアクセス権をすべてのユーザーに付与したい場合は、このオプションを選択し、この権限を「allusers」ロールに割り当てます。

      このオプションを選択しても、LDAP サーバー内のユーザーに付与されたロールが変更されることはありません。つまり、後からこのチェックボックスのチェックをはずすと、ログインしているユーザーは「allusers」ロールで付与される権限を持たなくなります。

    10. Active Directory 内で、[Attribute with user name] に入力した属性に、ドメイン名ではなくユーザーのユーザーアカウントのみが格納される場合、[Avoid domain name for authorization] を選択します。たとえば、属性に「mphilips@contoso.com」ではなく「mphilips」が格納される場合などです。

      Kerberos チケット内のログイン名にはドメイン名 (「mphilips@contoso.com」など) が含まれます。デフォルトでは、サーバーは Active Directory 内でこのユーザーのエントリを検索するときに、この名前を基準にしてフィルターします。[Attribute with user name] が「userPrincipalName」であり、この属性が「mphilips@contoso.com」ではなく「mphilips」というログイン名を持つ場合、このチェックボックスをチェックしないと認証に失敗します。

      このチェックボックスをチェックすると、サーバーは「userPrincipalName」が「mphilips」であるエントリを検索します。

    付録「 Active Directory または他の LDAP サーバーの問題のデバッグに役立つツール 」には、Active Directory および他の LDAP サーバー内のユーザーとそのロールの検索に関連する問題をデバッグするのに便利なツールの一覧が記載されています。

  7. [OK] をクリックして、Kerberos を有効にします。

    この変更を適用するために再起動する必要はありません。

この後、以下に対して Kerberos 認証を行えるようになります。

Denodo JDBC ドライバーと Administration Tool は接続を確立するときに、サーバーと認証のタイプ (ユーザー/パスワードまたは Kerberos) をネゴシエートします。デフォルトでは、サーバー内で Kerberos を有効にした後は、ユーザー/パスワード認証を継続して使用できるようになります。Kerberos を有効にする前に接続できた (Virtual DataPort でユーザーアカウントを作成したか、LDAP 認証でデータベースを設定した) 場合は、引き続きユーザーとパスワードで接続できます。

ODBC クライアントの場合は、 以下のセクション を参照してください。

ODBC クライアントへの Kerberos 認証の有効化

ODBC クライアントで Kerberos 認証を有効にするには、以下の手順に従います。

  1. [Administration] メニュー > [Database management] をクリックします。

  2. 1 つのデータベースを選択して、[Edit] をクリックします。

  3. [ODBC/ADDO.net authentication type] で [Kerberos] を選択します。

ODBC クライアントで Kerberos を使用するデータベースに対して、これを行う必要があります。

注釈

データベースで Kerberos 認証を有効にすると、ODBC クライアントはユーザー/パスワード認証を使用してこのデータベースに接続することができなくなります。したがって Kerberos を使用するには、既存の ODBC クライアントを再構成する必要があります。

JDBC クライアントと Administration Tool の場合と異なり、ODBC インターフェイスで使用される認証方法は、クライアントではなくサーバーによって設定されるからです。

Kerberos リプレイキャッシュを無効にする

リプレイキャッシュ (「rcache」) は、Denodo に接続するクライアントアプリケーションが最近提示したすべてのチケットを追跡します。このキャッシュは、リプレイキャッシュ内で重複する認証リクエストが検出された場合に、サーバーが接続を拒否してクライアントにエラーを返すために使用されます。このメカニズムにより、「リプレイ攻撃」が回避されます。

リプレイ攻撃に対して適切に防御されている場合や、リプレイ攻撃のリスクよりもパフォーマンスその他の考慮事項を重視しなければならないこともあります。そのような場合は、この保護を無効にすることをお勧めします。無効にするには、Virtual DataPort サーバーの Java 仮想マシン (JVM) の設定に、以下のシステムプロパティを追加します。

-Dsun.security.krb5.rcache=none

このプロパティを追加したら、Virtual DataPort を再起動して変更を有効にします。その後、クライアントは有効期間中にずっと同じ Kerberos チケットを使用できるようになります。

Control Center から JVM 設定を変更する方法については、「 こちらのセクション 」を参照してください。コマンドラインから JVM 設定を変更する方法については、「 別のセクション 」を参照してください。