このページは機械翻訳したものです。

6.4.1.7 LDAP プラガブル認証

注記

LDAP プラガブル認証は、商用製品である MySQL Enterprise Edition に含まれる拡張機能です。 商用製品の詳細は、https://www.mysql.com/products/ を参照してください。

MySQL Enterprise Edition は、MySQL Server が LDAP (Lightweight Directory Access Protocol) を使用して X.500 などのディレクトリサービスにアクセスすることで MySQL ユーザーを認証できるようにする認証方式をサポートしています。 MySQL は、LDAP を使用してユーザー、資格証明およびグループ情報をフェッチします。

LDAP プラガブル認証は、次の機能を提供します:

• 外部認証: LDAP 認証を使用すると、MySQL Server は LDAP ディレクトリ内の MySQL 付与テーブルの外部で定義されたユーザーからの接続を受け入れることができます。

• プロキシユーザーのサポート: LDAP 認証は、外部ユーザーがメンバーになっている LDAP グループに基づいて、クライアントプログラムによって渡される外部ユーザー名とは異なるユーザー名を MySQL に返すことができます。 つまり、LDAP プラグインは、外部 LDAP 認証ユーザーが持つべき権限を定義する MySQL ユーザーを返すことができます。 たとえば、joe の LDAP グループが developer の場合、joe という名前の LDAP ユーザーは developer という名前の MySQL ユーザーに接続して権限を持つことができます。

• セキュリティ: TLS を使用すると、LDAP サーバーへの接続をセキュリティー保護できます。

次のテーブルに、単純および SASL ベースの LDAP 認証用のプラグインおよびライブラリファイル名を示します。 ファイル名のサフィクスは、システムによって異なる場合があります。 ファイルは、plugin_dir システム変数で指定されたディレクトリに配置する必要があります。

表 6.18 簡易 LDAP 認証のプラグインおよびライブラリ名

プラグインまたはファイル	プラグインまたはファイル名
サーバー側のプラグイン名	authentication_ldap_simple
クライアント側のプラグイン名	mysql_clear_password
ライブラリファイル名	authentication_ldap_simple.so

表 6.19 SASL ベースの LDAP 認証用のプラグインおよびライブラリ名

プラグインまたはファイル	プラグインまたはファイル名
サーバー側のプラグイン名	authentication_ldap_sasl
クライアント側のプラグイン名	authentication_ldap_sasl_client
ライブラリファイル名	authentication_ldap_sasl.so, authentication_ldap_sasl_client.so

ライブラリファイルには、authentication_ldap_XXX 認証プラグインのみが含まれます。 クライアント側の mysql_clear_password プラグインは、libmysqlclient クライアントライブラリに組み込まれています。

各サーバー側 LDAP プラグインは、特定のクライアント側プラグインで動作します:

• サーバー側 authentication_ldap_simple プラグインは、単純な LDAP 認証を実行します。 このプラグインを使用するアカウントによる接続の場合、クライアントプログラムはクライアント側の mysql_clear_password プラグインを使用します。このプラグインは、パスワードをクリアテキストとしてサーバーに送信します。 パスワードのハッシュ化または暗号化は使用されないため、パスワードの公開を防ぐために、MySQL クライアントとサーバー間のセキュアな接続をお薦めします。

• サーバー側の authentication_ldap_sasl プラグインは、SASL ベースの LDAP 認証を実行します。 このプラグインを使用するアカウントによる接続の場合、クライアントプログラムはクライアント側の authentication_ldap_sasl_client プラグインを使用します。 クライアント側およびサーバー側 SASL LDAP プラグインは、SASL メッセージを使用して LDAP プロトコル内での資格証明のセキュアな転送を行い、MySQL クライアントとサーバー間でクリアテキストパスワードが送信されないようにします。

次の各セクションでは、LDAP プラガブル認証に固有のインストールおよび使用方法について説明します:

• LDAP プラガブル認証の前提条件

• MySQL ユーザーの LDAP 認証の仕組み

• LDAP プラガブル認証のインストール

• LDAP プラガブル認証のアンインストール

• LDAP プラガブル認証および ldap.conf

• LDAP プラガブル認証の使用

• 簡易 LDAP 認証

• SASL ベースの LDAP 認証

• プロキシを使用した LDAP 認証

• LDAP 認証グループプリファレンスとマッピングの指定

• LDAP 認証ユーザー DN 接尾辞

• LDAP 認証方式

• GSSAPI/Kerberos 認証方式

• LDAP 検索照会

MySQL のプラガブル認証に関する一般的な情報については、セクション6.2.17「プラガブル認証」を参照してください。 mysql_clear_password プラグインの詳細は、セクション6.4.1.4「クライアント側クリアテキストプラガブル認証」 を参照してください。 プロキシユーザーについては、セクション6.2.18「プロキシユーザー」を参照してください。

注記

システムが PAM をサポートし、PAM 認証方式として LDAP を許可する場合、MySQL ユーザー認証に LDAP を使用する別の方法は、サーバー側の authentication_pam プラグインを使用することです。 セクション6.4.1.5「PAM プラガブル認証」を参照してください。

LDAP プラガブル認証の前提条件

MySQL で LDAP プラガブル認証を使用するには、次の前提条件を満たす必要があります:

• LDAP 認証プラグインが通信するには、LDAP サーバーが使用可能である必要があります。

• MySQL によって認証される LDAP ユーザーは、LDAP サーバーによって管理されるディレクトリに存在する必要があります。

• LDAP クライアントライブラリは、サーバー側の authentication_ldap_sasl または authentication_ldap_simple プラグインが使用されているシステムで使用可能である必要があります。 現在サポートされているライブラリは、Windows ネイティブ LDAP ライブラリ、または Windows 以外のシステムの OpenLDAP ライブラリです。

• SASL ベースの LDAP 認証を使用するには:

  • LDAP サーバーは SASL サーバーと通信するように構成する必要があります。

  • SASL クライアントライブラリは、クライアント側の authentication_ldap_sasl_client プラグインが使用されているシステムで使用可能である必要があります。 現在サポートされているライブラリは Cyrus SASL ライブラリのみです。

  • 特定の SASL 認証方式を使用するには、その方式で必要なその他のサービスが使用可能である必要があります。 たとえば、GSSAPI/Kerberos を使用するには、GSSAPI ライブラリおよび Kerberos サービスが使用可能である必要があります。

MySQL ユーザーの LDAP 認証の仕組み

このセクションでは、MySQL と LDAP が連携して MySQL ユーザーを認証する方法の概要を示します。 特定の LDAP 認証プラグインを使用するように MySQL アカウントを設定する方法を示す例は、LDAP プラガブル認証の使用 を参照してください。 LDAP プラグインで使用可能な認証方式については、LDAP 認証方式 を参照してください。

クライアントは MySQL サーバーに接続し、MySQL クライアントユーザー名とパスワードを指定します:

• 単純な LDAP 認証の場合、クライアント側およびサーバー側のプラグインはパスワードをクリアテキストとして通信します。 パスワードの公開を防ぐために、MySQL クライアントとサーバー間のセキュアな接続をお薦めします。

• SASL ベースの LDAP 認証の場合、クライアント側とサーバー側のプラグインは、MySQL クライアントとサーバー間でクリアテキストのパスワードを送信しないようにします。 たとえば、プラグインは SASL メッセージを使用して、LDAP プロトコル内での資格証明のセキュアな転送を行うことができます。 GSSAPI 認証方式の場合、クライアント側およびサーバー側のプラグインは、LDAP メッセージを直接使用せずに Kerberos を使用してセキュアに通信します。

クライアントユーザー名とホスト名が MySQL アカウントと一致しない場合、接続は拒否されます。

一致する MySQL アカウントがある場合は、LDAP に対する認証が行われます。 LDAP サーバーは、ユーザーと一致するエントリを検索し、LDAP パスワードに対してエントリを認証します:

