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

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

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

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

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

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

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

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

このセクションでは、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 プラガブル認証の使用 を参照してください。

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

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

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

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

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

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

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

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

MySQL ユーザーの 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)

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

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

betsy_ldap LDAP 識別名を指定する BY 句が CREATE USER ステートメントに含まれていない場合、認証の試行ではクライアントによって提供されたユーザー名 (この場合は betsy) が使用されます。 betsy の 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 認証プラグインはプロキシをサポートしているため、ユーザーはあるユーザーとして MySQL サーバーに接続できますが、別のユーザーの権限を引き受けます。 このセクションでは、LDAP プラグインの基本的なプロキシサポートについて説明します。 LDAP プラグインは、グループプリファレンスおよびプロキシユーザーマッピングの指定もサポートしています。LDAP 認証グループプリファレンスとマッピングの指定 を参照してください。

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

次の 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 プロキシユーザー名へのマッピングを実行します (存在する場合)。 プロキシアカウントの例では、マッピングは次のように行われます:

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

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

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

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

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 の概念および操作に精通していることを前提としています:

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

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

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

Kerberos 設定の確認

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

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

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 プラグインを次のように構成します:

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

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

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

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

-- create proxy account
CREATE USER 'bredon@MYSQL.LOCAL'
  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 'bredon@MYSQL.LOCAL';

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

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

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

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

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

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

取得された 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 サーバーは、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 です。