• MySQL アカウントが LDAP ユーザー識別名 (DN) を指定している場合、LDAP 認証はその値とクライアントによって提供された LDAP パスワードを使用します。 (LDAP ユーザー DN を MySQL アカウントに関連付けるには、アカウントを作成する CREATE USER ステートメントに認証文字列を指定する BY 句を含めます。)

• MySQL アカウントに LDAP ユーザー DN が指定されていない場合、LDAP 認証ではクライアントから提供されたユーザー名と LDAP パスワードが使用されます。 この場合、認証プラグインはまずルート DN とパスワードを資格証明として使用して LDAP サーバーにバインドし、クライアントユーザー名に基づいてユーザー DN を検索してから、LDAP パスワードに対してそのユーザー DN を認証します。 ルート DN およびパスワードが正しくない値に設定されているか、空 (設定されていない) で LDAP サーバーが匿名接続を許可していない場合、ルート資格証明を使用したこのバインドは失敗します。

LDAP サーバーが一致または複数の一致を検出しなかった場合、認証は失敗し、クライアント接続は拒否されます。

LDAP サーバーが単一の一致を検出した場合、LDAP 認証は成功し (パスワードが正しいと想定)、LDAP サーバーは LDAP エントリを返し、認証プラグインはそのエントリに基づいて認証されたユーザーの名前を決定します:

• LDAP エントリにグループ属性 (デフォルトでは cn 属性) がある場合、プラグインはその値を認証されたユーザー名として返します。

• LDAP エントリに group 属性がない場合、認証プラグインは、認証されたユーザー名としてクライアントユーザー名を返します。

MySQL サーバーは、クライアントユーザー名と認証済ユーザー名を比較して、クライアントセッションでプロキシが発生するかどうかを判断します:

• 名前が同じ場合、プロキシは発生しません: クライアントユーザー名と一致する MySQL アカウントが権限チェックに使用されます。

• 名前が異なる場合、プロキシが発生: MySQL は、認証されたユーザー名と一致するアカウントを検索します。 そのアカウントはプロキシユーザーになり、権限チェックに使用されます。 クライアントユーザー名に一致する MySQL アカウントは、外部プロキシユーザーとして扱われます。

LDAP プラガブル認証のインストール

このセクションでは、LDAP 認証プラグインをインストールする方法について説明します。 プラグインのインストールについての一般的な情報は、セクション5.6.1「プラグインのインストールおよびアンインストール」を参照してください。

サーバーで使用できるようにするには、プラグインライブラリファイルを MySQL プラグインディレクトリ (plugin_dir システム変数で指定されたディレクトリ) に配置する必要があります。 必要に応じて、サーバーの起動時に plugin_dir の値を設定してプラグインディレクトリの場所を構成します。

サーバー側のプラグインライブラリファイルのベース名は、authentication_ldap_simple および authentication_ldap_sasl です。 ファイル名の接尾辞は、プラットフォームごとに異なります (たとえば、.so for Unix and Unix-like systems, .dll for Windows)。

サーバーの起動時にプラグインをロードするには、--plugin-load-add オプションを使用して、プラグインを含むライブラリファイルに名前を付けます。 このプラグインのロード方法では、サーバーが起動するたびにオプションを指定する必要があります。 また、構成するプラグイン提供のシステム変数の値を指定します。

各サーバー側 LDAP プラグインは、その操作の構成を可能にする一連のシステム変数を公開します。 これらのほとんどはオプションですが、LDAP バインド操作の LDAP サーバーホストを指定する変数 (プラグインが接続先を認識できるようにするため)、およびベース識別名を設定する必要があります (検索の範囲を制限してより高速な検索を取得するため)。 すべての LDAP システム変数の詳細は、セクション6.4.1.11「プラガブル認証システム変数」 を参照してください。

プラグインをロードし、LDAP バインド操作の LDAP サーバーホストおよびベース識別名を設定するには、my.cnf ファイルに次のような行を入力し、必要に応じてプラットフォームの .so 接尾辞を調整します:

[mysqld]
plugin-load-add=authentication_ldap_simple.so
authentication_ldap_simple_server_host=127.0.0.1
authentication_ldap_simple_bind_base_dn="dc=example,dc=com"
plugin-load-add=authentication_ldap_sasl.so
authentication_ldap_sasl_server_host=127.0.0.1
authentication_ldap_sasl_bind_base_dn="dc=example,dc=com"

my.cnf を変更したら、新しい設定を有効にするためにサーバーを再起動します。

または、実行時にプラグインをロードするには、次のステートメントを使用して、プラットフォームの .so 接尾辞を必要に応じて調整します:

INSTALL PLUGIN authentication_ldap_simple
  SONAME 'authentication_ldap_simple.so';
INSTALL PLUGIN authentication_ldap_sasl
  SONAME 'authentication_ldap_sasl.so';

INSTALL PLUGIN はプラグインをただちにロードし、mysql.plugins システムテーブルにも登録して、--plugin-load-add を必要とせずに後続の通常の起動のたびにサーバーがプラグインをロードするようにします。

実行時にプラグインをインストールすると、そのシステム変数が使用可能になり、それらの設定を my.cnf ファイルに追加して、その後の再起動のためにプラグインを構成できます。 例:

[mysqld]
authentication_ldap_simple_server_host=127.0.0.1
authentication_ldap_simple_bind_base_dn="dc=example,dc=com"
authentication_ldap_sasl_server_host=127.0.0.1
authentication_ldap_sasl_bind_base_dn="dc=example,dc=com"

my.cnf を変更したら、新しい設定を有効にするためにサーバーを再起動します。

または、実行時に値を設定して永続化するには、次のステートメントを使用します:

SET PERSIST authentication_ldap_simple_server_host='127.0.0.1';
SET PERSIST authentication_ldap_simple_bind_base_dn='dc=example,dc=com';
SET PERSIST authentication_ldap_sasl_server_host='127.0.0.1';
SET PERSIST authentication_ldap_sasl_bind_base_dn='dc=example,dc=com';

SET PERSIST は、実行中の MySQL インスタンスの値を設定します。 また、値が保存され、その後のサーバーの再起動に引き継がれます。 後続の再起動に引き継ぐことなく、実行中の MySQL インスタンスの値を変更するには、PERSIST ではなく GLOBAL キーワードを使用します。 セクション13.7.6.1「変数代入の SET 構文」を参照してください。

プラグインのインストールを確認するには、INFORMATION_SCHEMA.PLUGINS テーブルを調べるか、SHOW PLUGINS ステートメントを使用します (セクション5.6.2「サーバープラグイン情報の取得」 を参照)。 例:

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE '%ldap%';
+----------------------------+---------------+
| PLUGIN_NAME                | PLUGIN_STATUS |
+----------------------------+---------------+
| authentication_ldap_sasl   | ACTIVE        |
| authentication_ldap_simple | ACTIVE        |
+----------------------------+---------------+

プラグインの初期化に失敗した場合は、サーバーエラーログで診断メッセージを確認してください。

MySQL アカウントを LDAP プラグインに関連付けるには、LDAP プラガブル認証の使用 を参照してください。

SELinux の追加ノート

SELinux が有効になっている EL6 または EL を実行しているシステムでは、MySQL LDAP プラグインが LDAP サービスと通信できるように SELinux ポリシーを変更する必要があります:

1. 次の内容のファイル mysqlldap.te を作成します:

   module mysqlldap 1.0;
   
   require {
           type ldap_port_t;
           type mysqld_t;
           class tcp_socket name_connect;
   }
   
   #============= mysqld_t ==============
   
   allow mysqld_t ldap_port_t:tcp_socket name_connect;

2. セキュリティポリシーモジュールをバイナリ表現にコンパイルします:

   checkmodule -M -m mysqlldap.te -o mysqlldap.mod

3. SELinux ポリシーモジュールパッケージを作成します:

   semodule_package -m mysqlldap.mod  -o mysqlldap.pp

4. モジュールパッケージをインストールします:

   semodule -i mysqlldap.pp

5. SELinux ポリシーが変更されたら、MySQL サーバーを再起動します:

   service mysqld restart

LDAP プラガブル認証のアンインストール

LDAP 認証プラグインのアンインストールに使用する方法は、インストール方法によって異なります:

• --plugin-load-add オプションを使用してサーバーの起動時にプラグインをインストールした場合は、それらのオプションを指定せずにサーバーを再起動します。

• INSTALL PLUGIN を使用して実行時にプラグインをインストールした場合、それらはサーバーの再起動後もインストールされたままです。 これらをアンインストールするには、UNINSTALL PLUGIN を使用します:

  UNINSTALL PLUGIN authentication_ldap_simple;
  UNINSTALL PLUGIN authentication_ldap_sasl;

また、LDAP プラグイン関連のシステム変数を設定する起動オプションを my.cnf ファイルから削除します。 SET PERSIST を使用して LDAP システム変数を永続化した場合は、RESET PERSIST を使用して設定を削除します。

LDAP プラガブル認証および ldap.conf

OpenLDAP を使用するインストールの場合、ldap.conf ファイルは LDAP クライアントのグローバルデフォルトを提供します。 このファイルでオプションを設定して、LDAP 認証プラグインを含む LDAP クライアントに影響を与えることができます。 OpenLDAP では、次の優先順位で構成オプションが使用されます:

• LDAP クライアントによって指定された構成。

• ldap.conf ファイルで指定された構成。 このファイルの使用を無効にするには、LDAPNOINIT 環境変数を設定します。

• OpenLDAP ライブラリの組込みデフォルト。

ライブラリのデフォルト値または ldap.conf 値で適切なオプション値が得られない場合は、LDAP 認証プラグインで関連する変数を設定して LDAP 構成に直接影響を与えることができます。 たとえば、LDAP プラグインは、次のようなパラメータの ldap.conf をオーバーライドできます:

• TLS 構成: TLS を有効にして CA 構成を制御するためにシステム変数を使用できます。単純な LDAP 認証の場合は authentication_ldap_simple_tls および authentication_ldap_simple_ca_path など、および、SASL LDAP 認証の場合は authentication_ldap_sasl_tls および authentication_ldap_sasl_ca_path などです。

• LDAP 参照。 LDAP 検索照会を参照してください。

ldap.conf の詳細は、ldap.conf(5) のマニュアルページを参照してください。

LDAP プラガブル認証の使用

このセクションでは、MySQL アカウントが LDAP プラガブル認証を使用して MySQL サーバーに接続できるようにする方法について説明します。 LDAP プラガブル認証のインストール で説明されているように、サーバーが適切なサーバー側プラグインを有効にして実行されており、適切なクライアント側プラグインがクライアントホストで使用可能であることを前提としています。

このセクションでは、LDAP の構成または管理については説明しません。 これらのトピックを理解していることを前提としています。

2 つのサーバー側 LDAP プラグインは、それぞれ特定のクライアント側プラグインで動作します:

• サーバー側 authentication_ldap_simple プラグインは、単純な LDAP 認証を実行します。 このプラグインを使用するアカウントによる接続の場合、クライアントプログラムはクライアント側の mysql_clear_password プラグインを使用します。このプラグインは、パスワードをクリアテキストとしてサーバーに送信します。 パスワードのハッシュ化または暗号化は使用されないため、パスワードの公開を防ぐために、MySQL クライアントとサーバー間のセキュアな接続をお薦めします。

• サーバー側の authentication_ldap_sasl プラグインは、SASL ベースの LDAP 認証を実行します。 このプラグインを使用するアカウントによる接続の場合、クライアントプログラムはクライアント側の authentication_ldap_sasl_client プラグインを使用します。 クライアント側およびサーバー側 SASL LDAP プラグインは、SASL メッセージを使用して LDAP プロトコル内での資格証明のセキュアな転送を行い、MySQL クライアントとサーバー間でクリアテキストパスワードが送信されないようにします。

MySQL ユーザーの LDAP 認証の全体的な要件:

• 認証されるユーザーごとに LDAP ディレクトリエントリが必要です。

• サーバー側の LDAP 認証プラグインを指定し、オプションで関連する LDAP ユーザー識別名 (DN) を指定する MySQL ユーザーアカウントが必要です。 (LDAP ユーザー DN を MySQL アカウントに関連付けるには、アカウントを作成する CREATE USER ステートメントに BY 句を含めます。) アカウント名に LDAP 文字列がない場合、LDAP 認証はクライアントによって指定されたユーザー名を使用して LDAP エントリを検索します。

• クライアントプログラムは、MySQL アカウントが使用するサーバー側認証プラグインに適した接続方法を使用して接続します。 LDAP 認証の場合、接続には MySQL ユーザー名と LDAP パスワードが必要です。 また、サーバー側の authentication_ldap_simple プラグインを使用するアカウントの場合は、--enable-cleartext-plugin オプションを指定してクライアントプログラムを呼び出し、クライアント側の mysql_clear_password プラグインを有効にします。

ここでの手順は、次のシナリオを前提としています:

• MySQL ユーザー betsy および boris は、それぞれ betsy_ldap および boris_ldap の LDAP エントリに対して認証を行います。 (MySQL と LDAP のユーザー名が異なる必要はありません。 この説明で異なる名前を使用すると、操作コンテキストが MySQL か LDAP かを明確にするのに役立ちます。)

• LDAP エントリは、uid 属性を使用してユーザー名を指定します。 これは LDAP サーバーによって異なる場合があります。 一部の LDAP サーバーでは、uid ではなく cn 属性をユーザー名に使用します。 属性を変更するには、authentication_ldap_simple_user_search_attr または authentication_ldap_sasl_user_search_attr システム変数を適切に変更します。

• これらの LDAP エントリは、各ユーザーを一意に識別する識別名値を提供するために、LDAP サーバーによって管理されるディレクトリで使用できます:

  uid=betsy_ldap,ou=People,dc=example,dc=com
  uid=boris_ldap,ou=People,dc=example,dc=com

• MySQL アカウントを作成する CREATE USER ステートメントは、MySQL アカウントの認証対象となる LDAP エントリを示すために、BY 句で LDAP ユーザーを指定します。

LDAP 認証を使用するアカウントを設定する手順は、使用するサーバー側 LDAP プラグインによって異なります。 次の各セクションでは、いくつかの使用シナリオについて説明します。

簡易 LDAP 認証

単純な LDAP 認証用に MySQL アカウントを構成するには、CREATE USER ステートメントで authentication_ldap_simple プラグインを指定し、オプションで LDAP ユーザー識別名 (DN) を指定します:

CREATE USER user
  IDENTIFIED WITH authentication_ldap_simple
  [BY 'LDAP user DN'];

MySQL ユーザー betsy の LDAP ディレクトリに次のエントリがあるとします:

uid=betsy_ldap,ou=People,dc=example,dc=com

その後、betsy の MySQL アカウントを作成するステートメントは次のようになります:

CREATE USER 'betsy'@'localhost'
  IDENTIFIED WITH authentication_ldap_simple
  AS 'uid=betsy_ldap,ou=People,dc=example,dc=com';

BY 句で指定された認証文字列に LDAP パスワードが含まれていません。 これは、接続時にクライアントユーザーが指定する必要があります。

クライアントは、MySQL ユーザー名と LDAP パスワードを指定し、クライアント側の mysql_clear_password プラグインを有効にすることによって、MySQL サーバーに接続します:

shell> mysql --user=betsy --password --enable-cleartext-plugin
Enter password: betsy_password (betsy_ldap LDAP password)

注記

クライアント側の mysql_clear_password 認証プラグインでは、パスワードはそのまま残されるため、クライアントプログラムはクリアテキストとして MySQL サーバーに送信します。 これにより、パスワードをそのまま LDAP サーバーに渡すことができます。 SASL なしでサーバー側 LDAP ライブラリを使用するにはクリアテキストパスワードが必要ですが、一部の構成でセキュリティの問題が発生する可能性があります。 これらのメジャーにより、リスクが最小限に抑えられます:

• mysql_clear_password プラグインを誤って使用する可能性を低くするには、MySQL クライアントで明示的に有効にする必要があります (たとえば、--enable-cleartext-plugin オプションを使用)。 セクション6.4.1.4「クライアント側クリアテキストプラガブル認証」を参照してください。

• mysql_clear_password プラグインを有効にしてパスワードの公開を回避するには、MySQL クライアントは暗号化された接続を使用して MySQL サーバーに接続する必要があります。 セクション6.3.1「暗号化接続を使用するための MySQL の構成」を参照してください。

認証プロセスは次のように実行されます:

1. クライアント側プラグインは、betsy および betsy_password をクライアントユーザー名および LDAP パスワードとして MySQL サーバーに送信します。

2. 接続試行は'betsy'@'localhost'アカウントと一致します。 サーバー側 LDAP プラグインは、このアカウントに、LDAP ユーザー DN を指定するための'uid=betsy_ldap,ou=People,dc=example,dc=com'の認証文字列があることを検出します。 プラグインは、この文字列と LDAP パスワードを LDAP サーバーに送信します。

3. LDAP サーバーは betsy_ldap の LDAP エントリを検出し、パスワードが一致するため、LDAP 認証は成功します。

4. LDAP エントリにはグループ属性がないため、サーバー側プラグインは認証されたユーザーとしてクライアントユーザー名 (betsy) を返します。 これはクライアントによって提供されるユーザー名と同じであるため、プロキシは発生せず、クライアントセッションは権限チェックに'betsy'@'localhost'アカウントを使用します。

一致する LDAP エントリにグループ属性が含まれている場合、その属性値は認証されたユーザー名になり、値が betsy と異なる場合はプロキシが発生します。 group 属性の使用例については、プロキシを使用した LDAP 認証 を参照してください。

betsy_ldap LDAP 識別名を指定する BY 句が CREATE USER ステートメントに含まれていない場合、認証の試行ではクライアントによって提供されたユーザー名 (この場合は betsy) が使用されます。 betsy の LDAP エントリがない場合、認証は失敗します。

SASL ベースの LDAP 認証

SASL LDAP 認証用に MySQL アカウントを構成するには、CREATE USER ステートメントで authentication_ldap_sasl プラグインを指定し、オプションで LDAP ユーザー識別名 (DN) を指定します:

CREATE USER user
  IDENTIFIED WITH authentication_ldap_sasl
  [BY 'LDAP user DN'];

MySQL ユーザー boris の LDAP ディレクトリに次のエントリがあるとします:

uid=boris_ldap,ou=People,dc=example,dc=com

その後、boris の MySQL アカウントを作成するステートメントは次のようになります:

CREATE USER 'boris'@'localhost'
  IDENTIFIED WITH authentication_ldap_sasl
  AS 'uid=boris_ldap,ou=People,dc=example,dc=com';

BY 句で指定された認証文字列に LDAP パスワードが含まれていません。 これは、接続時にクライアントユーザーが指定する必要があります。

クライアントは、MySQL ユーザー名と LDAP パスワードを指定して MySQL サーバーに接続します:

shell> mysql --user=boris --password
Enter password: boris_password (boris_ldap LDAP password)

サーバー側 authentication_ldap_sasl プラグインの場合、クライアントはクライアント側 authentication_ldap_sasl_client プラグインを使用します。 クライアントプログラムがクライアント側プラグインを見つけられない場合は、プラグインライブラリファイルがインストールされているディレクトリの名前を指定する --plugin-dir オプションを指定します。

boris の認証プロセスは、クライアント側とサーバー側の SASL LDAP プラグインが SASL メッセージを使用して LDAP プロトコル内の資格証明をセキュアに送信し、MySQL クライアントとサーバー間のクリアテキストパスワードの送信を回避する点を除き、単純な LDAP 認証を使用した betsy の場合と同様です。

プロキシを使用した LDAP 認証

LDAP 認証プラグインはプロキシをサポートしているため、ユーザーはあるユーザーとして MySQL サーバーに接続できますが、別のユーザーの権限を引き受けます。 このセクションでは、LDAP プラグインの基本的なプロキシサポートについて説明します。 LDAP プラグインは、グループプリファレンスおよびプロキシユーザーマッピングの指定もサポートしています。LDAP 認証グループプリファレンスとマッピングの指定 を参照してください。

ここで説明するプロキシ実装は、LDAP を使用して認証する MySQL ユーザーを、様々な権限セットを定義する他の MySQL アカウントにマップするための LDAP グループ属性値の使用に基づいています。 ユーザーは、権限を定義するアカウントを使用して直接接続しません。 かわりに、すべての外部ログインが権限を保持するプロキシ MySQL アカウントにマップされるように、LDAP で認証されたデフォルトのプロキシアカウントを介して接続します。 プロキシアカウントを使用して接続するユーザーは、プロキシ設定された MySQL アカウントのいずれか (外部ユーザーに許可されるデータベース操作を決定する権限) にマップされます。

ここでの手順は、次のシナリオを前提としています:

• LDAP エントリは、uid 属性と cn 属性を使用して、それぞれユーザー名とグループ値を指定します。 異なるユーザーおよびグループ属性名を使用するには、適切なプラグイン固有のシステム変数を設定します:

  • authentication_ldap_simple プラグインの場合: authentication_ldap_simple_user_search_attr および authentication_ldap_simple_group_search_attr を設定します。

  • authentication_ldap_sasl プラグインの場合: authentication_ldap_sasl_user_search_attr および authentication_ldap_sasl_group_search_attr を設定します。

• これらの LDAP エントリは、各ユーザーを一意に識別する識別名値を提供するために、LDAP サーバーによって管理されるディレクトリで使用できます:

  uid=basha,ou=People,dc=example,dc=com,cn=accounting
  uid=basil,ou=People,dc=example,dc=com,cn=front_office

  接続時に、グループ属性値は認証されたユーザー名になるため、accounting および front_office プロキシアカウントに名前が付けられます。

• この例では、SASL LDAP 認証を使用することを前提としています。 単純な LDAP 認証に対して適切な調整を行います。

デフォルトのプロキシ MySQL アカウントを作成します:

CREATE USER ''@'%'
  IDENTIFIED WITH authentication_ldap_sasl;

プロキシアカウント定義には、LDAP ユーザー DN を指定する AS 'auth_string'句がありません。 したがって、次のようになります:

• クライアントが接続すると、クライアントユーザー名が検索対象の LDAP ユーザー名になります。

• 一致する LDAP エントリには、クライアントが保持する必要がある権限を定義するプロキシ設定された MySQL アカウントを指定するグループ属性が含まれている必要があります。

注記

MySQL インストールに匿名ユーザーが含まれている場合、デフォルトのプロキシユーザーと競合する可能性があります。 この問題とその対処方法の詳細は、デフォルトのプロキシユーザーと匿名ユーザーの競合 を参照してください。

プロキシ設定されたアカウントを作成し、各アカウントに次の権限を付与します:

CREATE USER 'accounting'@'localhost'
  IDENTIFIED WITH mysql_no_login;
CREATE USER 'front_office'@'localhost'
  IDENTIFIED WITH mysql_no_login;

GRANT ALL PRIVILEGES
  ON accountingdb.*
  TO 'accounting'@'localhost';
GRANT ALL PRIVILEGES
  ON frontdb.*
  TO 'front_office'@'localhost';

プロキシ設定されたアカウントは、mysql_no_login 認証プラグインを使用して、クライアントがアカウントを使用して MySQL サーバーに直接ログインできないようにします。 かわりに、LDAP を使用して認証するユーザーは、デフォルトの''@'%'プロキシアカウントを使用する必要があります。 (これは、mysql_no_login プラグインがインストールされていることを前提としています。 手順については、セクション6.4.1.8「ログインなしのプラガブル認証」 を参照してください。) プロキシ設定されたアカウントを直接使用しないように保護する別の方法については、プロキシアカウントへの直接ログインの防止 を参照してください。

プロキシされた各アカウントの PROXY 権限をプロキシアカウントに付与します:

GRANT PROXY
  ON 'accounting'@'localhost'
  TO ''@'%';
GRANT PROXY
  ON 'front_office'@'localhost'
  TO ''@'%';

mysql コマンドラインクライアントを使用して、basha として MySQL サーバーに接続します。

shell> mysql --user=basha --password
Enter password: basha_password (basha LDAP password)

認証は次のように行われます:

1. サーバーは、クライアントユーザー basha のデフォルトの''@'%'プロキシアカウントを使用して接続を認証します。

2. 一致する LDAP エントリは次のとおりです:

   uid=basha,ou=People,dc=example,dc=com,cn=accounting

3. 一致する LDAP エントリにはグループ属性 cn=accounting があるため、accounting が認証済プロキシユーザーになります。

4. 認証されたユーザーはクライアントユーザー名 basha とは異なりますが、その結果、basha は accounting のプロキシとして扱われ、basha はプロキシされた accounting アカウントの権限を引き継ぎます。 次のクエリーは、次に示すような出力を返します:

   mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
   +-----------------+----------------------+--------------+
   | USER()          | CURRENT_USER()       | @@proxy_user |
   +-----------------+----------------------+--------------+
   | basha@localhost | accounting@localhost | ''@'%'       |
   +-----------------+----------------------+--------------+

これは、basha がプロキシ設定された accounting MySQL アカウントに付与された権限を使用し、プロキシ設定がデフォルトのプロキシユーザーアカウントを介して行われることを示しています。

かわりに、basil として接続します:

shell> mysql --user=basil --password
Enter password: basil_password (basil LDAP password)

basil の認証プロセスは、前述の basha の認証プロセスと似ています:

1. サーバーは、クライアントユーザー basil のデフォルトの''@'%'プロキシアカウントを使用して接続を認証します。

2. 一致する LDAP エントリは次のとおりです:

   uid=basil,ou=People,dc=example,dc=com,cn=front_office

3. 一致する LDAP エントリにはグループ属性 cn=front_office があるため、front_office が認証済プロキシユーザーになります。

4. 認証されたユーザーはクライアントユーザー名 basil とは異なりますが、その結果、basil は front_office のプロキシとして扱われ、basil はプロキシされた front_office アカウントの権限を引き継ぎます。 次のクエリーは、次に示すような出力を返します:

   mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
   +-----------------+------------------------+--------------+
   | USER()          | CURRENT_USER()         | @@proxy_user |
   +-----------------+------------------------+--------------+
   | basil@localhost | front_office@localhost | ''@'%'       |
   +-----------------+------------------------+--------------+

これは、basil がプロキシ設定された front_office MySQL アカウントに付与された権限を使用し、プロキシ設定がデフォルトのプロキシユーザーアカウントを介して行われることを示しています。

LDAP 認証グループプリファレンスとマッピングの指定

プロキシを使用した LDAP 認証 で説明されているように、基本的な LDAP 認証プロキシは、LDAP サーバーから返された最初のグループ名を MySQL プロキシユーザーアカウント名としてプラグインが使用する原則によって機能します。 この単純な機能では、LDAP サーバーが複数のグループ名を返す場合、またはプロキシユーザー名としてグループ名以外の名前を指定する場合、使用するグループ名に関するプリファレンスを指定できません。

MySQL 8.0.14 では、LDAP 認証を使用する MySQL アカウントの場合、認証文字列で次の情報を指定して、プロキシの柔軟性を高めることができます:

• プラグインが LDAP サーバーから返されたグループと一致するリスト内の最初のグループ名を使用するように、優先順位の高いグループのリスト。

• グループ名からプロキシ設定されたユーザー名へのマッピング。これにより、一致したグループ名は、プロキシ設定されたユーザーとして使用するために指定された名前を提供できます。 これにより、プロキシユーザーとしてグループ名を使用するかわりに使用できます。

次の MySQL プロキシアカウント定義について考えてみます:

CREATE USER ''@'%'
  IDENTIFIED WITH authentication_ldap_sasl
  AS '+ou=People,dc=example,dc=com#grp1=usera,grp2,grp3=userc';

認証文字列には、+ 文字が接頭辞として付いたユーザー DN 接尾辞 ou=People,dc=example,dc=com があります。 したがって、LDAP 認証ユーザー DN 接尾辞 で説明されているように、完全なユーザー DN は、指定されたユーザー DN 接尾辞と、uid 属性としてのクライアントユーザー名から構成されます。

認証文字列の残りの部分は、グループプリファレンスおよびマッピング情報の開始を示す#で始まります。 認証文字列のこの部分には、グループ名が grp1, grp2, grp3 の順序でリストされます。 LDAP プラグインは、そのリストを LDAP サーバーから返されたグループ名のセットと比較し、リストの順序で返された名前との一致を探します。 プラグインは最初の一致を使用します。一致するものがない場合、認証は失敗します。

LDAP サーバーがグループ grp3、grp2 および grp7 を返すとします。 LDAP プラグインは、LDAP サーバーによって返される最初のグループではなくても、一致する認証文字列の最初のグループであるため、grp2 を使用します。 LDAP サーバーが grp4、grp2 および grp1 を返す場合、grp2 も一致していても、プラグインは grp1 を使用します。grp1 は、認証文字列の前半にリストされているため、grp2 よりも優先されます。

プラグインは、一致するグループ名を検出すると、そのグループ名から MySQL プロキシユーザー名へのマッピングを実行します (存在する場合)。 プロキシアカウントの例では、マッピングは次のように行われます:

• 一致するグループ名が grp1 または grp3 の場合、それらは認証文字列内でユーザー名 usera および userc にそれぞれ関連付けられます。 プラグインは、対応する関連ユーザー名をプロキシユーザー名として使用します。

• 一致するグループ名が grp2 の場合、認証文字列に関連付けられたユーザー名はありません。 プラグインは、プロキシユーザー名として grp2 を使用します。

LDAP サーバーが DN 形式でグループを返す場合、LDAP プラグインはグループ DN を解析してグループ名を抽出します。

LDAP グループプリファレンスおよびマッピング情報を指定するには、次の原則が適用されます:

• グループプリファレンスおよび認証文字列のマッピング部分を#接頭辞文字で開始します。

• グループプリファレンスとマッピングの指定は、カンマで区切られた 1 つ以上のアイテムのリストです。 各アイテムの形式は、group_name=user_name または group_name です。 アイテムは、グループ名のプリファレンス順にリストする必要があります。 LDAP サーバーによって返されるグループ名のセットと一致するものとしてプラグインによって選択されたグループ名の場合、次の 2 つの構文が有効に異なります:

  • group_name=user_name (ユーザー名付き) として指定されたアイテムの場合、グループ名は MySQL プロキシユーザー名として使用されるユーザー名にマップされます。

  • group_name (ユーザー名なし) として指定されたアイテムの場合、グループ名は MySQL プロキシユーザー名として使用されます。

• スペースなどの特殊文字を含むグループまたはユーザー名を引用符で囲むには、二重引用符 (") 文字で囲みます。 たとえば、アイテムのグループ名とユーザー名が my group name および my user name の場合は、引用符を使用してグループマッピングに記述する必要があります:

  "my group name"="my user name"

  アイテムに my_group_name および my_user_name のグループ名およびユーザー名 (特殊文字を含まない) がある場合、引用符を使用して記述する必要はありません。 次のいずれかが有効です:

  my_group_name=my_user_name
  my_group_name="my_user_name"
  "my_group_name"=my_user_name
  "my_group_name"="my_user_name"

• 文字をエスケープするには、その前にバックスラッシュ (\) を付けます。 これは、リテラルの二重引用符またはバックスラッシュを含める場合に特に便利です。それ以外の場合は、リテラルの二重引用符またはバックスラッシュは含まれません。

• ユーザー DN は認証文字列に存在する必要はありませんが、存在する場合は、グループプリファレンスおよびマッピング部分の前に存在する必要があります。 ユーザー DN は、完全なユーザー DN または + 接頭辞文字を含むユーザー DN 接尾辞として指定できます。 (LDAP 認証ユーザー DN 接尾辞を参照してください。)

LDAP 認証ユーザー DN 接尾辞

LDAP 認証プラグインでは、ユーザー DN 情報を提供する認証文字列を + 接頭辞文字で始めることができます:

• + 文字がない場合、認証文字列値は変更されずにそのまま処理されます。

• 認証文字列が + で始まる場合、プラグインは、(+ を削除して) 認証文字列で指定された DN とともに、クライアントによって送信されたユーザー名から完全なユーザー DN 値を構成します。 構築された DN では、クライアントユーザー名は LDAP ユーザー名を指定する属性の値になります。 これはデフォルトでは uid です。属性を変更するには、適切なシステム変数 (authentication_ldap_simple_user_search_attr または authentication_ldap_sasl_user_search_attr) を変更します。 認証文字列は、mysql.user システムテーブルに指定されているとおりに格納され、完全なユーザー DN は認証前に即時に構成されます。

このアカウント認証文字列の先頭には + がないため、完全なユーザー DN とみなされます:

CREATE USER 'baldwin'
  IDENTIFIED WITH authentication_ldap_simple
  AS 'uid=admin,ou=People,dc=example,dc=com';

クライアントは、アカウント (baldwin) で指定されたユーザー名で接続します。 この場合、認証文字列に接頭辞がなく、ユーザー DN を完全に指定するため、その名前は使用されません。

このアカウント認証文字列の先頭には + があるため、ユーザー DN の一部として取得されます:

CREATE USER 'accounting'
  IDENTIFIED WITH authentication_ldap_simple
  AS '+ou=People,dc=example,dc=com';

クライアントは、アカウント (accounting) で指定されたユーザー名で接続します。この場合、ユーザー DN を構成するための認証文字列とともに uid 属性として使用されます: uid=accounting,ou=People,dc=example,dc=com

前述の例のアカウントには空でないユーザー名が含まれているため、クライアントは常にアカウント定義で指定されたのと同じ名前を使用して MySQL サーバーに接続します。 プロキシを使用した LDAP 認証 で説明されているデフォルトの匿名''@'%'プロキシアカウントなど、アカウントのユーザー名が空の場合、クライアントは様々なユーザー名で MySQL サーバーに接続することがあります。 ただし、原則は同じです: 認証文字列が + で始まる場合、プラグインはクライアントから送信されたユーザー名と認証文字列を使用してユーザー DN を構築します。

LDAP 認証方式

LDAP 認証プラグインは、構成可能な認証方式を使用します。 適切なシステム変数および使用可能なメソッドの選択肢は、プラグイン固有です:

• authentication_ldap_simple プラグインの場合: メソッドを構成するには、authentication_ldap_simple_auth_method_name システム変数を設定します。 許可される選択肢は、SIMPLE および AD-FOREST です。

• authentication_ldap_sasl プラグインの場合: メソッドを構成するには、authentication_ldap_sasl_auth_method_name システム変数を設定します。 許可される選択肢は、SCRAM-SHA-1、SCRAM-SHA-256 および GSSAPI です。 (ホストシステムで実際に使用可能な SASL LDAP メソッドを判別するには、Authentication_ldap_sasl_supported_methods ステータス変数の値を確認します。)

許可される各メソッドの詳細は、システム変数の説明を参照してください。 また、方法によっては、次の各セクションで説明するように、追加の構成が必要になる場合があります。

GSSAPI/Kerberos 認証方式

Generic Security Service Application Program Interface (GSSAPI) は、セキュリティ抽象化インタフェースです。 Kerberos は、その抽象インタフェースを介して使用できる特定のセキュリティプロトコルのインスタンスです。 GSSAPI を使用すると、アプリケーションは Kerberos に対して認証を行い、サービス資格を取得してから、それらの資格を使用してほかのサービスへのセキュアなアクセスを有効にします。

そのようなサービスの 1 つは LDAP で、クライアント側とサーバー側の SASL LDAP 認証プラグインによって使用されます。 authentication_ldap_sasl_auth_method_name システム変数が GSSAPI に設定されている場合、これらのプラグインは GSSAPI/Kerberos 認証方式を使用します。 この場合、プラグインは LDAP メッセージを直接使用せずに Kerberos を使用して安全に通信します。 次に、サーバー側プラグインは LDAP サーバーと通信して、LDAP 認証メッセージを解釈し、LDAP グループを取得します。

GSSAPI/Kerberos は、Linux 上の MySQL クライアントおよびサーバーの認証方式としてのみサポートされます。 これは、Kerberos がデフォルトで有効になっている Microsoft Active Directory を使用してアプリケーションが LDAP にアクセスする Linux 環境で役立ちます。

次の説明では、GSSAPI メソッドを使用するための構成要件について説明します。 次の一般的な Kerberos 用語など、Kerberos の概念および操作に精通していることを前提としています:

• プリンシパル = ユーザーやサービスなどの名前付きエンティティ。

• KDC = AS および TGS で構成されるキー配布センター。

• AS = KDC の一部である認証サーバー。 TGT の取得に必要な初期チケットを提供します。

• TGS = KDC の一部であるチケット認可サービス。

• TGT = チケット認可チケット。TGS に提示され、サービスアクセス用のサービスチケットを取得します。

Kerberos 認証には KDC サーバーと LDAP サーバーの両方が必要です。 この要件は、様々な方法で満たすことができます:

• Active Directory には両方のサーバーが含まれており、Kerberos 認証は Active Directory LDAP サーバーでデフォルトで有効になっています。

• OpenLDAP には LDAP サーバーが用意されていますが、別の KDC サーバーが必要になる場合があり、追加の Kerberos 設定が必要です。

Kerberos はクライアントホストでも使用可能である必要があります。 クライアントは、TGT を取得するためにパスワードを使用して AS に接続します。 その後、クライアントは TGT を使用して TGS から LDAP などの他のサービスへのアクセスを取得します。

次のセクションでは、MySQL で SASL LDAP 認証に GSSAPI/Kerberos を使用するための構成ステップについて説明します:

• Kerberos 設定の確認

• GSSAPI/Kerberos 用のサーバー側 SASL LDAP 認証プラグインの構成

• GSSAPI/Kerberos を使用する MySQL アカウントの作成

• MySQL アカウントを使用した MySQL Server への接続

• /etc/krb5.conf クライアント構成パラメータ

Kerberos 設定の確認

次の例は、Active Directory で Kerberos の可用性をテストする方法を示しています。 この例では、次のことを想定しています:

• Active Directory は、IP アドレス 198.51.100.10 の ldap_auth.example.com という名前のホストで実行されています。

• MYSQL.LOCAL ドメインは、MySQL-related Kerberos 認証および LDAP 検索に使用されます。

• [e-mail] という名前の主体が KDC に登録されます。 (後で説明しますが、このプリンシパル名は GSSAPI/Kerberos を使用して MySQL サーバーに対する認証を行う MySQL ユーザーにも使用されます。)

これらの前提条件を満たしている場合は、次の手順に従います:

1. Kerberos ライブラリがオペレーティングシステムに正しくインストールおよび構成されていることを確認します。 たとえば、MySQL 認証中に使用する MYSQL.LOCAL ドメインを構成するには、Kerberos 構成ファイル/etc/krb5.conf に次のような内容を含める必要があります:

   [realms]
     MYSQL.LOCAL = {
       kdc = ldap_auth.example.com
       admin_server = ldap_auth.example.com
       default_domain = MYSQL.LOCAL
     }

2. サーバーホストの/etc/hosts にエントリを追加する必要がある場合があります:

   198.51.100.10 ldap_auth ldap_auth.example.com

3. Kerberos 認証が正しく機能するかどうかを確認します:

   1. kinit を使用して、Kerberos に対する認証を行います:

      kinit [e-mail]

      このコマンドは、[e-mail] という名前の Kerberos 主体の認証を行います。 入力を求めるプロンプトが表示されたら、プリンシパルパスワードを入力します。 KDC は、ほかの Kerberos-aware アプリケーションで使用するためにクライアント側にキャッシュされた TGT を返します。

   2. klist を使用して TGT が正しく取得されたかどうかを確認します。 出力は次のようになります:

      Ticket cache: FILE:/tmp/krb5cc_244306
      Default principal: [e-mail]
      
      Valid starting       Expires              Service principal
      03/23/2020 08:18:33  03/23/2020 18:18:33  krbtgt/[e-mail]

4. MYSQL.LOCAL ドメイン内のユーザーを検索する次のコマンドを使用して、ldapsearch が Kerberos TGT と連携するかどうかを確認します:

   ldapsearch -h 198.51.100.10 -Y GSSAPI -b "dc=MYSQL,dc=LOCAL"

GSSAPI/Kerberos 用のサーバー側 SASL LDAP 認証プラグインの構成

前述のように、LDAP サーバーが Kerberos を介してアクセス可能であると仮定して、GSSAPI/Kerberos 認証方式を使用するようにサーバー側 SASL LDAP 認証プラグインを構成します。 (LDAP プラグインの一般的なインストール情報については、LDAP プラガブル認証のインストール を参照してください。) 次に、サーバー my.cnf ファイルに含まれるプラグイン関連の設定の例を示します:

[mysqld]
plugin-load-add=authentication_ldap_sasl.so
authentication_ldap_sasl_auth_method_name="GSSAPI"
authentication_ldap_sasl_server_host=198.51.100.10
authentication_ldap_sasl_server_port=389
authentication_ldap_sasl_bind_root_dn="cn=admin,cn=users,dc=MYSQL,dc=LOCAL"
authentication_ldap_sasl_bind_root_pwd="password"
authentication_ldap_sasl_bind_base_dn="cn=users,dc=MYSQL,dc=LOCAL"
authentication_ldap_sasl_user_search_attr="sAMAccountName"

これらのオプションファイルの設定では、SASL LDAP プラグインを次のように構成します:

• --plugin-load-add オプションはプラグインをロードします (必要に応じて、プラットフォームの .so 接尾辞を調整します)。 以前に INSTALL PLUGIN ステートメントを使用してプラグインをロードした場合、このオプションは不要です。

• GSSAPI/Kerberos を SASL LDAP 認証方式として使用するには、authentication_ldap_sasl_auth_method_name を GSSAPI に設定する必要があります。

• authentication_ldap_sasl_server_host および authentication_ldap_sasl_server_port は、認証用の Active Directory サーバーホストの IP アドレスとポート番号を示します。

• authentication_ldap_sasl_bind_root_dn および authentication_ldap_sasl_bind_root_pwd は、グループ検索機能のルート DN およびパスワードを構成します。 この機能は必須ですが、ユーザーには検索権限がない可能性があります。 このような場合は、ルート DN 情報を指定する必要があります:

  • DN オプション値では、admin はユーザー検索を実行する権限を持つ管理 LDAP アカウントの名前である必要があります。

  • パスワードオプションの値で、password は admin アカウントのパスワードである必要があります。

• authentication_ldap_sasl_bind_base_dn は、MYSQL.LOCAL ドメイン内のユーザーを検索するためのユーザー DN ベースパスを示します。

• authentication_ldap_sasl_user_search_attr では、標準の Active Directory 検索属性 sAMAccountName が指定されています。 この属性は、ログオン名を照合するために検索で使用されます。属性値はユーザー DN 値と同じではありません。

GSSAPI/Kerberos を使用する MySQL アカウントの作成

GSSAPI/Kerberos メソッドで SASL LDAP 認証プラグインを使用した MySQL 認証は、Kerberos 主体であるユーザーに基づいています。 次の説明では、このユーザーとして [e-mail] という名前のプリンシパルを使用します。これは複数の場所に登録する必要があります:

• Kerberos 管理者は、ユーザー名を Kerberos プリンシパルとして登録する必要があります。 この名前にはドメイン名を含める必要があります。 プリンシパル名とパスワードは、クライアントが Kerberos で認証し、TGT を取得するために使用されます。

• LDAP 管理者は、LDAP エントリにユーザー名を登録する必要があります。 例:

  uid=bredon,dc=MYSQL,dc=LOCAL

  注記

  Active Directory (デフォルトの認証方法として Kerberos を使用) では、ユーザーを作成すると、Kerberos プリンシパルと LDAP エントリの両方が作成されます。

• MySQL DBA は、ユーザー名として Kerberos プリンシパル名を持ち、SASL LDAP プラグインを使用して認証するアカウントを作成する必要があります。

Kerberos 主体と LDAP エントリが適切なサービス管理者によって登録されており、前述の my.cnf 設定を使用して MySQL サーバーが起動されていると仮定して、ドメイン名を含む Kerberos 主体名に対応する MySQL アカウントを作成します。

注記

SASL LDAP プラグインは、Kerberos 認証に一定のユーザー DN を使用し、MySQL から構成されたユーザー DN を無視します。 これには、次のような影響があります:

• GSSAPI/Kerberos 認証を使用する MySQL アカウントの場合、CREATE USER ステートメントまたは ALTER USER ステートメントの認証文字列にはユーザー DN が含まれていない必要があります。これは効果がないためです。

• 認証文字列にはユーザー DN が含まれていないため、必要なプロキシユーザーにマップされたプロキシユーザーとしてユーザーを処理できるように、グループマッピング情報を含める必要があります。 LDAP 認証プラグインによるプロキシの詳細は、プロキシを使用した LDAP 認証 を参照してください。

次のステートメントは、proxied_krb_usr という名前のプロキシユーザーの権限を引き受ける [e-mail] という名前のプロキシユーザーを作成します。 同じ特権を持つほかの GSSAPI/Kerberos ユーザーも、同じプロキシユーザーのプロキシユーザーとして同様に作成できます。

-- create proxy account
CREATE USER '[e-mail]'
  IDENTIFIED WITH authentication_ldap_sasl
  BY '#krb_grp=proxied_krb_user';

-- create proxied account and grant its privileges;
-- use mysql_no_login plugin to prevent direct login
CREATE USER 'proxied_krb_user'
  IDENTIFIED WITH mysql_no_login;
GRANT ALL
  ON krb_user_db.*
  TO 'proxied_krb_user';

-- grant to proxy account the
-- PROXY privilege for proxied account
GRANT PROXY
  ON 'proxied_krb_user'
  TO '[e-mail]';

最初の CREATE USER ステートメントと GRANT PROXY ステートメントでプロキシアカウント名の引用符をよく確認します:

• ほとんどの MySQL アカウントでは、ユーザーとホストはアカウント名の別々の部分であるため、'user_name'@'host_name'とは別に引用符で囲まれます。

• Kerberos 認証の場合、アカウント名のユーザー部分にはプリンシパルドメインが含まれるため、'[e-mail]'は単一の値として引用符で囲まれます。 ホスト部分が指定されていないため、完全な MySQL アカウント名ではデフォルトの'%'がホスト部分として使用されます: '[e-mail]'@'%'

プロキシ設定されたアカウントは、mysql_no_login 認証プラグインを使用して、クライアントがアカウントを使用して MySQL サーバーに直接ログインできないようにします。 かわりに、LDAP を使用して認証するユーザーは [e-mail] プロキシアカウントを使用する必要があります。 (これは、mysql_no_login プラグインがインストールされていることを前提としています。 手順については、セクション6.4.1.8「ログインなしのプラガブル認証」 を参照してください。) プロキシ設定されたアカウントを直接使用しないように保護する別の方法については、プロキシアカウントへの直接ログインの防止 を参照してください。

MySQL アカウントを使用した MySQL Server への接続

GSSAPI/Kerberos を使用する MySQL アカウントが設定されると、クライアントは Kerberos に対して認証を行い、そのアカウントを使用して MySQL サーバーに接続できます。 Kerberos 認証は、MySQL クライアントプログラムの起動前または起動時に実行できます:

• クライアントユーザーは、MySQL クライアントプログラムを起動する前に、MySQL とは別に TGT を取得できます。 たとえば、クライアントユーザーは、Kerberos プリンシパル名とプリンシパルパスワードを指定して、kinit を使用して Kerberos への認証を行うことができます。 TGT はキャッシュされ、クライアント側 SASL LDAP 認証プラグインなどの他の Kerberos-aware アプリケーションで使用できるようになります。 この場合、MySQL クライアントプログラムは TGT を使用して MySQL サーバーに対する認証を行うため、ユーザー名またはパスワードを指定せずにクライアントを呼び出します:

  shell> kinit [e-mail]
  Password for [e-mail]: (enter password here)
  shell> mysql --default-auth=authentication_ldap_sasl_client

  MySQL クライアントコマンドに資格証明が含まれている場合は、次のように処理されます:

  • コマンドにユーザー名が含まれている場合、TGT 内のプリンシパル名と一致しないと認証は失敗します。

  • コマンドにパスワードが含まれている場合、パスワードは無視されます。 認証は TGT に基づいているため、ユーザーが指定したパスワードが正しくない場合でもを成功させることができます。 このため、パスワードが無視される原因となる有効な TGT が見つかった場合、プラグインは警告を生成します。

• TGT が存在しない場合、クライアント側 SASL LDAP 認証プラグイン自体が KDC から TGT を取得できます。 この場合、クライアントを起動するには、MySQL アカウントに関連付けられた Kerberos プリンシパルの名前とパスワードを指定します (コマンドを単一行で入力し、プロンプトでプリンシパルパスワードを入力します):

  shell> mysql --default-auth=authentication_ldap_sasl_client
           --user=[e-mail]
           --password
  Enter password: (enter password here)

• client コマンドで主体名がユーザー名として指定されておらず、TGT が存在しないためにクライアント側プラグインが Kerberos キャッシュを空にした場合、認証は失敗します。

TGT が存在するかどうかが不明な場合は、klist を使用して確認できます。

認証は次のように行われます:

1. クライアントは TGT を使用して Kerberos を使用して認証します。

2. サーバーはプリンシパルの LDAP エントリを検索し、それを使用して [e-mail] MySQL プロキシアカウントの接続を認証します。

3. プロキシアカウント認証文字列 ('#krb_grp=proxied_krb_user') のグループマッピング情報は、認証されたプロキシユーザーが proxied_krb_user である必要があることを示します。

4. [e-mail] は proxied_krb_user のプロキシとして扱われ、次のクエリーは次のような出力を返します:

   mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
   +------------------------------+--------------------+--------------------------+
   | USER()                       | CURRENT_USER()     | @@proxy_user             |
   +------------------------------+--------------------+--------------------------+
   | [e-mail]@localhost | proxied_krb_user@% | '[e-mail]'@'%' |
   +------------------------------+--------------------+--------------------------+

   USER() 値は、クライアントコマンド ([e-mail]) およびクライアントの接続元ホスト (localhost) に使用されるユーザー名を示します。

   CURRENT_USER() 値は、プロキシ設定されたユーザーアカウントのフルネームで、proxied_krb_user ユーザー部分と % ホスト部分で構成されます。

   @@proxy_user 値は、MySQL サーバーへの接続に使用されるアカウントのフルネームを示します。これは、[e-mail] ユーザー部分と % ホスト部分で構成されます。

   これは、プロキシが [e-mail] プロキシユーザーアカウントを介して発生し、[e-mail] が proxied_krb_user プロキシユーザーアカウントに付与された権限を引き受けることを示しています。

取得された TGT はクライアント側にキャッシュされ、パスワードを再度指定せずに期限切れになるまで使用できます。 ただし、TGT が取得されると、クライアント側プラグインはそれを使用してサービスチケットを取得し、サーバー側プラグインと通信します。

クライアント側プラグイン自体が TGT を取得する場合、クライアントユーザーは TGT を再利用しないようにすることができます。 /etc/krb5.conf クライアント構成パラメータ で説明されているように、ローカル/etc/krb5.conf ファイルを使用すると、クライアント側プラグインが TGT の処理を完了したときに TGT を破棄できます。

サーバー側プラグインは TGT 自体または TGT の取得に使用される Kerberos パスワードにアクセスできません。

LDAP 認証プラグインはキャッシュメカニズム (ローカルファイル内、メモリー内などの記憶域) を制御しませんが、kswitch などの Kerberos ユーティリティをこの目的で使用できます。

/etc/krb5.conf クライアント構成パラメータ

クライアント側 SASL LDAP プラグインは、ローカル/etc/krb5.conf ファイルを読み取ります。 このファイルが欠落しているかアクセスできない場合は、エラーが発生します。 ファイルがアクセス可能であると仮定すると、オプションの[appdefaults]グループを使用して、プラグインで使用される情報を提供できます。 このような情報は、グループの MySQL セクションに配置します。 例:

[appdefaults]
  MySQL = {
    ldap_server_host = "ldap_host.example.com"
    ldap_destroy_tgt = true
  }

クライアント側プラグインは、MySQL セクションの次のパラメータを認識します:

• ldap_server_host 値は LDAP サーバーホストを指定し、そのホストが[realms]グループで指定された KDC サーバーホストと異なる場合に役立ちます。 デフォルトでは、プラグインは KDC サーバーホストを LDAP サーバーホストとして使用します。

• ldap_destroy_tgt 値は、クライアント側プラグインが TGT を取得して使用したあとに破棄するかどうかを示します。 デフォルトでは、ldap_destroy_tgt は false ですが、TGT の再利用を避けるために true に設定できます。 (この設定は、クライアント側プラグインによって作成された TGT にのみ適用され、MySQL の外部で作成された TGT には適用されません。)

LDAP 検索照会

LDAP サーバーは、LDAP 検索を別の LDAP サーバー (LDAP リフェラルと呼ばれる機能) に委任するように構成できます。 サーバー a.example.com が"dc=example,dc=com"ルート DN を保持し、別のサーバー b.example.com に検索を委任するとします。 これを有効にするために、a.example.com は次の属性を持つ名前付き参照オブジェクトで構成されます:

dn: dc=subtree,dc=example,dc=com
objectClass: referral
objectClass: extensibleObject
dc: subtree
ref: ldap://b.example.com/dc=subtree,dc=example,dc=com

LDAP 参照を有効にする問題は、検索ベース DN がルート DN で、参照オブジェクトが設定されていない場合に、検索が LDAP 操作エラーで失敗する可能性があることです。 LDAP リフェラルが ldap.conf 構成ファイルでグローバルに設定されている場合でも、MySQL DBA は LDAP 認証プラグインでこのようなリフェラルエラーを回避できます。 各プラグインとの通信時に LDAP サーバーが LDAP リフェラルを使用するかどうかをプラグイン固有のベースで構成するには、authentication_ldap_simple_referral および authentication_ldap_sasl_referral システム変数を設定します。 変数を ON または OFF に設定すると、対応する LDAP 認証プラグインによって、MySQL 認証時にリフェラルを使用するかどうかが LDAP サーバーに通知されます。 各変数にはプラグイン固有の効果があり、LDAP サーバーと通信する他のアプリケーションには影響しません。 デフォルトでは、どちらの変数も OFF です。