MySQL8-中文参考-十三-

MySQL8 中文参考（十三）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

原文：dev.mysql.com/doc/refman/8.0/en/windows-pluggable-authentication.html

8.4.1.6 Windows 可插拔认证

注意

Windows 可插拔认证是 MySQL 企业版中包含的扩展，这是一个商业产品。要了解更多关于商业产品的信息，请查看www.mysql.com/products/。

Windows 版 MySQL 企业版支持一种在 Windows 上执行外部认证的认证方法，使 MySQL 服务器能够使用本机 Windows 服务对客户端连接进行认证。已登录到 Windows 的用户可以根据其环境中的信息从 MySQL 客户端程序连接到服务器，而无需指定额外的密码。

客户端和服务器在认证握手中交换数据包。由于这种交换，服务器创建一个代表客户端在 Windows OS 中身份的安全上下文对象。这个身份包括客户端账户的名称。Windows 可插拔认证使用客户端的身份来检查它是否是给定账户或组的成员。默认情况下，协商使用 Kerberos 进行认证，如果 Kerberos 不可用，则使用 NTLM。

Windows 可插拔认证提供了以下功能：

  • 外部认证：Windows 认证使 MySQL 服务器能够接受来自在 Windows 登录的 MySQL 授权表之外定义的用户的连接。

  • 代理用户支持：Windows 认证可以将一个与客户端程序传递的外部用户名不同的用户名返回给 MySQL。这意味着插件可以返回定义外部 Windows 认证用户应具有的权限的 MySQL 用户。例如，一个名为joe的 Windows 用户可以连接并具有名为developer的 MySQL 用户的权限。

以下表格显示了插件和库文件的名称。文件必须位于由plugin_dir系统变量命名的目录中。

表 8.21 Windows 认证的插件和库名称

插件或文件 插件或文件名
服务器端插件 authentication_windows
客户端插件 authentication_windows_client
库文件 authentication_windows.dll

库文件仅包含服务器端插件。客户端插件内置于libmysqlclient客户端库中。

服务器端 Windows 认证插件仅包含在 MySQL 企业版中。它不包含在 MySQL 社区发行版中。客户端插件包含在所有发行版中，包括社区发行版。这使得来自任何发行版的客户端都能连接到加载了服务器端插件的服务器。

以下部分提供了特定于 Windows 可插拔认证的安装和使用信息：

  • 安装 Windows 可插拔认证

  • 卸载 Windows 可插拔认证

  • 使用 Windows 可插拔认证

有关 MySQL 中可插拔认证的一般信息，请参阅 Section 8.2.17, “Pluggable Authentication”。有关代理用户信息，请参阅 Section 8.2.19, “Proxy Users”。

安装 Windows 可插拔认证

本节描述了如何安装服务器端 Windows 认证插件。有关安装插件的一般信息，请参阅 Section 7.6.1, “Installing and Uninstalling Plugins”。

要被服务器使用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如果需要，通过在服务器启动时设置plugin_dir的值来配置插件目录位置。

要在服务器启动时加载插件，请使用--plugin-load-add选项命名包含插件的库文件。使用此插件加载方法，每次服务器启动时都必须提供该选项。例如，将以下行放入服务器my.cnf文件中：

[mysqld]
plugin-load-add=authentication_windows.dll

修改my.cnf后，重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用以下语句：

INSTALL PLUGIN authentication_windows SONAME 'authentication_windows.dll';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

要验证插件安装，请检查信息模式PLUGINS表，或使用SHOW PLUGINS语句（参见 Section 7.6.2, “Obtaining Server Plugin Information”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE '%windows%';
+------------------------+---------------+
| PLUGIN_NAME            | PLUGIN_STATUS |
+------------------------+---------------+
| authentication_windows | ACTIVE        |
+------------------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断消息。

要将 MySQL 帐户与 Windows 认证插件关联，请参阅使用 Windows 可插拔认证。 通过authentication_windows_use_principal_name和authentication_windows_log_level系统变量提供了额外的插件控制。 请参阅第 7.1.8 节，“服务器系统变量”。

卸载 Windows 可插拔认证

卸载 Windows 认证插件的方法取决于您安装它的方式：

  • 如果您在服务器启动时使用--plugin-load-add选项安装插件，请在不带该选项的情况下重新启动服务器。

  • 如果您使用INSTALL PLUGIN语句在运行时安装插件，则插件将在服务器重新启动时保持安装状态。 要卸载它，请使用UNINSTALL PLUGIN：

    UNINSTALL PLUGIN authentication_windows;

另外，删除任何设置 Windows 插件相关系统变量的启动选项。

使用 Windows 可插拔认证

Windows 认证插件支持使用 MySQL 帐户，使得已登录 Windows 的用户可以连接到 MySQL 服务器，而无需指定额外的密码。 假定服务器正在运行并启用了服务器端插件，如安装 Windows 可插拔认证中所述。 一旦 DBA 启用了服务器端插件并设置了要使用它的帐户，客户端就可以使用这些帐户连接，而无需进行其他设置。

在CREATE USER语句的IDENTIFIED WITH子句中引用 Windows 认证插件，请使用名称authentication_windows。 假设 Windows 用户Rafal和Tasha应被允许连接到 MySQL，以及Administrators或Power Users组中的任何用户。 要设置这一点，请创建一个名为sql_admin的 MySQL 帐户，该帐户使用 Windows 插件进行身份验证：

CREATE USER sql_admin
  IDENTIFIED WITH authentication_windows
  AS 'Rafal, Tasha, Administrators, "Power Users"';

插件名称为authentication_windows。 AS关键字后面的字符串是认证字符串。 它指定了名为Rafal或Tasha的 Windows 用户被允许作为 MySQL 用户sql_admin进行服务器身份验证，以及Administrators或Power Users组中的任何 Windows 用户。 后一个组名包含一个空格，因此必须用双引号括起来。

创建sql_admin账户后，已登录到 Windows 的用户可以尝试使用该账户连接到服务器：

C:\> mysql --user=sql_admin

这里不需要密码。authentication_windows插件使用 Windows 安全 API 来检查连接的是哪个 Windows 用户。如果该用户名为Rafal或Tasha，或者是Administrators或Power Users组的成员，则服务器授予访问权限，并将客户端验证为sql_admin，并具有授予sql_admin账户的任何权限。否则，服务器将拒绝访问。

Windows 认证插件的认证字符串语法遵循以下规则：

  • 该字符串由一个或多个以逗号分隔的用户映射组成。

  • 每个用户映射将 Windows 用户或组名与 MySQL 用户名称关联起来：

    *win_user_or_group_name=mysql_user_name*
*win_user_or_group_name*

    对于后一种语法，如果没有给出mysql_user_name值，则隐式值是由CREATE USER语句创建的 MySQL 用户。因此，以下语句是等效的：

    CREATE USER sql_admin
  IDENTIFIED WITH authentication_windows
  AS 'Rafal, Tasha, Administrators, "Power Users"';

CREATE USER sql_admin
  IDENTIFIED WITH authentication_windows
  AS 'Rafal=sql_admin, Tasha=sql_admin, Administrators=sql_admin,
      "Power Users"=sql_admin';

  • 值中的每个反斜杠字符（\）都必须加倍，因为反斜杠是 MySQL 字符串中的转义字符。

  • 在双引号内部的前导和尾随空格将被忽略。

  • 未引用的win_user_or_group_name和mysql_user_name值可以包含除等号、逗号或空格之外的任何内容。

  • 如果win_user_or_group_name和/或mysql_user_name值用双引号引起来，那么引号之间的所有内容都是值的一部分。例如，如果名称包含空格字符，则这是必要的。双引号内的所有字符都是合法的，除了双引号和反斜杠。要包含这两个字符，需要用反斜杠进行转义。

  • win_user_or_group_name值使用 Windows 主体的传统语法，可以是本地的或域中的。示例（注意反斜杠的加倍）：

    domain\\user
.\\user
domain\\group
.\\group
BUILTIN\\WellKnownGroup

当服务器调用插件来验证客户端时，插件从左到右扫描认证字符串，以查找与 Windows 用户匹配的用户或组。如果有匹配，插件将相应的mysql_user_name返回给 MySQL 服务器。如果没有匹配，则认证失败。

用户名称匹配优先于组名称匹配。假设名为win_user的 Windows 用户是win_group的成员，并且认证字符串如下所示：

'win_group = sql_user1, win_user = sql_user2'

当win_user连接到 MySQL 服务器时，既与win_group匹配，也与win_user匹配。插件将用户验证为sql_user2，因为更具体的用户匹配优先于组匹配，即使组在认证字符串中首先列出。

Windows 身份验证始终适用于从运行服务器的同一台计算机发起的连接。对于跨计算机连接，两台计算机必须在 Microsoft Active Directory 中注册。如果它们在同一个 Windows 域中，则无需指定域名。也可以允许来自不同域的连接，就像这个例子中一样：

CREATE USER sql_accounting
  IDENTIFIED WITH authentication_windows
  AS 'SomeDomain\\Accounting';

这里 SomeDomain 是另一个域的名称。反斜杠字符被加倍，因为它是字符串中的 MySQL 转义字符。

MySQL 支持代理用户的概念，即客户端可以使用一个账户连接和认证到 MySQL 服务器，但在连接时具有另一个账户的权限（参见 Section 8.2.19, “Proxy Users”）。假设您希望 Windows 用户使用单个用户名连接，但根据其 Windows 用户和组名称映射到特定的 MySQL 账户，如下所示：

  • local_user 和 MyDomain\domain_user 本地和域 Windows 用户应映射到 local_wlad MySQL 账户。

  • MyDomain\Developers 域组中的用户应映射到 local_dev MySQL 账户。

  • 本地机器管理员应映射到 local_admin MySQL 账户。

要设置这个，为 Windows 用户创建一个代理账户进行连接，并配置此账户，使用户和组映射到适当的 MySQL 账户（local_wlad、local_dev、local_admin）。此外，授予 MySQL 账户执行所需操作的适当权限。以下说明使用 win_proxy 作为代理账户，local_wlad、local_dev 和 local_admin 作为代理账户。

  1. 创建代理 MySQL 账户：

    CREATE USER win_proxy
  IDENTIFIED WITH  authentication_windows
  AS 'local_user = local_wlad,
      MyDomain\\domain_user = local_wlad,
      MyDomain\\Developers = local_dev,
      BUILTIN\\Administrators = local_admin';

  2. 为了使代理工作，代理账户必须存在，因此创建它们：

    CREATE USER local_wlad
  IDENTIFIED WITH mysql_no_login;
CREATE USER local_dev
  IDENTIFIED WITH mysql_no_login;
CREATE USER local_admin
  IDENTIFIED WITH mysql_no_login;

    代理账户使用 mysql_no_login 认证插件，以防止客户端直接使用这些账户登录到 MySQL 服务器。相反，使用 Windows 进行身份验证的用户应该使用 win_proxy 代理账户。（这假定插件已安装。有关说明，请参见 Section 8.4.1.9, “No-Login Pluggable Authentication”。）有关保护代理账户免受直接使用的替代方法，请参见 Preventing Direct Login to Proxied Accounts。

    您还应该执行 GRANT 语句（未显示），为每个代理账户授予所需的 MySQL 访问权限。

  3. 为代理账户授予 PROXY 权限，以代表每个代理账户：

    GRANT PROXY ON local_wlad TO win_proxy;
GRANT PROXY ON local_dev TO win_proxy;
GRANT PROXY ON local_admin TO win_proxy;

现在，Windows 用户local_user和MyDomain\domain_user可以作为win_proxy连接到 MySQL 服务器，并在经过身份验证后具有身份验证字符串中指定帐户（在本例中为local_wlad）的权限。以win_proxy身份连接的MyDomain\Developers组中的用户具有local_dev帐户的权限。BUILTIN\Administrators组中的用户具有local_admin帐户的权限。

要配置身份验证，使所有没有自己的 MySQL 帐户的 Windows 用户通过代理帐户进行身份验证，请在上述说明中将默认代理帐户（''@''）替换为win_proxy。有关默认代理帐户的信息，请参阅 Section 8.2.19, “Proxy Users”。

注意

如果您的 MySQL 安装中存在匿名用户，则它们可能与默认代理用户发生冲突。有关此问题的更多信息以及处理方法，请参阅 Default Proxy User and Anonymous User Conflicts。

要在 Connector/NET 8.0 及更高版本中使用 Windows 身份验证插件与 Connector/NET 连接字符串，请参阅 Connector/NET Authentication。

原文：dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html

8.4.1.7 LDAP 可插拔身份验证

注意

LDAP 可插拔身份验证是 MySQL 企业版中包含的扩展，是一种商业产品。要了解更多关于商业产品的信息，请参见www.mysql.com/products/。

MySQL 企业版支持一种身份验证方法，使 MySQL 服务器能够使用 LDAP（轻量级目录访问协议）通过访问目录服务（如 X.500）对 MySQL 用户进行身份验证。MySQL 使用 LDAP 获取用户、凭据和组信息。

LDAP 可插拔身份验证提供以下功能：

  • 外部身份验证：LDAP 身份验证使 MySQL 服务器能够接受来自 LDAP 目录中定义的用户的连接，而不是在 MySQL 授权表中定义的用户。

  • 代理用户支持：LDAP 身份验证可以根据外部用户所属的 LDAP 组返回一个与客户端程序传递的外部用户名不同的 MySQL 用户名给 MySQL，这意味着 LDAP 插件可以返回定义外部 LDAP 身份验证用户应具有的特权的 MySQL 用户。例如，名为joe的 LDAP 用户可以连接并具有名为developer的 MySQL 用户的特权，如果joe的 LDAP 组是developer。

  • 安全性：使用 TLS，连接到 LDAP 服务器可以是安全的。

服务器端和客户端插件可用于简单和基于 SASL 的 LDAP 身份验证。在 Microsoft Windows 上，不支持基于 SASL 的 LDAP 身份验证的服务器端插件，但支持客户端插件。

以下表格显示了简单和基于 SASL 的 LDAP 身份验证的插件和库文件名称。文件名后缀可能在您的系统上有所不同。这些文件必须位于由plugin_dir系统变量指定的目录中。

表 8.22 简单 LDAP 身份验证的插件和库名称

插件或文件 插件或文件名称
服务器端插件名称 authentication_ldap_simple
客户端插件名称 mysql_clear_password
库文件名称 authentication_ldap_simple.so

表 8.23 基于 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 客户端和服务器之间发送明文密码。

    注意

    在 Microsoft Windows 上，不支持基于 SASL 的 LDAP 认证的服务器插件，但支持客户端插件。在其他平台上，服务器和客户端插件都受支持。

服务器端的 LDAP 认证插件仅包含在 MySQL 企业版中。它们不包含在 MySQL 社区发行版中。客户端端的 SASL LDAP 插件包含在所有发行版中，包括社区发行版，并且如前所述，客户端的mysql_clear_password插件内置于libmysqlclient客户端库中，该库也包含在所有发行版中。这使得来自任何发行版的客户端都可以连接到加载了适当服务器端插件的服务器。

以下各节提供了特定于 LDAP 可插拔认证的安装和使用信息：

  • LDAP 可插拔认证的先决条件

  • MySQL 用户的 LDAP 认证工作原理

  • 安装 LDAP 可插拔认证

  • 卸载 LDAP 可插拔认证

  • LDAP 可插拔认证和 ldap.conf

  • 使用 LDAP 可插拔认证

  • 简单 LDAP 认证

  • 基于 SASL 的 LDAP 认证

  • 代理 LDAP 认证

  • LDAP 认证组偏好和映射规范

  • LDAP 认证用户 DN 后缀

  • LDAP 认证方法

  • GSSAPI/Kerberos 认证方法

  • LDAP 搜索引荐

有关 MySQL 中可插拔认证的一般信息，请参见第 8.2.17 节，“可插拔认证”。有关mysql_clear_password插件的信息，请参见第 8.4.1.4 节，“客户端明文可插拔认证”。有关代理用户信息，请参见第 8.2.19 节，“代理用户”。

注意

如果您的系统支持 PAM 并允许 LDAP 作为 PAM 认证方法，另一种使用 LDAP 进行 MySQL 用户认证的方法是使用服务器端authentication_pam插件。请参见第 8.4.1.5 节，“PAM 可插拔认证”。

LDAP 可插拔认证的先决条件

要为 MySQL 使用 LDAP 可插拔认证，必须满足以下先决条件：

  • 必须有 LDAP 服务器可用，以便 LDAP 认证插件与之通信。

  • 要由 MySQL 进行认证的 LDAP 用户必须存在于 LDAP 服务器管理的目录中。

  • 在使用服务器端authentication_ldap_sasl或authentication_ldap_simple插件的系统上必须有 LDAP 客户端库可用。目前支持的库是 Windows 本机 LDAP 库，或非 Windows 系统上的 OpenLDAP 库。

  • 要使用基于 SASL 的 LDAP 认证：

    • LDAP 服务器必须配置为与 SASL 服务器通信。

    • 在使用客户端端authentication_ldap_sasl_client插件的系统上必须有 SASL 客户端库可用。目前，唯一支持的库是 Cyrus SASL 库。

    • 要使用特定的 SASL 认证方法，必须提供该方法所需的任何其他服务。例如，要使用 GSSAPI/Kerberos，必须提供 GSSAPI 库和 Kerberos 服务。

MySQL 用户的 LDAP 认证工作原理

本节概述了 MySQL 和 LDAP 如何共同工作以对 MySQL 用户进行认证。有关如何设置 MySQL 账户以使用特定 LDAP 认证插件的示例，请参见使用 LDAP 可插拔认证。有关 LDAP 插件可用的认证方法的信息，请参见 LDAP 认证方法。

客户端连接到 MySQL 服务器，提供 MySQL 客户端用户名和密码：

  • 对于简单的 LDAP 认证，客户端和服务器端插件以明文形式传输密码。建议在 MySQL 客户端和服务器之间建立安全连接，以防止密码泄露。

  • 对于基于 SASL 的 LDAP 认证，客户端和服务器端插件避免在 MySQL 客户端和服务器之间发送明文密码。例如，插件可能使用 SASL 消息来在 LDAP 协议内安全传输凭据。对于 GSSAPI 认证方法，客户端和服务器端插件使用 Kerberos 进行安全通信，而不直接使用 LDAP 消息。

如果客户端用户名和主机名与任何 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 条目没有组属性，认证插件将返回客户端用户名作为经过认证的用户名。

MySQL 服务器将客户端用户名与经过认证的用户名进行比较，以确定客户端会话是否发生代理：

  • 如果名称相同，则不会发生代理：将用于权限检查的与客户端用户名匹配的 MySQL 帐户。

  • 如果名称不同，将发生代理：MySQL 将寻找与经过认证的用户名匹配的帐户。该帐户将成为代理用户，用于权限检查。与客户端用户名匹配的 MySQL 帐户将被视为外部代理用户。

安装 LDAP 可插入认证

本节描述了如何安装服务器端 LDAP 认证插件。有关安装插件的一般信息，请参见第 7.6.1 节，“安装和卸载插件”。

要被服务器使用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如有必要，通过在服务器启动时设置plugin_dir的值来配置插件目录位置。

服务器端插件库文件的基本名称为authentication_ldap_simple和authentication_ldap_sasl。文件名后缀因平台而异（例如，对于 Unix 和类 Unix 系统，为.so，对于 Windows 为.dll）。

注意

在 Microsoft Windows 上，不支持基于 SASL 的 LDAP 认证的服务器插件，但支持客户端插件。在其他平台上，服务器和客户端插件都受支持。

要在服务器启动时加载插件，使用--plugin-load-add选项命名包含插件的库文件。使用此插件加载方法，选项必须在每次服务器启动时给出。还要为您希望配置的任何插件提供的系统变量指定值。

每个服务器端 LDAP 插件都公开一组系统变量，以使其操作可以配置。设置大多数这些变量是可选的，但您必须设置指定 LDAP 服务器主机（以便插件知道在哪里连接）和 LDAP 绑定操作的基本区分名称（以限制搜索范围并获得更快的搜索）的变量。有关所有 LDAP 系统变量的详细信息，请参见第 8.4.1.13 节，“可插入认证系统变量”。

要加载插件并设置 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 实例的值，而不使其在后续重新启动时保留，请使用GLOBAL关键字而不是PERSIST。参见 Section 15.7.6.1, “SET Syntax for Variable Assignment”。

要验证插件安装，请检查信息模式PLUGINS表或使用SHOW PLUGINS语句（参见 Section 7.6.2, “Obtaining Server Plugin Information”）。例如：

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 的附加说明

在运行 EL6 或启用 SELinux 的 EL 系统上，需要更改 SELinux 策略以启用 MySQL LDAP 插件与 LDAP 服务通信：

  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;

另外，从您的 my.cnf 文件中删除任何设置 LDAP 插件相关系统变量的启动选项。如果您使用 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 配置，例如 authentication_ldap_simple_tls 和 authentication_ldap_simple_ca_path 用于简单 LDAP 认证，以及 authentication_ldap_sasl_tls 和 authentication_ldap_sasl_ca_path 用于 SASL LDAP 认证。

  • LDAP 引荐。请参阅 LDAP 搜索引荐。

有关 ldap.conf 的更多信息，请参阅 ldap.conf(5) 手册页。

使用 LDAP 可插拔认证

本节描述了如何启用 MySQL 帐户使用 LDAP 可插拔认证连接到 MySQL 服务器。假设服务器正在运行，并启用了适当的服务器端插件，如安装 LDAP 可插拔认证中所述，并且客户端主机上有适当的客户端插件可用。

本节不描述 LDAP 配置或管理。假定您已熟悉这些主题。

两个服务器端 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 目录条目。

  • 必须有一个 MySQL 用户帐户，指定一个服务器端 LDAP 身份验证插件，并可选择命名相关的 LDAP 用户专有名称（DN）。 （要将 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 服务器使用cn属性而不是uid来表示用户名。 要更改属性，请适当修改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

  • CREATE USER 语句创建 MySQL 账户时，在 BY 子句中指定 LDAP 用户，以指示 MySQL 账户进行身份验证的 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 服务器，并启用客户端端 mysql_clear_password 插件：

$> 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 选项）。 请参见 Section 8.4.1.4, “Client-Side Cleartext Pluggable Authentication”。

  • 为了避免启用 mysql_clear_password 插件时密码暴露，MySQL 客户端应该使用加密连接连接到 MySQL 服务器。 请参见 Section 8.3.1, “Configuring MySQL to Use Encrypted Connections”。

认证过程如下进行：

  1. 客户端插件将 betsy 和 betsy_password 作为客户端用户名和 LDAP 密码发送到 MySQL 服务器。

  2. 连接尝试匹配 'betsy'@'localhost' 账户。 服务器端 LDAP 插件发现该账户具有一个认证字符串 'uid=betsy_ldap,ou=People,dc=example,dc=com' 用于命名 LDAP 用户 DN。 该插件将此字符串和 LDAP 密码发送到 LDAP 服务器。

  3. LDAP 服务器找到了 betsy_ldap 的 LDAP 条目，并且密码匹配，因此 LDAP 认证成功。

  4. LDAP 条目没有组属性，因此服务器端插件将客户端用户名（betsy）作为经过身份验证的用户返回。这与客户端提供的相同用户名，因此不会发生代理，并且客户端会话使用'betsy'@'localhost'账户进行权限检查。

如果匹配的 LDAP 条目包含组属性，该属性值将成为经过身份验证的用户名，并且如果该值与betsy不同，则将发生代理。有关使用组属性的示例，请参阅具有代理功能的 LDAP 认证。

如果CREATE USER语句中没有包含BY子句来指定betsy_ldap LDAP 专有名称，认证尝试将使用客户端提供的用户名（在本例中为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 服务器：

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

对于服务器端的authentication_ldap_sasl插件，客户端使用客户端的authentication_ldap_sasl_client插件。如果客户端程序找不到客户端插件，请指定一个--plugin-dir选项，指定安装插件库文件的目录。

boris的认证过程与之前描述的betsy的简单 LDAP 认证类似，只是客户端和服务器端的 SASL LDAP 插件使用 SASL 消息来在 LDAP 协议中安全传输凭据，以避免在 MySQL 客户端和服务器之间发送明文密码。

具有代理功能的 LDAP 认证

LDAP 认证插件支持代理，使用户可以以一个用户连接到 MySQL 服务器，但假定另一个用户的权限。本节描述了基本的 LDAP 插件代理支持。LDAP 插件还支持指定组偏好和代理用户映射；请参阅 LDAP 认证组偏好和映射规范。

此处描述的代理实现基于使用 LDAP 组属性值将通过 LDAP 进行身份验证的连接 MySQL 用户映射到定义不同权限集的其他 MySQL 账户。用户不会直接通过定义权限的账户连接。相反，他们通过使用 LDAP 进行身份验证的默认代理账户连接，以便将所有外部登录映射到持有权限的代理 MySQL 账户。通过代理账户连接的任何用户都将映射到其中一个代理 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;

代理账户定义中没有AS '*auth_string*'子句来命名 LDAP 用户 DN。因此：

  • 当客户端连接时，客户端用户名将成为要搜索的 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插件。有关说明，请参见 Section 8.4.1.9, “No-Login Pluggable Authentication”。）有关保护代理帐户免受直接使用的替代方法，请参见 Preventing Direct Login to Proxied Accounts。

为每个代理帐户授予PROXY权限：

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

使用mysql命令行客户端连接到 MySQL 服务器作为basha。

$> 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：

$> 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 插件使用grp2，因为它是认证字符串中第一个匹配的组，即使它不是 LDAP 服务器返回的第一个组。如果 LDAP 服务器返回grp4、grp2和grp1，插件使用grp1，即使grp2也匹配。grp1的优先级高于grp2，因为它在认证字符串中较早列出。

假设插件找到组名匹配，它将从该组名映射到 MySQL 代理用户名称，如果有的话。对于示例代理账户，映射如下进行：

  • 如果匹配的组名是grp1或grp3，它们在认证字符串中与用户名称usera和userc相关联。插件使用相应的关联用户名称作为代理用户名称。

  • 如果匹配的组名是 grp2，认证字符串中没有关联的用户名。插件使用 grp2 作为代理用户名称。

如果 LDAP 服务器以 DN 格式返回组，LDAP 插件会解析组 DN 以从中提取组名。

要指定 LDAP 组偏好和映射信息，应遵循以下原则：

  • 用 # 前缀字符开始认证字符串的组偏好和映射部分。

  • 组偏好和映射规范是由逗号分隔的一个或多个项目的列表。每个项目的形式为 *group_name*=*user_name* 或 group_name。项目应按组名偏好顺序列出。对于插件从 LDAP 服务器返回的组名集合中选择的组名，两种语法在效果上有所不同：

    • 对于指定为 *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 认证方法

通用安全服务应用程序接口（GSSAPI）是一个安全抽象接口。Kerberos 是可以通过该抽象接口使用的特定安全协议的一个实例。使用 GSSAPI，应用程序通过 Kerberos 进行身份验证以获取服务凭证，然后再使用这些凭证来实现对其他服务的安全访问。

其中一种服务是 LDAP，它被客户端和服务器端的 SASL LDAP 认证插件使用。当 authentication_ldap_sasl_auth_method_name 系统变量设置为 GSSAPI 时，这些插件使用 GSSAPI/Kerberos 认证方法。在这种情况下，插件通过 Kerberos 安全通信，而不直接使用 LDAP 消息。服务器端插件然后与 LDAP 服务器通信以解释 LDAP 认证消息并检索 LDAP 组。

GSSAPI/Kerberos 在 Linux 上作为 MySQL 服务器和客户端的 LDAP 认证方法得到支持。在 Linux 环境中，当应用程序通过默认启用 Kerberos 的 Microsoft Active Directory 访问 LDAP 时，这是非常有用的。

以下讨论提供了使用 GSSAPI 方法的配置要求信息。假定熟悉 Kerberos 概念和操作。以下列表简要定义了几个常见的 Kerberos 术语。您还可以在 RFC 4120 的术语表部分找到有用的信息。

  • 主体：一个命名实体，比如用户或服务器。

  • KDC：密钥分发中心，包括 AS 和 TGS：

    • AS：认证服务器；提供获取额外票证所需的初始票证授予票证。

    • TGS：票证授予服务器；为拥有有效 TGT 的 Kerberos 客户端提供额外票证。

  • TGT：票据授予票据；提交给 TGS 以获取用于服务访问的服务票据。

使用 Kerberos 进行 LDAP 身份验证需要 KDC 服务器和 LDAP 服务器。可以通过不同方式满足此要求：

  • Active Directory 包括两个服务器，Active Directory LDAP 服务器默认启用 Kerberos 身份验证。

  • OpenLDAP 提供了一个 LDAP 服务器，但可能需要一个单独的 KDC 服务器，并需要额外的 Kerberos 设置。

客户端主机上也必须可用 Kerberos。客户端使用密码联系 AS 以获取 TGT。然后，客户端使用 TGT 从 TGS 获取其他服务的访问权限，例如 LDAP。

以下各节讨论了在 MySQL 中使用 GSSAPI/Kerberos 进行 SASL LDAP 身份验证的配置步骤：

  • 验证 Kerberos 和 LDAP 的可用性

  • 为 GSSAPI/Kerberos 配置服务器端 SASL LDAP 身份验证插件

  • 创建一个使用 GSSAPI/Kerberos 进行 LDAP 身份验证的 MySQL 帐户

  • 使用 MySQL 帐户连接到 MySQL 服务器

  • LDAP 身份验证的客户端配置参数

验证 Kerberos 和 LDAP 的可用性

以下示例显示如何在 Active Directory 中测试 Kerberos 的可用性。示例做出以下假设：

  • Active Directory 运行在名为ldap_auth.example.com的主机上，IP 地址为198.51.100.10。

  • 与 MySQL 相关的 Kerberos 身份验证和 LDAP 查找使用MYSQL.LOCAL域。

  • 名为bredon@MYSQL.LOCAL的主体已在 KDC 中注册。（在后续讨论中，此主体名称还与使用 GSSAPI/Kerberos 对 MySQL 服务器进行身份验证的 MySQL 帐户相关联。）

在满足这些假设的情况下，按照以下步骤操作：

  1. 验证操作系统中 Kerberos 库是否已安装和配置正确。例如，要为 MySQL 身份验证期间使用MYSQL.LOCAL域，/etc/krb5.conf Kerberos 配置文件应包含类似于以下内容：

    [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 bredon@MYSQL.LOCAL
Password for bredon@MYSQL.LOCAL: *(enter password here)*

      该命令用于验证名为bredon@MYSQL.LOCAL的 Kerberos 主体。当命令提示时，请输入主体的密码。KDC 返回一个 TGT，该 TGT 在客户端缓存中供其他支持 Kerberos 的应用程序使用。

    2. 使用klist检查 TGT 是否正确获取。输出应类似于以下内容：

      $> klist
Ticket cache: FILE:/tmp/krb5cc_244306
Default principal: bredon@MYSQL.LOCAL

Valid starting       Expires              Service principal
03/23/2021 08:18:33  03/23/2021 18:18:33  krbtgt/MYSQL.LOCAL@MYSQL.LOCAL

  4. 使用此命令检查ldapsearch是否与 Kerberos TGT 一起工作，该命令在MYSQL.LOCAL域中搜索用户：

    ldapsearch -h 198.51.100.10 -Y GSSAPI -b "dc=MYSQL,dc=LOCAL"
配置服务器端 SASL LDAP 认证插件以使用 GSSAPI/Kerberos

假设 LDAP 服务器可以通过上述方式访问 Kerberos，配置服务器端 SASL LDAP 认证插件以使用 GSSAPI/Kerberos 认证方法。（有关一般 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语句加载了插件，则此选项是不必要的。

  • authentication_ldap_sasl_auth_method_name必须设置为GSSAPI以使用 GSSAPI/Kerberos 作为 SASL LDAP 认证方法。

  • 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指示用户 DN 基本路径，以便搜索在MYSQL.LOCAL域中的用户。

  • authentication_ldap_sasl_user_search_attr 指定了一个标准的 Active Directory 搜索属性，sAMAccountName。此属性用于搜索以匹配登录名；属性值与用户 DN 值不同。

创建一个使用 GSSAPI/Kerberos 进行 LDAP 认证的 MySQL 账户

使用 GSSAPI/Kerberos 方法的 SASL LDAP 认证插件进行 MySQL 认证是基于一个作为 Kerberos 主体的用户。以下讨论使用一个名为 bredon@MYSQL.LOCAL 的主体作为此用户，必须在多个地方注册：

  • Kerberos 管理员应该将用户名称注册为 Kerberos 主体。此名称应包括域名。客户端使用主体名称和密码进行 Kerberos 认证并获取 TGT。

  • LDAP 管理员应在 LDAP 条目中注册用户名称。例如：

    uid=bredon,dc=MYSQL,dc=LOCAL

    注意

    在 Active Directory（默认使用 Kerberos 作为认证方法），创建用户会同时创建 Kerberos 主体和 LDAP 条目。

  • MySQL DBA 应创建一个账户，其用户名称为 Kerberos 主体名称，并使用 SASL LDAP 插件进行认证。

假设适当的服务管理员已经注册了 Kerberos 主体和 LDAP 条目，并且，如前面在 Installing LDAP Pluggable Authentication 和 Configure the Server-Side SASL LDAP Authentication Plugin for GSSAPI/Kerberos 中描述的那样，MySQL 服务器已经以适当的配置设置启动了服务器端 SASL LDAP 插件。然后 MySQL DBA 创建一个对应于 Kerberos 主体名称的 MySQL 账户，包括域名。

注意

SASL LDAP 插件对于 Kerberos 认证使用一个固定的用户 DN，并忽略从 MySQL 配置的任何用户 DN。这有一定的影响：

  • 对于使用 GSSAPI/Kerberos 认证的任何 MySQL 账户，在 CREATE USER 或 ALTER USER 语句中的认证字符串不应包含用户 DN，因为它没有任何效果。

  • 因为认证字符串不包含用户 DN，所以应包含组映射信息，以使用户能够作为映射到所需代理用户的代理用户进行处理。有关使用 LDAP 认证插件进行代理的信息，请参阅 LDAP Authentication with Proxying。

以下语句创建一个名为bredon@MYSQL.LOCAL的代理用户，该用户假定了被代理用户proxied_krb_usr的权限。其他应具有相同权限的 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 账户，用户和主机是账户名称的独立部分，因此分别引用为'*user_name*'@'*host_name*'。

  • 对于 LDAP Kerberos 认证，账户名称的用户部分包括主体域，因此'bredon@MYSQL.LOCAL'被引用为单个值。因为没有给出主机部分，所以完整的 MySQL 账户名称使用默认的'%'作为主机部分：'bredon@MYSQL.LOCAL'@'%'

注意

当创建一个使用 GSSAPI/Kerberos 认证方法的authentication_ldap_sasl SASL LDAP 认证插件进行身份验证的账户时，CREATE USER语句将领域作为用户名的一部分。这与使用authentication_kerberos Kerberos 插件创建账户不同。对于这样的账户，CREATE USER语句不包括领域作为用户名的一部分。而是在BY子句中指定领域作为认证字符串。请参阅创建使用 Kerberos 认证的 MySQL 账户。

被代理账户使用mysql_no_login认证插件防止客户端直接使用该账户登录到 MySQL 服务器。相反，预期使用 LDAP 进行身份验证的用户使用bredon@MYSQL.LOCAL代理账户。（这假设已安装mysql_no_login插件。有关说明，请参见第 8.4.1.9 节，“无登录可插入认证”。）有关保护被代理账户免受直接使用的替代方法，请参见防止直接登录到被代理账户。

使用 MySQL 账户连接到 MySQL 服务器

设置使用 GSSAPI/Kerberos 进行身份验证的 MySQL 账户后，客户端可以使用它连接到 MySQL 服务器。Kerberos 认证可以在 MySQL 客户端程序调用之前或同时进行：

  • 在调用 MySQL 客户端程序之前，客户端用户可以独立于 MySQL 从 KDC 获取 TGT。例如，客户端用户可以使用kinit通过提供 Kerberos 主体名称和主体密码来对 Kerberos 进行身份验证：

    $> kinit bredon@MYSQL.LOCAL
Password for bredon@MYSQL.LOCAL: *(enter password here)*

    结果的 TGT 被缓存并可供其他了解 Kerberos 的应用程序使用，例如使用客户端端 SASL LDAP 认证插件的程序。在这种情况下，MySQL 客户端程序使用 TGT 对 MySQL 服务器进行认证，因此调用客户端时不需要指定用户名或密码：

    mysql --default-auth=authentication_ldap_sasl_client

    正如刚才所描述的，当 TGT 被缓存时，在客户端命令中不需要用户名称和密码选项。如果命令中仍然包含它们，则处理如下：

    • 如果命令包含用户名，如果该名称与 TGT 中的主体名称不匹配，则认证失败。

    • 如果命令包含密码，客户端插件会忽略它。因为认证是基于 TGT 的，即使用户提供的密码不正确，也可以成功。因此，如果找到有效的 TGT 导致密码被忽略，插件会产生警告。

  • 如果 Kerberos 缓存中不包含 TGT，则客户端端 SASL LDAP 认证插件本身可以从 KDC 获取 TGT。使用与 MySQL 账户关联的 Kerberos 主体的名称和密码选项调用客户端（在提示时输入主体密码）：

    mysql --default-auth=authentication_ldap_sasl_client
  --user=bredon@MYSQL.LOCAL
  --password

  • 如果 Kerberos 缓存中不包含 TGT，并且客户端命令未指定主体名称作为用户名，则认证失败。

如果您不确定是否存在 TGT，可以使用 klist 进行检查。

认证过程如下：

  1. 客户端使用 TGT 使用 Kerberos 进行认证。

  2. 服务器找到主体的 LDAP 条目并用它来认证连接到 bredon@MYSQL.LOCAL MySQL 代理账户。

  3. 代理账户认证字符串中的组映射信息（'#krb_grp=proxied_krb_user'）表示认证的被代理用户应该是 proxied_krb_user。

  4. bredon@MYSQL.LOCAL 被视为 proxied_krb_user 的代理，并且以下查询返回如下输出：

    mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
+------------------------------+--------------------+--------------------------+
| USER()                       | CURRENT_USER()     | @@proxy_user             |
+------------------------------+--------------------+--------------------------+
| bredon@MYSQL.LOCAL@localhost | proxied_krb_user@% | 'bredon@MYSQL.LOCAL'@'%' |
+------------------------------+--------------------+--------------------------+

    USER() 值表示用于客户端命令的用户名（bredon@MYSQL.LOCAL）和客户端连接的主机（localhost）。

    CURRENT_USER() 值是被代理用户账户的全名，由 proxied_krb_user 用户部分和 % 主机部分组成。

    @@proxy_user 值表示用于连接到 MySQL 服务器的账户的全名，由 bredon@MYSQL.LOCAL 用户部分和 % 主机部分组成。

    这表明代理是通过 bredon@MYSQL.LOCAL 代理用户账户进行的，并且 bredon@MYSQL.LOCAL 承担了授予 proxied_krb_user 被代理用户账户的权限。

一旦获得 TGT，客户端会将其缓存在本地，并且在不再需要重新输入密码的情况下可以一直使用直到过期。无论如何获取 TGT，客户端插件都会使用它来获取服务票据并与服务器端插件通信。

注意

当客户端身份验证插件本身获取 TGT 时，客户端用户可能不希望 TGT 被重复使用。如 LDAP 身份验证的客户端配置参数所述，本地的/etc/krb5.conf文件可用于使客户端插件在完成后销毁 TGT。

服务器端插件无法访问 TGT 本身或用于获取 TGT 的 Kerberos 密码。

LDAP 身份验证插件无法控制缓存机制（存储在本地文件中、内存中等），但 Kerberos 实用程序如kswitch可能可用于此目的。

LDAP 身份验证的客户端配置参数

authentication_ldap_sasl_client客户端端 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 后是否销毁 TGT。默认情况下，ldap_destroy_tgt为false，但可以设置为true以避免 TGT 重复使用。（此设置仅适用于由客户端插件创建的 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.conf配置文件中全局设置了 LDAP 引荐，MySQL DBA 可能希望避免 LDAP 认证插件出现此类引荐错误。要根据插件特定的基础配置 LDAP 服务器在与每个插件通信时是否应使用 LDAP 引荐，需设置authentication_ldap_simple_referral和authentication_ldap_sasl_referral系统变量。将任一变量设置为ON或OFF会导致相应的 LDAP 认证插件告知 LDAP 服务器在 MySQL 认证期间是否使用引荐。每个变量具有插件特定的效果，不会影响与 LDAP 服务器通信的其他应用程序。这两个变量默认为OFF。

原文：dev.mysql.com/doc/refman/8.0/en/kerberos-pluggable-authentication.html

8.4.1.8 Kerberos 可插拔认证

注意

Kerberos 可插拔认证是 MySQL 企业版中包含的扩展，这是一个商业产品。要了解更多关于商业产品的信息，请参见www.mysql.com/products/。

MySQL 企业版支持一种认证方法，允许用户使用 Kerberos 对 MySQL 服务器进行身份验证，前提是有适当的 Kerberos 票证可用或可以获取。

该认证方法适用于 MySQL 8.0.26 及更高版本，在 Linux 上的 MySQL 服务器和客户端。在 Linux 环境中，应用程序可以访问默认启用 Kerberos 的 Microsoft Active Directory 时，这是非常有用的。从 MySQL 8.0.27 开始（MIT Kerberos 的 MySQL 8.0.32），客户端端插件也在 Windows 上受支持。服务器端插件仍然只在 Linux 上受支持。

Kerberos 可插拔认证提供了以下功能：

  • 外部认证：Kerberos 认证使 MySQL 服务器能够接受来自 MySQL 授权表之外定义的用户的连接，这些用户已经获得了适当的 Kerberos 票证。

  • 安全性：Kerberos 使用票证与对称密钥加密结合，实现了在网络上传输密码的身份验证。Kerberos 认证支持无用户和无密码的场景。

以下表显示了插件和库文件名称。文件名后缀可能在您的系统上有所不同。该文件必须位于由plugin_dir系统变量命名的目录中。有关安装信息，请参见安装 Kerberos 可插拔认证。

表 8.24 Kerberos 认证的插件和库名称

插件或文件 插件或文件名
服务器端插件 authentication_kerberos
客户端插件 authentication_kerberos_client
库文件 authentication_kerberos.so，authentication_kerberos_client.so

服务器端 Kerberos 认证插件仅包含在 MySQL 企业版中。它不包含在 MySQL 社区发行版中。客户端插件包含在所有发行版中，包括社区发行版。这使得来自任何发行版的客户端都可以连接到加载了服务器端插件的服务器。

以下各节提供了特定于 Kerberos 可插拔认证的安装和使用信息：

  • Kerberos 可插拔认证的先决条件

  • MySQL 用户的 Kerberos 认证工作原理

  • 安装 Kerberos 可插拔认证

  • 使用 Kerberos 可插拔认证

  • Kerberos 认证调试

有关 MySQL 中可插拔认证的一般信息，请参阅 第 8.2.17 节，“可插拔认证”。

Kerberos 可插拔认证的先决条件

要在 MySQL 中使用可插拔的 Kerberos 认证，必须满足以下先决条件：

  • 必须提供一个 Kerberos 服务，以便 Kerberos 认证插件进行通信。

  • MySQL 要对其进行认证的每个 Kerberos 用户（主体）必须存在于 KDC 服务器管理的数据库中。

  • 在使用服务器端或客户端 Kerberos 认证插件的系统上必须提供 Kerberos 客户端库。此外，GSSAPI 用作访问 Kerberos 认证的接口，因此必须提供 GSSAPI 库。

MySQL 用户的 Kerberos 认证工作原理

本节概述了 MySQL 和 Kerberos 如何共同工作以对 MySQL 用户进行认证。有关如何设置 MySQL 帐户以使用 Kerberos 认证插件的示例，请参阅 使用 Kerberos 可插拔认证。

假定读者熟悉 Kerberos 的概念和操作。以下列表简要定义了几个常见的 Kerberos 术语。您还可以在 RFC 4120 的术语表部分找到有用的信息。

  • 主体：命名实体，如用户或服务器。在本讨论中，某些与主体相关的术语经常出现：

    • SPN：服务主体名称；代表服务的主体名称。

    • UPN：用户主体名称；代表用户的主体名称。

  • KDC：密钥分发中心，包括 AS 和 TGS：

    • AS：认证服务器；提供获取额外票证所需的初始票证授予票证。

    • TGS：票据授予服务器；为拥有有效 TGT 的 Kerberos 客户端提供额外的票据。

  • TGT：票据授予票据；提交给 TGS 以获取用于服务访问的服务票据。

  • ST：服务票据；提供对 MySQL 服务器等服务的访问。

使用 Kerberos 进行身份验证需要一个 KDC 服务器，例如，由 Microsoft Active Directory 提供。

MySQL 中的 Kerberos 认证使用通用安全服务应用程序接口（GSSAPI），这是一个安全抽象接口。Kerberos 是可以通过该抽象接口使用的特定安全协议的一个实例。使用 GSSAPI，应用程序进行身份验证以获取服务凭据，然后依次使用这些凭据来启用对其他服务的安全访问。

在 Windows 上，authentication_kerberos_client 认证插件支持两种模式，客户端用户可以在运行时设置或在选项文件中指定：

  • SSPI 模式：安全支持提供程序接口（SSPI）实现了 GSSAPI（参见 SSPI 模式下的 Windows 客户端命令）。SSPI 在传输层面与 GSSAPI 兼容，但仅支持 Windows 单点登录场景，并且专门指代已登录用户。SSPI 是大多数 Windows 客户端的默认模式。

  • GSSAPI 模式：在 Windows 上通过 MIT Kerberos 库支持 GSSAPI（参见 GSSAPI 模式下的 Windows 客户端命令）。

使用 Kerberos 认证插件，应用程序和 MySQL 服务器能够使用 Kerberos 认证协议相互认证用户和 MySQL 服务。这样，用户和服务器都能够验证彼此的身份。不会通过网络发送密码，并且 Kerberos 协议消息受到窃听和重放攻击的保护。

MySQL 中的 Kerberos 认证遵循这些步骤，其中服务器端和客户端部分分别使用 authentication_kerberos 和 authentication_kerberos_client 认证插件执行：

  1. MySQL 服务器向客户端应用程序发送其服务主体名称。此 SPN 必须在 Kerberos 系统中注册，并且在服务器端使用 authentication_kerberos_service_principal 系统变量进行配置。

  2. 使用 GSSAPI，客户端应用程序创建一个 Kerberos 客户端端身份验证会话，并与 Kerberos KDC 交换 Kerberos 消息：

    • 客户端从认证服务器获取票据授予票据。

    • 使用 TGT，客户端从票据授予服务获取 MySQL 的服务票据。

    如果 TGT、ST 或两者都已在本地缓存，则可以跳过或部分跳过此步骤。客户端可以选择使用客户端 keytab 文件来获取 TGT 和 ST，而无需提供密码。

  3. 使用 GSSAPI，客户端应用程序向 MySQL 服务器呈现 MySQL ST。

  4. 使用 GSSAPI，MySQL 服务器创建一个 Kerberos 服务器端认证会话。服务器验证用户身份和用户请求的有效性。它使用其服务 keytab 文件中配置的服务密钥验证 ST，以确定身份验证成功或失败，并将身份验证结果返回给客户端。

应用程序可以使用提供的用户名和密码进行身份验证，也可以使用本地缓存的 TGT 或 ST（例如，使用 kinit 或类似方法创建）。因此，此设计涵盖了各种用例，从完全无用户和无密码连接，其中 Kerberos 服务票据是从本地存储的 Kerberos 缓存获取的，到提供并使用用户名和密码以获取有效的 Kerberos 服务票据从 KDC 发送到 MySQL 服务器的连接。

如前述描述所示，MySQL 的 Kerberos 认证使用两种类型的 keytab 文件：

  • 在客户端主机上，可以使用客户端 keytab 文件来获取 TGT 和 ST，而无需提供密码。请参阅 Client Configuration Parameters for Kerberos Authentication。

  • 在 MySQL 服务器主机上，使用服务器端服务 keytab 文件来验证 MySQL 服务器从客户端接收的服务票据。 keytab 文件名是使用 authentication_kerberos_service_key_tab 系统变量配置的。

有关 keytab 文件的信息，请参阅 web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html。

安装 Kerberos 可插拔认证

本节描述了如何安装服务器端 Kerberos 认证插件。有关安装插件的一般信息，请参阅 Section 7.6.1, “Installing and Uninstalling Plugins”。

注意

服务器端插件仅在 Linux 系统上受支持。在 Windows 系统上，仅支持客户端端插件（截至 MySQL 8.0.27），可以在 Windows 系统上用于连接使用 Kerberos 认证的 Linux 服务器。

要使服务器可用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。必要时，通过设置plugin_dir的值来配置插件目录位置以在服务器启动时生效。

服务器端插件库文件基本名称为authentication_kerberos。Unix 和类 Unix 系统的文件名后缀为.so。

要在服务器启动时加载插件，请使用--plugin-load-add选项命名包含插件的库文件。使用此插件加载方法，每次服务器启动时都必须提供该选项。还要为您希望配置的任何插件提供的系统变量指定值。插件公开这些系统变量，使其操作可以配置：

  • authentication_kerberos_service_principal: MySQL 服务主体名称（SPN）。此名称将发送给尝试使用 Kerberos 进行身份验证的客户端。SPN 必须存在于 KDC 服务器管理的数据库中。默认值为mysql/*host_name*@*realm_name*。

  • authentication_kerberos_service_key_tab: 用于验证从客户端接收到的票证的 keytab 文件。此文件必须存在并包含 SPN 的有效密钥，否则客户端的身份验证将失败。默认值为数据目录中的mysql.keytab。

有关所有 Kerberos 身份验证系统变量的详细信息，请参见 Section 8.4.1.13, “Pluggable Authentication System Variables”。

要加载插件并配置它，请在您的my.cnf文件中放入类似以下行的内容，使用适合您安装的系统变量的值：

[mysqld]
plugin-load-add=authentication_kerberos.so
authentication_kerberos_service_principal=mysql/krbauth.example.com@MYSQL.LOCAL
authentication_kerberos_service_key_tab=/var/mysql/data/mysql.keytab

修改my.cnf后，重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用以下语句：

INSTALL PLUGIN authentication_kerberos
  SONAME 'authentication_kerberos.so';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

当您在运行时安装插件而没有在my.cnf文件中配置其系统变量时，系统变量 authentication_kerberos_service_key_tab 将设置为数据目录中的默认值mysql.keytab。此系统变量的值不能在运行时更改，因此如果需要指定不同的文件，您需要将设置添加到您的my.cnf文件，然后重新启动 MySQL 服务器。例如：

[mysqld]
authentication_kerberos_service_key_tab=/var/mysql/data/mysql.keytab

如果 keytab 文件不在正确的位置或不包含有效的 SPN 密钥，则 MySQL 服务器不会验证此问题，但客户端会返回身份验证错误，直到您解决问题。

authentication_kerberos_service_principal 系统变量可以在运行时使用 SET PERSIST 语句设置和持久化，而无需重新启动服务器：

SET PERSIST authentication_kerberos_service_principal='mysql/krbauth.example.com@MYSQL.LOCAL';

SET PERSIST 为运行中的 MySQL 实例设置一个值。它还保存该值，导致其在后续服务器重启时保留。要更改运行中的 MySQL 实例的值，而不使其在后续重启中保留，使用GLOBAL关键字而不是PERSIST。参见 Section 15.7.6.1, “变量赋值的 SET 语法”。

要验证插件安装，请检查信息模式 PLUGINS 表或使用 SHOW PLUGINS 语句（参见 Section 7.6.2, “获取服务器插件信息”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME = 'authentication_kerberos';
+-------------------------+---------------+
| PLUGIN_NAME             | PLUGIN_STATUS |
+-------------------------+---------------+
| authentication_kerberos | ACTIVE        |
+-------------------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断信息。

要将 MySQL 帐户与 Kerberos 插件关联，请参见 使用 Kerberos 可插拔认证。

使用 Kerberos 可插拔认证

本节描述了如何启用 MySQL 帐户使用 Kerberos 可插拔认证连接到 MySQL 服务器。假定服务器正在运行并启用了服务器端插件，如 安装 Kerberos 可插拔认证 中所述，并且客户端主机上可用客户端插件。

  • 验证 Kerberos 可用性

  • 创建一个使用 Kerberos 身份验证的 MySQL 帐户

  • 使用 MySQL 帐户连接到 MySQL 服务器

  • Kerberos 身份验证的客户端配置参数

验证 Kerberos 的可用性

以下示例显示如何测试 Active Directory 中 Kerberos 的可用性。该示例做出以下假设：

  • Active Directory 正在名为krbauth.example.com的主机上运行，IP 地址为198.51.100.11。

  • 与 MySQL 相关的 Kerberos 身份验证使用MYSQL.LOCAL域，并且还使用MYSQL.LOCAL作为领域名称。

  • 名为karl@MYSQL.LOCAL的主体已在 KDC 中注册。（在后续讨论中，此主体名称与使用 Kerberos 身份验证连接到 MySQL 服务器的 MySQL 帐户相关联。）

在满足这些假设的情况下，按照以下步骤进行：

  1. 验证操作系统中是否正确安装和配置了 Kerberos 库。例如，要在 MySQL 身份验证期间使用MYSQL.LOCAL域和领域，/etc/krb5.conf Kerberos 配置文件应包含类似于以下内容：

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

  2. 您可能需要为服务器主机在/etc/hosts中添加一个条目：

    198.51.100.11 krbauth krbauth.example.com

  3. 检查 Kerberos 身份验证是否正常工作：

    1. 使用kinit进行 Kerberos 身份验证：

      $> kinit karl@MYSQL.LOCAL
Password for karl@MYSQL.LOCAL: *(enter password here)*

      该命令对名为karl@MYSQL.LOCAL的 Kerberos 主体进行身份验证。当命令提示时输入主体密码。KDC 返回一个 TGT，该 TGT 在客户端缓存以供其他了解 Kerberos 的应用程序使用。

    2. 使用klist检查 TGT 是否正确获取。输出应类似于以下内容：

      $> klist
Ticket cache: FILE:/tmp/krb5cc_244306
Default principal: karl@MYSQL.LOCAL

Valid starting       Expires              Service principal
03/23/2021 08:18:33  03/23/2021 18:18:33  krbtgt/MYSQL.LOCAL@MYSQL.LOCAL
创建一个使用 Kerberos 身份验证的 MySQL 帐户

使用authentication_kerberos身份验证插件进行 MySQL 身份验证基于 Kerberos 用户主体名称（UPN）。这里的说明假设一个名为karl的 MySQL 用户使用 Kerberos 进行 MySQL 身份验证，Kerberos 领域命名为MYSQL.LOCAL，用户主体名称为karl@MYSQL.LOCAL。这个 UPN 必须在几个地方注册：

  • Kerberos 管理员应将用户名称注册为 Kerberos 主体。此名称包括领域名称。客户端使用主体名称和密码进行 Kerberos 身份验证，并获取票据授予票据（TGT）。

  • MySQL DBA 应创建一个与 Kerberos 主体名称对应并使用 Kerberos 插件进行身份验证的帐户。

假设适当的服务管理员已注册了 Kerberos 用户主体名称，并且如前所述在安装 Kerberos 可插拔认证中，MySQL 服务器已使用适当的配置设置启动了服务器端 Kerberos 插件。要创建与 Kerberos UPN *user*@*realm_name*对应的 MySQL 帐户，MySQL DBA 使用类似于以下语句：

CREATE USER *user*
  IDENTIFIED WITH authentication_kerberos
  BY '*realm_name*';

由user指定的帐户可以包含或省略主机名部分。如果省略主机名，则通常默认为%。realm_name存储为mysql.user系统表中帐户的authentication_string值。

要创建与 UPN karl@MYSQL.LOCAL对应的 MySQL 帐户，请使用此语句：

CREATE USER 'karl'
  IDENTIFIED WITH authentication_kerberos
  BY 'MYSQL.LOCAL';

如果 MySQL 必须为此帐户构造 UPN，例如获取或验证票证（TGT 或 ST），则通过组合帐户名（忽略任何主机名部分）和领域名来执行此操作。例如，从前述CREATE USER语句中得到的完整帐户名为'karl'@'%'。MySQL 从用户名部分karl（忽略主机名部分）和领域名MYSQL.LOCAL构造 UPN，以生成karl@MYSQL.LOCAL。

注意

请注意，当创建使用authentication_kerberos进行身份验证的帐户时，CREATE USER语句不包括 UPN 领域作为用户名的一部分。而是在BY子句中指定领域（在本例中为MYSQL.LOCAL）作为认证字符串。这与使用 GSSAPI/Kerberos 认证方法的authentication_ldap_sasl SASL LDAP 认证插件创建帐户不同。对于这样的帐户，CREATE USER语句包括 UPN 领域作为用户名的一部分。请参阅创建使用 GSSAPI/Kerberos 进行 LDAP 认证的 MySQL 帐户。

设置好帐户后，客户端可以使用它连接到 MySQL 服务器。该过程取决于客户端主机是运行 Linux 还是 Windows，如下面的讨论所示。

使用authentication_kerberos受到限制，即不支持具有相同用户部分但不同领域部分的 UPN。例如，您不能创建对应于以下这两个 UPN 的 MySQL 帐户：

kate@MYSQL.LOCAL
kate@EXAMPLE.COM

两个 UPN 都具有kate的用户部分，但领域部分不同（MYSQL.LOCAL与EXAMPLE.COM）。这是不允许的。

使用 MySQL 帐户连接到 MySQL 服务器

设置了使用 Kerberos 进行身份验证的 MySQL 帐户后，客户端可以按以下方式连接到 MySQL 服务器：

  1. 使用用户主体名称（UPN）和其密码对 Kerberos 进行身份验证，以获取票据授予票据（TGT）。

  2. 使用 TGT 获取 MySQL 的服务票据（ST）。

  3. 通过呈现 MySQL ST 向 MySQL 服务器进行身份验证。

第一步（向 Kerberos 进行身份验证）可以通过各种方式执行：

  • 在连接到 MySQL 之前：

    • 在 Linux 或在GSSAPI模式下的 Windows 上，调用kinit以获取 TGT 并将其保存在 Kerberos 凭据缓存中。

    • 在SSPI模式下的 Windows 中，认证可能已在登录时完成，这会将登录用户的 TGT 保存在 Windows 内存缓存中。kinit不会被使用，也没有 Kerberos 缓存。

  • 连接到 MySQL 时，客户端程序本身可以获取 TGT，如果它可以确定所需的 Kerberos UPN 和密码：

    • 信息可以来自诸如命令选项或操作系统之类的来源。

    • 在 Linux 上，客户端还可以使用 keytab 文件或/etc/krb5.conf配置文件。在GSSAPI模式下的 Windows 客户端使用配置文件。在SSPI模式下��Windows 客户端两者都不使用。

连接到 MySQL 服务器的客户端命令的详细信息因 Linux 和 Windows 而异，因此每个主机类型都会单独讨论，但这些命令属性适用于所有主机类型：

  • 每个显示的命令都包括以下选项，但在某些情况下可以省略每个选项：

    • --default-auth选项指定客户端端身份验证插件的名称（authentication_kerberos_client）。当指定--user选项时，可以省略此选项，因为在这种情况下，MySQL 可以从 MySQL 服务器发送的用户帐户信息中确定插件。

    • --plugin-dir选项指示客户端程序authentication_kerberos_client插件的位置。如果插件安装在默认（编译内）位置，则可以省略此选项。

  • 命令还应包括任何其他选项，如--host或--port，以指定连接到哪个 MySQL 服务器。

  • 每个命令都要单独输入一行。如果命令包括--password选项以获取密码，请在提示时输入与 MySQL 用户关联的 Kerberos UPN 的密码。

Linux 客户端连接命令

在 Linux 上，连接到 MySQL 服务器的适当客户端命令因命令是使用来自 Kerberos 缓存的 TGT 进行身份验证，还是基于 MySQL 用户名和 UPN 密码的命令选项而异：

  • 在调用 MySQL 客户端程序之前，客户端用户可以独立于 MySQL 从 KDC 获取 TGT。例如，客户端用户可以使用kinit通过提供 Kerberos 用户主体名称和主体密码来对 Kerberos 进行身份验证：

    $> kinit karl@MYSQL.LOCAL
Password for karl@MYSQL.LOCAL: *(enter password here)*

    生成的 UPN 的 TGT 被缓存，并可供其他了解 Kerberos 的应用程序使用，例如使用客户端端 Kerberos 认证插件的程序。在这种情况下，调用客户端时不指定用户名称或密码选项：

    mysql
  --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*

    客户端插件在缓存中找到 TGT，使用它获取 MySQL ST，并使用 ST 对 MySQL 服务器进行身份验证。

    正如刚才描述的，当 UPN 的 TGT 被缓存时，在客户端命令中不需要用户名称和密码选项。如果命令仍然包含它们，则处理如下：

    • 此命令包括一个用户名选项：

      mysql
  --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --user=karl

      在这种情况下，如果选项指定的用户名与 TGT 中的 UPN 的用户名部分不匹配，则身份验证将失败。

    • 此命令包括一个密码选项，在提示时输入：

      mysql
  --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --password

      在这种情况下，客户端端插件会忽略密码。因为身份验证是基于 TGT 的，即使用户提供的密码不正确，也可以成功*。因此，如果找到导致密码被忽略的有效 TGT，插件会产生警告。

  • 如果 Kerberos 缓存中不包含 TGT，则客户端端 Kerberos 认证插件本身可以从 KDC 获取 TGT。使用 MySQL 用户名和密码的选项调用客户端，然后在提示时输入 UPN 密码：

    mysql --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --user=karl
  --password

    客户端端的 Kerberos 认证插件将用户名称（karl）与用户帐户中指定的领域（MYSQL.LOCAL）结合起来构建 UPN（karl@MYSQL.LOCAL）。客户端插件使用 UPN 和密码获取 TGT，使用 TGT 获取 MySQL ST，并使用 ST 对 MySQL 服务器进行身份验证。

    或者，假设 Kerberos 缓存中不包含 TGT，并且命令指定了密码选项但没有用户名称选项：

    mysql --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --password

    客户端端 Kerberos 认证插件使用操作系统登录名作为 MySQL 用户名。它将该用户名与用户的 MySQL 帐户中的领域结合起来构建 UPN。客户端插件使用 UPN 和密码获取 TGT，使用 TGT 获取 MySQL ST，并使用 ST 对 MySQL 服务器进行身份验证。

如果您不确定是否存在 TGT，可以使用klist进行检查。

注意

当客户端端 Kerberos 认证插件本身获取 TGT 时，客户端用户可能不希望 TGT 被重用。如用于 Kerberos 认证的客户端配置参数中所述，本地/etc/krb5.conf文件可用于使客户端插件在完成后销毁 TGT。

SSPI 模式下 Windows 客户端的连接命令

在 Windows 上，使用默认的客户端插件选项（SSPI），连接到 MySQL 服务器的适当客户端命令取决于命令是基于 MySQL 用户名和 UPN 密码的命令选项进行身份验证，还是使用 Windows 内存缓存中的 TGT。有关 Windows 上 GSSAPI 模式的详细信息，请参阅 GSSAPI 模式下 Windows 客户端的命令。

一个命令可以明确指定 MySQL 用户名和 UPN 密码的选项，也可以省略这些选项：

  • 此命令包括 MySQL 用户名和 UPN 密码的选项：

    mysql --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --user=karl
  --password

    客户端端的 Kerberos 认证插件将用户名称（karl）和用户帐户中指定的领域（MYSQL.LOCAL）结合起来构建 UPN（karl@MYSQL.LOCAL）。客户端插件使用 UPN 和密码获取 TGT，使用 TGT 获取 MySQL ST，并使用 ST 对 MySQL 服务器进行身份验证。

    Windows 内存缓存中的任何信息都将被忽略；用户名称和密码选项值优先。

  • 此命令包括 UPN 密码选项，但不包括 MySQL 用户名选项：

    mysql
  --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --password

    客户端端的 Kerberos 认证插件使用已登录用户名称作为 MySQL 用户名，并将该用户名与用户 MySQL 帐户中的领域结合起来构建 UPN。客户端插件使用 UPN 和密码获取 TGT，使用 TGT 获取 MySQL ST，并使用 ST 对 MySQL 服务器进行身份验证。

  • 此命令不包括 MySQL 用户名或 UPN 密码的选项：

    mysql
  --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*

    客户端端插件从 Windows 内存缓存中获取 TGT，使用 TGT 获取 MySQL ST，并使用 ST 对 MySQL 服务器进行身份验证。

    这种方法要求客户端主机是 Windows Server Active Directory (AD) 域的一部分。如果不是这种情况，请通过手动输入 AD 服务器和领域作为 DNS 服务器和前缀来帮助 MySQL 客户端发现 AD 域的 IP 地址：

    1. 启动 console.exe 并选择网络和共享中心。

    2. 从网络和共享中心窗口的侧边栏中，选择更改适配器设置。

    3. 在网络连接窗口中，右键单击要配置的网络或 VPN 连接，然后选择属性。

    4. 从网络选项卡中，找到并单击 Internet 协议版本 4 (TCP/IPv4)，然后单击属性。

    5. 在 Internet 协议版本 4 (TCP/IPv4) 属性对话框中，单击高级。打开高级 TCP/IP 设置对话框。

    6. 从 DNS 选项卡中，将 Active Directory 服务器和领域添加为 DNS 服务器和前缀。

  • 此命令包括 MySQL 用户名选项，但不包括 UPN 密码选项：

    mysql
  --default-auth=authentication_kerberos_client
  --plugin-dir=*path/to/plugin/directory*
  --user=karl

    客户端端的 Kerberos 身份验证插件将由用户名称选项指定的名称与登录用户名进行比较。如果名称相同，则插件使用登录用户的 TGT 进行身份验证。如果名称不同，则身份验证失败。

在 GSSAPI 模式下的 Windows 客户端连接命令

在 Windows 上，客户端用户必须明确使用 plugin_authentication_kerberos_client_mode 插件选项指定 GSSAPI 模式，以通过 MIT Kerberos 库启用支持。默认模式为 SSPI（请参阅 SSPI 模式下 Windows 客户端的命令）。

可以指定 GSSAPI 模式：

  • 在运行 Windows 主机上始终从 MIT Kerberos 缓存中检索或放置票证。

    [mysql]
plugin_authentication_kerberos_client_mode=GSSAPI

    或：

    [mysql]
plugin-authentication-kerberos-client-mode=GSSAPI

  • 在运行时从命令行使用 mysql 或 mysqldump 客户端程序。例如，以下命令（带有下划线或破折号）使 mysql 通过 MIT Kerberos 库连接到 Windows 上的服务器。

    mysql *[connection-options]* --plugin_authentication_kerberos_client_mode=GSSAPI

    或：

    mysql *[connection-options]* --plugin-authentication-kerberos-client-mode=GSSAPI

  • 客户端用户可以从 MySQL Workbench 和一些 MySQL 连接器中选择 GSSAPI 模式。在运行 Windows 的客户端主机上，您可以覆盖默认位置：

    • 通过设置 KRB5_CONFIG 环境变量来配置 Kerberos 配置文件。

    • 使用 KRB5CCNAME 环境变量设置默认凭据缓存名称（例如，KRB5CCNAME=DIR:/mydir/）。

    有关特定客户端插件信息，请参阅 dev.mysql.com/doc/ 文档。

连接到 MySQL 服务器的适当客户端命令因命令是使用 MIT Kerberos 缓存中的 TGT 进行身份验证，还是基于 MySQL 用户名称和 UPN 密码的命令选项而异。在 Windows 上通过 MIT 库支持的 GSSAPI 与 Linux 上的 GSSAPI 类似（请参阅 Linux 客户端命令），但有以下例外：

  • 在运行 MySQL 客户端程序之前，在选项文件中。插件变量名称可以使用下划线或破折号：

  • kinit 在 Windows 上以具有狭窄权限和特定角色的功能帐户运行。客户端用户不知道 kinit 密码。有关概述，请参阅 docs.oracle.com/en/java/javase/11/tools/kinit.html。

  • 如果客户端用户提供密码，MIT Kerberos 库在 Windows 上决定是使用密码还是依赖现有票证。

  • 描述在用于 Kerberos 认证的客户端配置参数中的destroy_tickets参数不受支持，因为 Windows 上的 MIT Kerberos 库不支持所需的 API 成员（get_profile_boolean）来从配置文件中读取其值。

用于 Kerberos 认证的客户端配置参数

本节仅适用于运行 Linux 的客户端主机，不适用于运行 Windows 的客户端主机。

注意

运行 Windows 的客户端主机，将authentication_kerberos_client客户端 Kerberos 插件设置为GSSAPI模式支持客户端配置参数，但 Windows 上的 MIT Kerberos 库不支持本节中描述的destroy_tickets参数。

如果在 MySQL 客户端应用程序调用时不存在有效的票证授予票证（TGT），应用程序本身可以获取并缓存 TGT。如果在 Kerberos 认证过程中，客户端应用程序导致 TGT 被缓存，任何添加的 TGT 在不再需要时可以通过设置适当的配置参数销毁。

authentication_kerberos_client客户端 Kerberos 插件读取本地的/etc/krb5.conf文件。如果该文件丢失或无法访问，将会出现错误。假设文件可访问，它可以包含一个可选的[appdefaults]部分，提供插件使用的信息。将信息放在该部分的mysql部分内。例如：

[appdefaults]
 mysql = {
 destroy_tickets = true
  }

客户端插件在mysql部分识别这些参数：

  • destroy_tickets值指示客户端插件在获取和使用 TGT 后是否销毁 TGT。默认情况下，destroy_tickets为false，但可以设置为true以避免 TGT 重用。（此设置仅适用于由客户端插件创建的 TGT，不适用于由其他插件或外部 MySQL 创建的 TGT。）

在客户端主机上，可以使用客户端 keytab 文件来获取 TGT 和 TS 而无需提供密码。有关 keytab 文件的信息，请参阅web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html。

Kerberos 认证调试

AUTHENTICATION_KERBEROS_CLIENT_LOG环境变量用于启用或禁用 Kerberos 认证的调试输出。

注意

尽管AUTHENTICATION_KERBEROS_CLIENT_LOG中包含CLIENT，但同一环境变量也适用于服务器端插件以及客户端插件。

在服务器端，允许的值为 0（关闭）和 1（开启）。日志消息写入服务器错误日志，受服务器错误日志详细级别的影响。例如，如果您正在使用基于优先级的日志过滤，log_error_verbosity 系统变量控制详细程度，如第 7.4.2.5 节“基于优先级的错误日志过滤（log_filter_internal）”中所述。

在客户端，允许的值为 1 到 5，并写入标准错误输出。以下表格显示了每个日志级别值的含义。

日志级别 含义
1 或未设置 无日志记录
2 错误消息
3 错误和警告消息
4 错误、警告和信息消息
5 错误、警告、信息和调试消息

原文：dev.mysql.com/doc/refman/8.0/en/no-login-pluggable-authentication.html

8.4.1.9 无登录可插拔认证

mysql_no_login 服务器端认证插件阻止所有使用它的账户的客户端连接。此插件的用例包括：

  • 必须能够执行存储过程和视图并具有提升权限，而不会将这些权限暴露给普通用户的账户。

  • 代理账户永远不应允许直接登录，而是仅通过代理账户访问的账户。

以下表显示了插件和库文件名。文件名后缀可能因您的系统而异。该文件必须位于由 plugin_dir 系统变量命名的目录中。

表 8.25 无登录认证的插件和库名称

插件或文件 插件或文件名
服务器端插件 mysql_no_login
客户端插件 无
库文件 mysql_no_login.so

以下各节提供了特定于无登录可插拔认证的安装和使用信息：

  • 安装无登录可插拔认证

  • 卸载无登录可插拔认证

  • 使用无登录可插拔认证

有关 MySQL 中可插拔认证的一般信息，请参阅第 8.2.17 节，“可插拔认证”。有关代理用户信息，请参阅第 8.2.19 节，“代理用户”。

安装无登录可插拔认证

本节描述了如何安装无登录认证插件。有关安装插件的一般信息，请参阅第 7.6.1 节，“安装和卸载插件”。

要使服务器可用，插件库文件必须位于 MySQL 插件目录中（由 plugin_dir 系统变量命名的目录）。如有必要，请通过在服务器启动时设置 plugin_dir 的值来配置插件目录位置。

插件库文件基本名称为 mysql_no_login。文件名后缀因平台而异（例如，对于 Unix 和类 Unix 系统，为 .so，对于 Windows 为 .dll）。

要在服务器启动时加载插件，请使用--plugin-load-add选项命名包含插件的库文件。使用此插件加载方法，选项必须在每次服务器启动时给出。例如，将这些行放入服务器的my.cnf文件中，根据需要调整您平台的.so后缀：

[mysqld]
plugin-load-add=mysql_no_login.so

修改my.cnf后，请重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用此语句，根据需要调整您平台的.so后缀：

INSTALL PLUGIN mysql_no_login SONAME 'mysql_no_login.so';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

要验证插件安装，请检查信息模式PLUGINS表或使用SHOW PLUGINS语句（参见 Section 7.6.2, “Obtaining Server Plugin Information”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE '%login%';
+----------------+---------------+
| PLUGIN_NAME    | PLUGIN_STATUS |
+----------------+---------------+
| mysql_no_login | ACTIVE        |
+----------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断消息。

要将 MySQL 帐户与无登录插件关联，请参阅使用无登录可插拔认证。

卸载无登录可插拔认证

卸载无登录认证插件的方法取决于您安装它的方式：

  • 如果您在服务器启动时使用--plugin-load-add选项安装了插件，请在不带该选项的情况下重新启动服务器。

  • 如果您在运行时使用INSTALL PLUGIN语句安装了插件，则在服务器重新启动时仍然保留安装。要卸载它，请使用UNINSTALL PLUGIN：

    UNINSTALL PLUGIN mysql_no_login;
使用无登录可插拔认证

本节描述如何使用无登录认证插件防止帐户被用于从 MySQL 客户端程序连接到服务器。假定服务器正在运行，并启用了无登录插件，如安装无登录可插拔认证中所述。

在CREATE USER语句的IDENTIFIED WITH子句中引用无登录认证插件时，请使用名称mysql_no_login。

使用mysql_no_login进行身份验证的账户可用作存储过程和视图对象的DEFINER。如果此类对象定义还包括SQL SECURITY DEFINER，则将以该账户的权限执行。数据库管理员可以利用此行为提供仅通过受控接口公开的机密或敏感数据的访问。

以下示例说明了这些原则。它定义了一个不允许客户端连接的账户，并将其与一个仅公开mysql.user系统表的某些列的视图关联起来：

CREATE DATABASE nologindb;
CREATE USER 'nologin'@'localhost'
  IDENTIFIED WITH mysql_no_login;
GRANT ALL ON nologindb.*
  TO 'nologin'@'localhost';
GRANT SELECT ON mysql.user
  TO 'nologin'@'localhost';
CREATE DEFINER = 'nologin'@'localhost'
  SQL SECURITY DEFINER
  VIEW nologindb.myview
  AS SELECT User, Host FROM mysql.user;

要为普通用户提供对视图的受保护访问，请执行以下操作：

GRANT SELECT ON nologindb.myview
  TO 'ordinaryuser'@'localhost';

现在普通用户可以使用视图访问它呈现的有限信息：

SELECT * FROM nologindb.myview;

用户尝试访问视图中未公开的列或未被授权访问的用户尝试从视图中选择将导致错误。

注意

由于nologin账户不能直接使用，因此必须由具有创建对象和设置DEFINER值所需特权的root或类似账户执行设置对象的操作。

mysql_no_login插件在代理场景中也很有用。（有关代理涉及的概念讨论，请参阅第 8.2.19 节，“代理用户”。）使用mysql_no_login进行身份验证的账户可用作代理账户的被代理用户：

-- create proxied account
CREATE USER 'proxied_user'@'localhost'
  IDENTIFIED WITH mysql_no_login;
-- grant privileges to proxied account
GRANT ...
  ON ...
  TO 'proxied_user'@'localhost';
-- permit proxy_user to be a proxy account for proxied account
GRANT PROXY
  ON 'proxied_user'@'localhost'
  TO 'proxy_user'@'localhost';

这使客户端可以通过代理账户(proxy_user)访问 MySQL，但不能通过直接连接作为被代理用户(proxied_user)绕过代理机制。使用proxy_user账户连接的客户端具有proxied_user账户的权限，但proxied_user本身不能用于连接。

若要了解有关保护代理账户免受直接使用的替代方法，请参阅防止直接登录到代理账户。

原文：dev.mysql.com/doc/refman/8.0/en/socket-pluggable-authentication.html

8.4.1.10 套接字对等凭证可插拔认证

服务器端auth_socket认证插件用于认证通过 Unix 套接字文件从本地主机连接的客户端。该插件使用SO_PEERCRED套接字选项来获取运行客户端程序的用户信息。因此，该插件只能在支持SO_PEERCRED选项的系统上使用，例如 Linux。

此插件的源代码可作为一个相对简单的示例，演示如何编写一个可加载的认证插件。

以下表显示了插件和库文件名。文件必须位于由plugin_dir系统变量命名的目录中。

表 8.26 套接字对等凭证认证的插件和库名称

插件或文件 插件或文件名
服务器端插件 auth_socket
客户端插件 无，请参阅讨论
库文件 auth_socket.so

以下各节提供了特定于套接字可插拔认证的安装和使用信息：

  • 安装套接字可插拔认证

  • 卸载套接字可插拔认证

  • 使用套接字可插拔认证

有关 MySQL 中可插拔认证的一般信息，请参阅第 8.2.17 节，“可插拔认证”。

安装套接字可插拔认证

本节描述了如何安装套接字认证插件。有关安装插件的一般信息，请参阅第 7.6.1 节，“安装和卸载插件”。

要使服务器可用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如有必要，通过在服务器启动时设置plugin_dir的值来配置插件目录位置。

要在服务器启动时加载插件，请使用--plugin-load-add选项来命名包含插件的库文件。使用这种插件加载方法，选项必须在每次服务器启动时给出。例如，将以下行放入服务器的my.cnf文件中：

[mysqld]
plugin-load-add=auth_socket.so

修改my.cnf后，重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用此语句：

INSTALL PLUGIN auth_socket SONAME 'auth_socket.so';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

要验证插件安装情况，请检查信息模式PLUGINS表，或使用SHOW PLUGINS语句（参见第 7.6.2 节，“获取服务器插件信息”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE '%socket%';
+-------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+-------------+---------------+
| auth_socket | ACTIVE        |
+-------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断消息。

要将 MySQL 帐户与套接字插件关联，请参阅使用套接字可插拔认证。

卸载套接字可插拔认证

卸载套接字可插拔认证插件的方法取决于您安装插件的方式：

  • 如果您在服务器启动时使用--plugin-load-add选项安装了插件，请在不带该选项的情况下重新启动服务器。

  • 如果您在运行时使用INSTALL PLUGIN语句安装了插件，则在服务器重新启动时仍然安装。要卸载它，请使用UNINSTALL PLUGIN：

    UNINSTALL PLUGIN auth_socket;
使用套接字可插拔认证

套接字插件检查套接字用户名（操作系统用户名）是否与客户端程序指定给服务器的 MySQL 用户名匹配。如果名称不匹配，则插件将检查套接字用户名是否与mysql.user系统表行的authentication_string列中指定的名称匹配。如果找到匹配项，则插件允许连接。authentication_string值可以使用CREATE USER或ALTER USER中的IDENTIFIED ...AS子句指定。

假设为一个名为valerie的操作系统用户创建了一个用于通过套接字文件从本地主机进行认证的 MySQL 帐户，该用户将通过auth_socket插件进行认证：

CREATE USER 'valerie'@'localhost' IDENTIFIED WITH auth_socket;

如果本地主机上的用户使用登录名 stefanie 调用 mysql 并使用选项 --user=valerie 通过套接字文件连接，服务器将使用 auth_socket 对客户端进行身份验证。插件确定 --user 选项值 (valerie) 与客户端用户名 (stephanie) 不同，因此拒绝连接。如果名为 valerie 的用户尝试同样的操作，插件会发现用户名和 MySQL 用户名都是 valerie，允许连接。但是，即使是 valerie，如果使用不同的协议（如 TCP/IP）进行连接，插件也会拒绝连接。

要允许 valerie 和 stephanie 操作系统用户通过使用账户的套接字文件连接访问 MySQL，可以通过两种方式实现：

  • 在创建账户时分别命名这两个用户，一个在 CREATE USER 后面，另一个在认证字符串中：

    CREATE USER 'valerie'@'localhost' IDENTIFIED WITH auth_socket AS 'stephanie';

  • 如果您已经使用 CREATE USER 为单个用户创建了账户，可以使用 ALTER USER 来添加第二个用户：

    CREATE USER 'valerie'@'localhost' IDENTIFIED WITH auth_socket;
ALTER USER 'valerie'@'localhost' IDENTIFIED WITH auth_socket AS 'stephanie';

要访问账户，valerie 和 stephanie 在连接时都需要指定 --user=valerie。

原文：dev.mysql.com/doc/refman/8.0/en/fido-pluggable-authentication.html

8.4.1.11 FIDO 可插拔认证

注意

FIDO 可插拔认证是包含在 MySQL Enterprise Edition 中的扩展，这是一款商业产品。要了解更多关于商业产品的信息，请参见 www.mysql.com/products/。

MySQL Enterprise Edition 支持一种认证方法，允许用户使用 FIDO 认证对 MySQL 服务器进行认证。从 MySQL 8.0.35 开始，此认证方法已被弃用，并可能在未来的 MySQL 版本中被移除。为了获得类似的功能，请考虑升级到 MySQL 8.2（或更高版本），用户可以使用 WebAuthn 认证 对 MySQL 服务器进行认证。在进行升级之前，您需要了解 MySQL 创新和长期支持（LTS）版本的发布模型。有关更多信息，请参见 Section 3.2, “升级路径”。

FIDO 代表快速身份在线，提供了不需要使用密码的认证标准。

FIDO 可插拔认证提供以下功能：

  • FIDO 可以使用智能卡、安全密钥和生物识别读卡器等设备对 MySQL 服务器进行认证。

  • 因为认证可以通过除提供密码外的其他方式进行，所以 FIDO 实现了无密码认证。

  • 另一方面，设备认证通常与密码认证一起使用，因此 FIDO 认证可用于使用多因素认证的 MySQL 帐户；参见 Section 8.2.18, “多因素认证”。

以下表格显示了插件和库文件的名称。文件名后缀可能因系统而异。Unix 和类 Unix 系统通常使用 .so，Windows 系统使用 .dll。文件必须位于由 plugin_dir 系统变量指定的目录中。有关安装信息，请参见 安装 FIDO 可插拔认证。

表 8.27 FIDO 认证的插件和库名称

插件或文件 插件或文件名
服务器端插件 authentication_fido
客户端插件 authentication_fido_client
库文件 authentication_fido.so，authentication_fido_client.so

注意

在使用服务器端或客户端 FIDO 认证插件的系统上必须可用 libfido2 库。如果主机上有多个 FIDO 设备，则 libfido2 库决定用于注册和认证的设备。libfido2 库不提供设备选择功能。

服务器端的 FIDO 身份验证插件仅包含在 MySQL 企业版中。它不包含在 MySQL 社区发行版中。客户端插件包含在所有发行版中，包括社区发行版，这使得来自任何发行版的客户端都可以连接到加载了服务器端插件的服务器。

以下各节提供了特定于 FIDO 可插拔认证的安装和使用信息：

  • 安装 FIDO 可插拔认证

  • 使用 FIDO 认证

  • FIDO 免密码认证

  • FIDO 设备注销

  • MySQL 用户 FIDO 认证的工作原理

有关 MySQL 中可插拔认证的一般信息，请参见第 8.2.17 节，“可插拔认证”。

安装 FIDO 可插拔认证

本节描述了如何安装服务器端的 FIDO 身份验证插件。有关安装插件的一般信息，请参见第 7.6.1 节，“安装和卸载插件”。

要使服务器可用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如果需要，通过在服务器启动时设置plugin_dir的值来配置插件目录位置。

服务器端插件库文件基本名称为authentication_fido。文件名后缀因平台而异（例如，对于 Unix 和类 Unix 系统，为.so，对于 Windows 为.dll）。

要在服务器启动时加载插件，请使用--plugin-load-add选项命名包含插件的库文件。使用此插件加载方法，选项必须在每次服务器启动时给出。

要加载插件，请在您的my.cnf文件中添加类似以下行，根据需要调整.so后缀以适应您的平台：

[mysqld]
plugin-load-add=authentication_fido.so

修改my.cnf后，重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用此语句，根据需要调整.so后缀以适应您的平台：

INSTALL PLUGIN authentication_fido
  SONAME 'authentication_fido.so';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

要验证插件安装，请检查信息模式PLUGINS表，或使用SHOW PLUGINS语句（参见 Section 7.6.2，“获取服务器插件信息”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME = 'authentication_fido';
+---------------------+---------------+
| PLUGIN_NAME         | PLUGIN_STATUS |
+---------------------+---------------+
| authentication_fido | ACTIVE        |
+---------------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断消息。

要将 MySQL 帐户与 FIDO 认证插件关联，请参见使用 FIDO 认证。

使用 FIDO 认证

FIDO 认证通常用于多因素认证的背景下（参见 Section 8.2.18，“多因素认证”）。本节展示了如何将基于 FIDO 设备的认证纳入多因素帐户中，使用authentication_fido插件。

在以下讨论中假定服务器正在运行，并启用了服务器端 FIDO 认证插件，如安装 FIDO 可插拔认证中所述，并且客户端 FIDO 插件在客户端主机的插件目录中可用。

注意

在 Windows 上，只有当客户端进程以具有管理员权限的用户身份运行时，FIDO 认证才能正常工作。

还假定 FIDO 认证与非 FIDO 认证一起使用（这意味着 2FA 或 3FA 帐户）。FIDO 也可以单独使用，创建以无密码方式进行身份验证的 1FA 帐户。在这种情况下，设置过程略有不同。有关说明，请参见 FIDO 无密码认证。

配置为使用authentication_fido插件的帐户与 FIDO 设备关联。因此，在进行 FIDO 认证之前需要进行一次设备注册步骤。设备注册过程具有以下特点：

  • 与帐户关联的任何 FIDO 设备必须在使用帐户之前注册。

  • 注册要求客户端主机上有一个 FIDO 设备，否则注册将失败。

  • 用户在注册过程中收到提示时，应执行适当的 FIDO 设备操作（例如，触摸设备或进行生物识别扫描）。

  • 要执行设备注册，客户端用户必须调用mysql客户端程序或 MySQL Shell，并指定--fido-register-factor选项以指定正在注册设备的因素或因素。例如，如果帐户设置为将 FIDO 用作第二身份验证因素，则用户使用--fido-register-factor=2选项调用mysql。

  • 如果用户帐户配置为将authentication_fido插件设置为第二或第三因素，则在注册步骤可以继续之前，所有前面因素的身份验证必须成功。

  • 服务器根据用户帐户中的信息知道 FIDO 设备是否需要注册或已经注册。当客户端程序连接时，如果设备必须注册，服务器会将客户端会话置于沙盒模式，以便在执行其他操作之前必须进行注册。用于 FIDO 设备注册的沙盒模式类似于处理过期密码的模式。请参阅第 8.2.16 节，“服务器处理过期密码”。

  • 在沙盒模式下，除了ALTER USER语句之外，不允许使用其他语句。注册是通过此语句的形式执行的。当使用--fido-register-factor选项调用时，mysql客户端会生成执行注册所需的ALTER USER语句。注册完成后，服务器会将会话从沙盒模式切换出来，客户端可以正常进行操作。有关生成的ALTER USER语句的信息，请参考--fido-register-factor的描述。

  • 当为帐户执行设备注册后，服务器会更新该帐户的mysql.user系统表行，以更新设备注册状态并存储公钥和凭证 ID。

  • 只能由帐户指定的用户执行注册步骤。如果一个用户尝试为另一个用户执行注册，则会出现错误。

  • 用户在注册和身份验证过程中应使用相同的 FIDO 设备。如果在客户端主机上注册了 FIDO 设备后，重置设备或插入不同设备，则身份验证将失败。在这种情况下，必须取消与帐户关联的设备注册，并重新进行注册。

假设您希望一个账户首先使用 caching_sha2_password 插件进行认证，然后再使用 authentication_fido 插件进行认证。可以使用类似以下语句创建多因素账户：

CREATE USER 'u2'@'localhost'
  IDENTIFIED WITH caching_sha2_password
    BY '*sha2_password*'
  AND IDENTIFIED WITH authentication_fido;

要连接，提供因素 1 密码以满足该因素的认证，并将 --fido-register-factor 设置为因素 2 以启动 FIDO 设备的注册。

$> mysql --user=u2 --password1 --fido-register-factor=2
Enter password: *(enter factor 1 password)*

一旦因素 1 密码被接受，客户端会进入沙盒模式，以便为因素 2 进行设备注册。在注册过程中，您将被提示执行适当的 FIDO 设备操作，例如触摸设备或进行生物识别扫描。

当注册过程完成时，连接到服务器是允许的。

注意

在注册后，无论账户的认证链中是否存在额外的认证因素，连接到服务器都是允许的。例如，如果前面的示例中的账户定义了第三个认证因素（使用非 FIDO 认证），则在成功注册后连接将被允许，而无需对第三个因素进行认证。然而，后续的连接将需要对所有三个因素进行认证。

FIDO 无密码认证

本节描述了如何单独使用 FIDO 创建支持无密码认证的 1FA 账户。在这种情况下，“无密码”意味着认证会发生，但使用的是除密码之外的方法，例如安全密钥或生物识别扫描。这并不是指使用密码为空的基于密码的认证插件的账户。那种“无密码”是完全不安全的，不建议使用。

使用 authentication_fido 插件实现无密码认证时，需要满足以下先决条件：

  • 创建无密码认证账户的用户需要PASSWORDLESS_USER_ADMIN权限，以及CREATE USER权限。

  • authentication_policy 值的第一个元素必须是星号（*），而不是插件名称。例如，默认的 authentication_policy 值支持启用无密码认证，因为第一个元素是星号：

    authentication_policy='*,,'

    有关配置 authentication_policy 值的信息，请参阅配置多因素认证策略。

要将authentication_fido用作免密码认证方法，必须将帐户创建为将authentication_fido作为第一因素认证方法。还必须为第一因素指定INITIAL AUTHENTICATION IDENTIFIED BY子句（不支持第 2 或第 3 因素）。此子句指定 FIDO 设备注册时将使用随机生成的还是用户指定的密码。设备注册后，服务器会删除密码并修改帐户，使authentication_fido成为唯一的认证方法（1FA 方法）。

所需的CREATE USER语法如下：

CREATE USER *user*
  IDENTIFIED WITH authentication_fido
  INITIAL AUTHENTICATION IDENTIFIED BY {RANDOM PASSWORD | '*auth_string*'};

以下示例使用RANDOM PASSWORD语法：

mysql> CREATE USER 'u1'@'localhost'
         IDENTIFIED WITH authentication_fido
         INITIAL AUTHENTICATION IDENTIFIED BY RANDOM PASSWORD;
+------+-----------+----------------------+-------------+
| user | host      | generated password   | auth_factor |
+------+-----------+----------------------+-------------+
| u1   | localhost | 9XHK]M{l2rnD;VXyHzeF |           1 |
+------+-----------+----------------------+-------------+

要执行注册，用户必须使用与INITIAL AUTHENTICATION IDENTIFIED BY子句关联的密码对服务器进行身份验证，可以是随机生成的密码，也可以是'*auth_string*'值。如果帐户是刚刚创建的，用户执行此命令并在提示处粘贴先前生成的随机密码（9XHK]M{l2rnD;VXyHzeF）：

$> mysql --user=u1 --password --fido-register-factor=2
Enter password:

选项--fido-register-factor=2用于表示INITIAL AUTHENTICATION IDENTIFIED BY子句当前充当第一因素认证方法。因此，用户必须使用第二因素提供临时密码。成功注册后，服务器将删除临时密码并修改mysql.user系统表中的帐户条目，将authentication_fido列为唯一（1FA）认证方法。

创建无密码认证帐户时，重要的是在CREATE USER语句中包含INITIAL AUTHENTICATION IDENTIFIED BY子句。服务器将接受没有子句的语句，但由于没有办法连接到服务器注册设备，因此生成的帐户无法使用。假设您执行了这样的语句：

CREATE USER 'u2'@'localhost'
  IDENTIFIED WITH authentication_fido;

后续尝试使用帐户连接将失败，如下所示：

$> mysql --user=u2 --skip-password
Failed to open FIDO device.
ERROR 1 (HY000): Unknown MySQL error

注意

使用通用第二因素（U2F）协议实现无密码认证，该协议不支持设置要注册的设备的 PIN 等其他安全措施。因此，设备持有者有责任确保设备以安全方式处理。

FIDO 设备注销

可以注销与 MySQL 帐户关联的 FIDO 设备。在多种情况下，这可能是可取或必要的：

  • 要用不同设备替换 FIDO 设备。必须注销先前的设备并注册新设备。

    在这种情况下，帐户所有者或任何具有CREATE USER权限的用户都可以注销设备。帐户所有者可以注册新设备。

  • FIDO 设备被重置或丢失。直到当前设备被注销并执行新的注册为止，认证尝试将失败。

    在这种情况下，由于账户所有者无法进行身份验证，因此无法注销当前设备，必须联系 DBA（或任何具有CREATE USER 权限的用户）来执行此操作。然后账户所有者可以重新注册重置的设备或注册新设备。

注销 FIDO 设备可以由账户所有者或任何具有CREATE USER 权限的用户执行。使用以下语法：

ALTER USER *user* {2 | 3} FACTOR UNREGISTER;

要重新注册设备或执行新的注册，请参考使用 FIDO 认证 中的说明。

FIDO 认证 MySQL 用户的工作原理

本节概述了 MySQL 和 FIDO 如何共同工作以对 MySQL 用户进行认证。有关如何设置 MySQL 账户以使用 FIDO 认证插件的示例，请参见使用 FIDO 认证。

使用 FIDO 认证的账户必须在连接到服务器之前执行初始设备注册步骤。设备注册后，认证可以继续进行。FIDO 设备注册过程如下：

  1. 服务器向客户端发送随机挑战、用户 ID 和依赖方 ID（唯一标识服务器），依赖方 ID 由authentication_fido_rp_id 系统变量定义。默认值为 MySQL。

  2. 客户端接收该信息并将其发送给客户端 FIDO 认证插件，后者再将其提供给 FIDO 设备。

  3. 用户执行适当的设备操作（例如，触摸设备或进行生物识别扫描）后，FIDO 设备生成公钥/私钥对、密钥句柄、X.509 证书和签名，然后返回给服务器。

  4. 服务器端 FIDO 认证插件验证签名。验证成功后，服务器将凭证 ID 和公钥存储在 mysql.user 系统表中。

注册成功后，FIDO 认证遵循以下流程：

  1. 服务器向客户端发送随机挑战、用户 ID、依赖方 ID 和凭证。

  2. 客户端将相同的信息发送给 FIDO 设备。

  3. FIDO 设备提示用户执行适当的设备操作，根据注册时所做的选择。

  4. 此操作解锁私钥并签署挑战。

  5. 签署的挑战返回给服务器。

  6. 服务器端 FIDO 认证插件使用公钥验证签名，并响应以指示认证成功或失败。

原文：dev.mysql.com/doc/refman/8.0/en/test-pluggable-authentication.html

8.4.1.12 测试可插拔认证

MySQL 包含一个测试插件，用于检查帐户凭据并将成功或失败记录到服务器错误日志中。这是一个可加载的插件（非内置），必须在使用之前安装。

测试插件源代码与服务器源代码分开，不同于内置的本机插件，因此可以作为一个相对简单的示例来演示如何编写可加载的认证插件。

注意

此插件旨在用于测试和开发目的，不适用于生产环境或暴露在公共网络上的服务器。

以下表格显示了插件和库文件的名称。文件名后缀可能在您的系统上有所不同。文件必须位于由plugin_dir系统变量命名的目录中。

表 8.28 测试认证的插件和库名称

插件或文件 插件或文件名
服务器端插件 test_plugin_server
客户端插件 auth_test_plugin
库文件 auth_test_plugin.so

以下各节提供了特定于测试可插拔认证的安装和使用信息：

  • 安装测试可插拔认证

  • 卸载测试可插拔认证

  • 使用测试可插拔认证

有关 MySQL 中可插拔认证的一般信息，请参见第 8.2.17 节，“可插拔认证”。

安装测试可插拔认证

本节描述了如何安装服务器端测试认证插件。有关安装插件的一般信息，请参见第 7.6.1 节，“安装和卸载插件”。

要被服务器使用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如有必要，在服务器启动时通过设置plugin_dir的值来配置插件目录位置。

要在服务器启动时加载插件，请使用--plugin-load-add选项命名包含插件的库文件。使用此插件加载方法，每次服务器启动时都必须提供该选项。例如，将这些行放入服务器的my.cnf文件中，根据需要调整.so后缀以适应您的平台：

[mysqld]
plugin-load-add=auth_test_plugin.so

修改my.cnf后，重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用此语句，根据需要调整.so后缀以适应您的平台：

INSTALL PLUGIN test_plugin_server SONAME 'auth_test_plugin.so';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

要验证插件安装，请检查 Information Schema PLUGINS表或使用SHOW PLUGINS语句（参见 Section 7.6.2, “Obtaining Server Plugin Information”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE '%test_plugin%';
+--------------------+---------------+
| PLUGIN_NAME        | PLUGIN_STATUS |
+--------------------+---------------+
| test_plugin_server | ACTIVE        |
+--------------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断消息。

要将 MySQL 帐户与测试插件关联，请参阅 Using Test Pluggable Authentication。

卸载测试可插拔认证

用于卸载测试认证插件的方法取决于您安装它的方式：

  • 如果您在服务器启动时使用--plugin-load-add选项安装了插件，请在不带该选项的情况下重新启动服务器。

  • 如果您使用INSTALL PLUGIN语句在运行时安装插件，则它将在服务器重新启动时保持安装状态。要卸载它，请使用UNINSTALL PLUGIN：

    UNINSTALL PLUGIN test_plugin_server;
使用测试可插拔认证

要使用测试认证插件，请创建一个帐户并在IDENTIFIED WITH子句中命名该插件：

CREATE USER 'testuser'@'localhost'
IDENTIFIED WITH test_plugin_server
BY '*testpassword*';

测试认证插件还需要创建代理用户，如下所示：

CREATE USER testpassword@localhost;
GRANT PROXY ON testpassword@localhost TO testuser@localhost;

然后在连接到服务器时为该帐户提供--user和--password选项。例如：

$> mysql --user=testuser --password
Enter password: *testpassword*

该插件从客户端接收的密码并将其与存储在mysql.user系统表中帐户行的authentication_string列中的值进行比较。如果两个值匹配，插件将authentication_string值作为新的有效用户 ID 返回。

你可以查看服务器错误日志，查看是否有关于身份验证成功的消息（注意密码被报告为“user”）：

[Note] Plugin test_plugin_server reported:
'successfully authenticated user *testpassword*'

原文：dev.mysql.com/doc/refman/8.0/en/pluggable-authentication-system-variables.html

8.4.1.13 可插拔认证系统变量

除非安装了适当的服务器端插件，否则这些变量不可用：

  • authentication_ldap_sasl 用于形式为 authentication_ldap_sasl_*xxx* 的系统变量

  • authentication_ldap_simple 用于形式为 authentication_ldap_simple_*xxx* 的系统变量

表 8.29 认证插件系统变量摘要

名称 命令行 选项文件 系统变量 状态变量 变量范围 动态
authentication_fido_rp_id 是 是 是 全局 是
authentication_kerberos_service_key_tab 是 是 是 全局 否
authentication_kerberos_service_principal 是 是 是 全局 是
authentication_ldap_sasl_auth_method_name 是 是 是 全局 是
authentication_ldap_sasl_bind_base_dn 是 是 是 全局 是
authentication_ldap_sasl_bind_root_dn 是 是 是 全局 是
authentication_ldap_sasl_bind_root_pwd 是 是 是 全局 是
authentication_ldap_sasl_ca_path 是 是 是 全局 是
authentication_ldap_sasl_group_search_attr 是 是 是 全局 是
authentication_ldap_sasl_group_search_filter 是 是 是 全局 是
authentication_ldap_sasl_init_pool_size 是 是 是 全局 是
authentication_ldap_sasl_log_status 是 是 是 全局 是
authentication_ldap_sasl_max_pool_size 是 是 是 全局 是
authentication_ldap_sasl_referral 是 是 是 全局 是
authentication_ldap_sasl_server_host 是 是 是 全局 是
authentication_ldap_sasl_server_port 是 是 是 全局 是
authentication_ldap_sasl_tls 是 是 是 全局 是
authentication_ldap_sasl_user_search_attr 是 是 是 全局 是
authentication_ldap_simple_auth_method_name 是 是 是 全局 是
authentication_ldap_simple_bind_base_dn 是 是 是 全局 是
authentication_ldap_simple_bind_root_dn 是 是 是 全局 是
authentication_ldap_simple_bind_root_pwd 是 是 是 全局 是
authentication_ldap_simple_ca_path 是 是 是 全局 是
authentication_ldap_simple_group_search_attr 是 是 是 全局 是
authentication_ldap_simple_group_search_filter 是 是 是 全局 是
authentication_ldap_simple_init_pool_size 是 是 是 全局 是
authentication_ldap_simple_log_status 是 是 是 全局 是
authentication_ldap_simple_max_pool_size 是 是 是 全局 是
authentication_ldap_simple_referral 是 是 是 全局 是
authentication_ldap_simple_server_host 是 是 是 全局 是
authentication_ldap_simple_server_port 是 是 是 全局 是
authentication_ldap_simple_tls 是 是 是 全局 是
authentication_ldap_simple_user_search_attr 是 是 是 全局 是
authentication_policy 是 是 是 全局 是
authentication_windows_log_level 是 是 是 全局 否
authentication_windows_use_principal_name 是 是 是 全局 否
名称 命令行 选项文件 系统变量 状态变量 变量范围 动态

  • authentication_fido_rp_id

    命令行格式 --authentication-fido-rp-id=value
    引入版本 8.0.27
    弃用 8.0.35
    系统变量 authentication_fido_rp_id
    范围 全局
    动态 是
    SET_VAR Hint Applies 否
    类型 字符串
    默认值 MySQL

    此变量指定用于 FIDO 设备注册和 FIDO 认证的依赖方 ID。如果尝试进行 FIDO 认证且此值与 FIDO 设备预期的值不符，则设备会认为自己未与正确的服务器通信，从而导致错误。最大值长度为 255 个字符。

    注意

    截至 MySQL 8.0.35 版本，此插件变量已被弃用，并可能在未来的 MySQL 版本中移除。

  • authentication_kerberos_service_key_tab

    命令行格式 --authentication-kerberos-service-key-tab=file_name
    引入版本 8.0.26
    系统变量 authentication_kerberos_service_key_tab
    范围 全局
    动态 否
    SET_VAR Hint Applies 否
    类型 文件名
    默认值 datadir/mysql.keytab

    包含用于认证从客户端接收的 MySQL 服务票据的 Kerberos 服务密钥的服务器端密钥表（“keytab”）文件的名称。文件名应给出为绝对路径名。如果未设置此变量，则默认值为数据目录中的 mysql.keytab。

    文件必须存在并包含服务主体名称（SPN）的有效密钥，否则客户端的身份验证将失败。 （SPN 和相同密钥也必须在 Kerberos 服务器中创建。） 该文件可能包含多个服务主体名称及其相应的密钥组合。

    文件必须由 Kerberos 服务器管理员生成，并复制到 MySQL 服务器可访问的位置。 可以使用以下命令验证文件是否正确并已正确复制：

    klist -k *file_name*

    有关 keytab 文件的信息，请参阅 web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html。

  • authentication_kerberos_service_principal

    命令行格式 --authentication-kerberos-service-principal=name
    引入 8.0.26
    系统变量 authentication_kerberos_service_principal
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 mysql/host_name@realm_name

    MySQL 服务器发送给客户端的 Kerberos 服务主体名称（SPN）。

    该值由服务名称（mysql）、主机名和领域名组成。 默认值为 mysql/*host_name*@*realm_name*。 服务主体名称中的领域使得可以检索到确切的服务密钥。

    要使用非默认值，请使用相同格式设置该值。 例如，要使用主机名为 krbauth.example.com 和领域为 MYSQL.LOCAL，请将 authentication_kerberos_service_principal 设置为 mysql/krbauth.example.com@MYSQL.LOCAL。

    服务主体名称和服务密钥必须已经存在于由 KDC 服务器管理的数据库中。

    可能存在仅由领域名称不同的服务主体名称。

  • authentication_ldap_sasl_auth_method_name

    命令行格式 --authentication-ldap-sasl-auth-method-name=value
    系统变量 authentication_ldap_sasl_auth_method_name
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 SCRAM-SHA-1
    有效值（≥ 8.0.23） SCRAM-SHA-1``SCRAM-SHA-256``GSSAPI
    有效值（≥ 8.0.20, ≤ 8.0.22） SCRAM-SHA-1``GSSAPI
    有效值（≤ 8.0.19） SCRAM-SHA-1

    对于 SASL LDAP 身份验证，这是身份验证方法的名称。身份验证插件与 LDAP 服务器之间的通信根据这种身份验证方法进行，以确保密码安全。

    允许这些身份验证方法值：

    • SCRAM-SHA-1：使用 SASL 挑战-响应机制。

      客户端端的 authentication_ldap_sasl_client 插件与 SASL 服务器通信，使用密码创建挑战并获取 SASL 请求缓冲区，然后将此缓冲区传递给服务器端的 authentication_ldap_sasl 插件。客户端端和服务器端的 SASL LDAP 插件使用 SASL 消息来安全传输凭据，以避免在 MySQL 客户端和服务器之间发送明文密码。

    • SCRAM-SHA-256：使用 SASL 挑战-响应机制。

      这种方法类似于 SCRAM-SHA-1，但更安全。它在 MySQL 8.0.23 及更高版本中可用。它需要使用 Cyrus SASL 2.1.27 或更高版本构建的 OpenLDAP 服务器。

    • GSSAPI：使用 Kerberos，一种无密码且基于票据的协议。

      GSSAPI/Kerberos 是 MySQL 客户端和服务器仅在 Linux 上支持的身份验证方法。在 Linux 环境中，应用程序使用默认启用 Kerberos 的 Microsoft Active Directory 访问 LDAP 时，这是非常有用的。

      客户端端的 authentication_ldap_sasl_client 插件使用来自 Kerberos 的票据授予票据（TGT）获取服务票据，但不直接使用 LDAP 服务。服务器端的 authentication_ldap_sasl 插件在客户端插件和 LDAP 服务器之间路由 Kerberos 消息。然后，服务器端插件使用获取的凭据与 LDAP 服务器通信，解释 LDAP 身份验证消息并检索 LDAP 组。

  • authentication_ldap_sasl_bind_base_dn

    命令行格式 --authentication-ldap-sasl-bind-base-dn=value
    系统变量 authentication_ldap_sasl_bind_base_dn
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 NULL

    对于 SASL LDAP 身份验证，基本区分名称（DN）。此变量可用于通过在搜索树中的特定位置（“基本”）锚定它们来限制搜索范围。

    假设一组 LDAP 用户条目的成员具有以下形式：

    uid=*user_name*,ou=People,dc=example,dc=com

    另一组 LDAP 用户条目的成员具有以下形式：

    uid=*user_name*,ou=Admin,dc=example,dc=com

    然后根据不同的基本 DN 值进行搜索：

    • 如果基本 DN 是 ou=People,dc=example,dc=com：搜索仅在第一组中找到用户条目。

    • 如果基本 DN 是 ou=Admin,dc=example,dc=com：搜索仅在第二组中找到用户条目。

    • 如果基本 DN 是 ou=dc=example,dc=com：搜索会在第一组或第二组中找到用户条目。

    一般来说，更具体的基本 DN 值会导致更快的搜索，因为它们限制了搜索范围。

  • authentication_ldap_sasl_bind_root_dn

    命令行格式 --authentication-ldap-sasl-bind-root-dn=value
    系统变量 authentication_ldap_sasl_bind_root_dn
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 NULL

    对于 SASL LDAP 认证，根区分名称（DN）。此变量与 authentication_ldap_sasl_bind_root_pwd 一起用作用于执行搜索的目的的 LDAP 服务器进行身份验证的凭据。身份验证使用一个或两个 LDAP 绑定操作，具体取决于 MySQL 帐户是否指定了 LDAP 用户 DN：

    • 如果帐户没有指定用户 DN：authentication_ldap_sasl 使用 authentication_ldap_sasl_bind_root_dn 和 authentication_ldap_sasl_bind_root_pwd 执行初始 LDAP 绑定。（这两个默认为空，所以如果它们没有设置，LDAP 服务器必须允许匿名连接。）生成的绑定 LDAP 句柄用于根据客户端用户名搜索用户 DN。authentication_ldap_sasl 使用用户 DN 和客户端提供的密码执行第二次绑定。

    • 如果帐户没有指定用户 DN：在这种情况下，第一个绑定操作是不必要的。authentication_ldap_sasl 使用用户 DN 和客户端提供的密码执行单个绑定。这比如果 MySQL 帐户没有指定 LDAP 用户 DN 要快。

  • authentication_ldap_sasl_bind_root_pwd

    命令行格式 --authentication-ldap-sasl-bind-root-pwd=value
    系统变量 authentication_ldap_sasl_bind_root_pwd
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 NULL

    对于 SASL LDAP 认证，根分隔名的密码。此变量与authentication_ldap_sasl_bind_root_dn一起使用。请参阅该变量的描述。

  • authentication_ldap_sasl_ca_path

    命令行格式 --authentication-ldap-sasl-ca-path=value
    系统变量 authentication_ldap_sasl_ca_path
    作用范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串
    默认值 NULL

    对于 SASL LDAP 认证，证书颁发机构文件的绝对路径。如果希望认证插件执行 LDAP 服务器证书的验证，则指定此文件。

    注意

    除了将authentication_ldap_sasl_ca_path变量设置为文件名外，还必须将适当的证书颁发机构证书添加到文件中，并启用authentication_ldap_sasl_tls系统变量。这些变量可以设置以覆盖默认的 OpenLDAP TLS 配置；请参阅 LDAP Pluggable Authentication and ldap.conf

  • authentication_ldap_sasl_group_search_attr

    命令行格式 --authentication-ldap-sasl-group-search-attr=value
    系统变量 authentication_ldap_sasl_group_search_attr
    作用范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串
    默认值 cn

    对于 SASL LDAP 认证，指定 LDAP 目录条目中指定组名的属性名称。如果authentication_ldap_sasl_group_search_attr具有默认值cn，则搜索将返回cn值作为组名。例如，如果具有uid值为user1的 LDAP 条目具有cn属性为mygroup，则搜索user1将返回mygroup作为组名。

    如果您不想进行组或代理认证，则此变量应为空字符串。

    如果组搜索属性是isMemberOf，LDAP 认证直接检索用户属性isMemberOf的值，并将其分配为组信息。如果组搜索属性不是isMemberOf，LDAP 认证将搜索用户是成员的所有组。（后者是默认行为。）此行为基于 LDAP 组信息可以以两种方式存储：1）组条目可以具有名为memberUid或member的属性，其值为用户名；2）用户条目可以具有名为isMemberOf的属性，其值为组名。

  • authentication_ldap_sasl_group_search_filter

    命令行格式 --authentication-ldap-sasl-group-search-filter=value
    系统变量 authentication_ldap_sasl_group_search_filter
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 (|(&(objectClass=posixGroup)(memberUid=%s))(&(objectClass=group)(member=%s)))

    对于 SASL LDAP 认证，自定义组搜索过滤器。

    搜索过滤器值可以包含{UA}和{UD}符号，分别表示用户名和完整用户 DN。例如，{UA}会被替换为用户名，比如"admin"，而{UD}会被替换为完整 DN，比如"uid=admin,ou=People,dc=example,dc=com"。以下是默认值，支持 OpenLDAP 和 Active Directory：

    (|(&(objectClass=posixGroup)(memberUid={UA}))
  (&(objectClass=group)(member={UD})))

    在某些情况下，对于用户场景，memberOf是一个简单的用户属性，不包含任何组信息。为了增加灵活性，可以在组搜索属性前使用可选的{GA}前缀。任何带有{GA}前缀的组属性都被视为具有组名的用户属性。例如，对于值{GA}MemberOf，如果组值是 DN，则从组 DN 中返回第一个属性值作为组名。

  • authentication_ldap_sasl_init_pool_size

    命令行格式 --authentication-ldap-sasl-init-pool-size=#
    系统变量 authentication_ldap_sasl_init_pool_size
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 整数
    默认值 10
    最小值 0
    最大值 32767
    单位 连接

    对于 SASL LDAP 认证，连接到 LDAP 服务器的连接池的初始大小。根据对 LDAP 服务器的平均并发认证请求数量选择此变量的值。

    插件使用authentication_ldap_sasl_init_pool_size和authentication_ldap_sasl_max_pool_size一起进行连接池管理：

    • 当认证插件初始化时，它会创建authentication_ldap_sasl_init_pool_size个连接，除非authentication_ldap_sasl_max_pool_size=0以禁用连接池。

    • 如果插件在当前连接池中没有空闲连接时收到认证请求，插件可以创建一个新连接，最多达到authentication_ldap_sasl_max_pool_size所指定的最大连接池大小。

    • 如果插件在连接池已经达到最大值且没有空闲连接时收到请求，认证将失败。

    • 当插件卸载时，它会关闭所有连接池中的连接。

    对插件系统变量设置的更改可能不会对已经在池中的连接产生影响。例如，修改 LDAP 服务器主机、端口或 TLS 设置不会影响现有连接。但是，如果原始变量值无效且连接池无法初始化，则插件会尝试为下一个 LDAP 请求重新初始化池。在这种情况下，新的系统变量值将用于重新初始化尝试。

    如果authentication_ldap_sasl_max_pool_size=0以禁用连接池，插件打开的每个 LDAP 连接都使用那时系统变量的值。

  • authentication_ldap_sasl_log_status

    命令行格式 --authentication-ldap-sasl-log-status=#
    系统变量 authentication_ldap_sasl_log_status
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1
    最小值 1
    最大值（≥ 8.0.18） 6
    最大值（≤ 8.0.17） 5

    对于 SASL LDAP 认证，写入错误日志的消息的日志级别。以下表显示了允许的级别值及其含义。

    表 8.30 authentication_ldap_sasl_log_status 的日志级别

    选项值 记录的消息类型
    1 没有消息
    2 错误消息
    3 错误和警告消息
    4 错误、警告和信息消息
    5 与前一级别相同，加上来自 MySQL 的调试消息
    6 与前一级别相同，加上来自 LDAP 库的调试消息

    从 MySQL 8.0.18 开始提供日志级别 6。

    在客户端端，可以通过设置AUTHENTICATION_LDAP_CLIENT_LOG环境变量将消息记录到标准输出。允许的默认值与authentication_ldap_sasl_log_status相同。

    AUTHENTICATION_LDAP_CLIENT_LOG环境变量仅适用于 SASL LDAP 认证。对于简单 LDAP 认证，它不起作用，因为在这种情况下，客户端插件是mysql_clear_password，它对 LDAP 操作一无所知。

  • authentication_ldap_sasl_max_pool_size

    命令行格式 --authentication-ldap-sasl-max-pool-size=#
    系统变量 authentication_ldap_sasl_max_pool_size
    作用域 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1000
    最小值 0
    最大值 32767
    单位 连接

    对于 SASL LDAP 认证，连接到 LDAP 服务器的连接池的最大大小。要禁用连接池，请将此变量设置为 0。

    此变量与authentication_ldap_sasl_init_pool_size一起使用。请参阅该变量的描述。

  • authentication_ldap_sasl_referral

    命令行格式 --authentication-ldap-sasl-referral[={OFF|ON}]
    引入版本 8.0.20
    系统变量 authentication_ldap_sasl_referral
    作用域 全局
    动态 是
    SET_VAR提示适用 否
    类型 布尔值
    默认值 OFF

    对于 SASL LDAP 认证，是否启用 LDAP 搜索引荐。请参阅 LDAP 搜索引荐。

    此变量可用于覆盖默认的 OpenLDAP 引荐配置；请参阅 LDAP 可插拔认证和 ldap.conf

  • authentication_ldap_sasl_server_host

    命令行格式 --authentication-ldap-sasl-server-host=host_name
    系统变量 authentication_ldap_sasl_server_host
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串

    对于 SASL LDAP 认证，LDAP 服务器主机。此变量的允许值取决于认证方法：

    • 对于authentication_ldap_sasl_auth_method_name=SCRAM-SHA-1：LDAP 服务器主机可以是主机名或 IP 地址。

    • 对于authentication_ldap_sasl_auth_method_name=SCRAM-SHA-256：LDAP 服务器主机可以是主机名或 IP 地址。

  • authentication_ldap_sasl_server_port

    命令行格式 --authentication-ldap-sasl-server-port=port_num
    系统变量 authentication_ldap_sasl_server_port
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 389
    最小值 1
    最大值 32376

    对于 SASL LDAP 认证，LDAP 服务器的 TCP/IP 端口号。

    从 MySQL 8.0.14 开始，如果 LDAP 端口号配置为 636 或 3269，则插件将使用 LDAPS（SSL 上的 LDAP）而不是 LDAP。（LDAPS 与startTLS不同。）

  • authentication_ldap_sasl_tls

    命令行格式 --authentication-ldap-sasl-tls[={OFF|ON}]
    系统变量 authentication_ldap_sasl_tls
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 布尔值
    默认值 OFF

    对于 SASL LDAP 认证，插件与 LDAP 服务器的连接是否安全。如果启用此变量，插件将使用 TLS 安全连接到 LDAP 服务器。此变量可用于覆盖默认的 OpenLDAP TLS 配置；请参阅 LDAP 可插拔认证和 ldap.conf。如果您启用此变量，可能还希望设置authentication_ldap_sasl_ca_path变量。

    MySQL LDAP 插件支持 StartTLS 方法，该方法在普通 LDAP 连接的顶部初始化 TLS。

    截至 MySQL 8.0.14，可以通过设置authentication_ldap_sasl_server_port系统变量来使用 LDAPS。

  • authentication_ldap_sasl_user_search_attr

    命令行格式 --authentication-ldap-sasl-user-search-attr=value
    系统变量 authentication_ldap_sasl_user_search_attr
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串
    默认值 uid

    对于 SASL LDAP 身份验证，指定 LDAP 目录条目中的用户名的属性名称。如果未提供用户可分辨名称，身份验证插件将使用此属性搜索名称。例如，如果authentication_ldap_sasl_user_search_attr的值为uid，则搜索用户名称user1会找到具有uid值为user1的条目。

  • authentication_ldap_simple_auth_method_name

    命令行格式 --authentication-ldap-simple-auth-method-name=value
    系统变量 authentication_ldap_simple_auth_method_name
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串
    默认值 SIMPLE
    有效值 SIMPLE``AD-FOREST

    对于简单的 LDAP 身份验证，身份验证方法名称。身份验证插件与 LDAP 服务器之间的通信根据此身份验证方法进行。

    注意

    对于所有简单的 LDAP 身份验证方法，建议还设置 TLS 参数，要求与 LDAP 服务器的通信必须通过安全连接进行。

    允许使用这些身份验证方法值：

    • SIMPLE: 使用简单的 LDAP 身份验证。该方法使用一个或两个 LDAP 绑定操作，具体取决于 MySQL 账户是否命名了 LDAP 用户的可分辨名称。请参阅authentication_ldap_simple_bind_root_dn的描述。

    • AD-FOREST: 一种基于SIMPLE的变体，使得身份验证在 Active Directory forest 中搜索所有域，在每个 Active Directory 域上执行 LDAP 绑定，直到在某个域中找到用户。

  • authentication_ldap_simple_bind_base_dn

    命令行格式 --authentication-ldap-simple-bind-base-dn=value
    系统变量 authentication_ldap_simple_bind_base_dn
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串
    默认值 NULL

    对于简单的 LDAP 身份验证，基本分明名称（DN）。此变量可用于通过在搜索树中的特定位置（“基本”）锚定它们来限制搜索范围。

    假设一组 LDAP 用户条目的成员各自具有以下形式：

    uid=*user_name*,ou=People,dc=example,dc=com

    另一组 LDAP 用户条目的成员具有以下形式：

    uid=*user_name*,ou=Admin,dc=example,dc=com

    然后，不同基本 DN 值的搜索工作如下：

    • 如果基本 DN 为ou=People,dc=example,dc=com：搜索仅在第一组中找到用户条目。

    • 如果基本 DN 为ou=Admin,dc=example,dc=com：搜索仅在第二组中找到用户条目。

    • 如果基本 DN 为ou=dc=example,dc=com：搜索在第一组或第二组中找到用户条目。

    一般来说，更具体的基本 DN 值会导致更快的搜索，因为它们限制了搜索范围。

  • authentication_ldap_simple_bind_root_dn

    命令行格式 --authentication-ldap-simple-bind-root-dn=value
    系统变量 authentication_ldap_simple_bind_root_dn
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 字符串
    默认值 NULL

    对于简单的 LDAP 身份验证，根分明名称（DN）。此变量与authentication_ldap_simple_bind_root_pwd一起用作验证到 LDAP 服务器以执行搜索的凭据。身份验证使用一个或两个 LDAP 绑定操作，具体取决于 MySQL 帐户是否命名为 LDAP 用户 DN：

    • 如果帐户没有指定用户 DN：authentication_ldap_simple使用authentication_ldap_simple_bind_root_dn和authentication_ldap_simple_bind_root_pwd执行初始 LDAP 绑定。（这两个变量默认为空，因此如果它们未设置，则 LDAP 服务器必须允许匿名连接。）生成的绑定 LDAP 句柄用于根据客户端用户名搜索用户 DN。authentication_ldap_simple使用用户 DN 和客户端提供的密码执行第二次绑定。

    • 如果帐户没有指定用户 DN：在这种情况下，第一个绑定操作是不必要的。authentication_ldap_simple使用用户 DN 和客户端提供的密码执行单个绑定。这比如果 MySQL 帐户没有指定 LDAP 用户 DN 要快。

  • authentication_ldap_simple_bind_root_pwd

    命令行格式 --authentication-ldap-simple-bind-root-pwd=value
    系统变量 authentication_ldap_simple_bind_root_pwd
    作用域 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 NULL

    对于简单的 LDAP 身份验证，根分隔名称的密码。此变量与authentication_ldap_simple_bind_root_dn一起使用。请参阅该变量的描述。

  • authentication_ldap_simple_ca_path

    命令行格式 --authentication-ldap-simple-ca-path=value
    系统变量 authentication_ldap_simple_ca_path
    作用域 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 NULL

    对于简单的 LDAP 身份验证，证书颁发机构文件的绝对路径。如果希望认证插件执行 LDAP 服务器证书的验证，请指定此文件。

    注意

    除了将authentication_ldap_simple_ca_path变量设置为文件名之外，还必须将适当的证书颁发机构证书添加到文件中，并启用authentication_ldap_simple_tls系统变量。这些变量可以设置以覆盖默认的 OpenLDAP TLS 配置；请参阅 LDAP Pluggable Authentication and ldap.conf

  • authentication_ldap_simple_group_search_attr

    命令行格式 --authentication-ldap-simple-group-search-attr=value
    系统变量 authentication_ldap_simple_group_search_attr
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 cn

    对于简单的 LDAP 认证，指定 LDAP 目录条目中组名的属性名称。如果authentication_ldap_simple_group_search_attr具有其默认值cn，搜索将返回cn值作为组名。例如，如果具有uid值为user1的 LDAP 条目具有cn属性为mygroup，则搜索user1将返回mygroup作为组名。

    如果组搜索属性是isMemberOf，LDAP 认证直接检索用户属性isMemberOf的值，并将其分配为组信息。如果组搜索属性不是isMemberOf，LDAP 认证将搜索用户是成员的所有组。（后者是默认行为。）此行为基于 LDAP 组信息可以以两种方式存储的方式：1）组条目可以具有名为memberUid或member的属性，其值为用户名；2）用户条目可以具有名为isMemberOf的属性，其值为组名。

  • authentication_ldap_simple_group_search_filter

    命令行格式 --authentication-ldap-simple-group-search-filter=value
    系统变量 authentication_ldap_simple_group_search_filter
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 (|(&(objectClass=posixGroup)(memberUid=%s))(&(objectClass=group)(member=%s)))

    对于简单的 LDAP 认证，自定义组搜索过滤器。

    搜索过滤器值可以包含{UA}和{UD}符号，分别表示用户名和完整用户 DN。例如，{UA}被替换为用户名，如"admin"，而{UD}被替换为完整 DN，如"uid=admin,ou=People,dc=example,dc=com"。以下值是默认值，支持 OpenLDAP 和 Active Directory：

    (|(&(objectClass=posixGroup)(memberUid={UA}))
  (&(objectClass=group)(member={UD})))

    在某些用户场景中，memberOf是一个简单的用户属性，不包含任何组信息。为了增加灵活性，可以在组搜索属性中使用可选的{GA}前缀。任何带有{GA}前缀的组属性都被视为具有组名的用户属性。例如，如果值为{GA}MemberOf，如果组值是 DN，则从组 DN 中返回第一个属性值作为组名。

  • authentication_ldap_simple_init_pool_size

    命令行格式 --authentication-ldap-simple-init-pool-size=#
    系统变量 authentication_ldap_simple_init_pool_size
    作用域 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 10
    最小值 0
    最大值 32767
    单位 连接

    对于简单的 LDAP 认证，连接到 LDAP 服务器的连接池的初始大小。根据对 LDAP 服务器的平均并发认证请求数量选择此变量的值。

    插件同时使用authentication_ldap_simple_init_pool_size和authentication_ldap_simple_max_pool_size进行连接池管理：

    • 当认证插件初始化时，它会创建authentication_ldap_simple_init_pool_size个连接，除非authentication_ldap_simple_max_pool_size=0以禁用连接池。

    • 如果插件在当前连接池中没有空闲连接时收到认证请求，则插件可以创建一个新连接，最多达到authentication_ldap_simple_max_pool_size给定的最大连接池大小。

    • 如果插件在池大小已达到最大值且没有空闲连接时收到请求，则身份验证失败。

    • 当插件卸载时，它会关闭所有连接池中的连接。

    对插件系统变量设置的更改可能对已经在池中的连接没有影响。例如，修改 LDAP 服务器主机、端口或 TLS 设置不会影响现有连接。但是，如果原始变量值无效且连接池无法初始化，则插件会尝试为下一个 LDAP 请求重新初始化池。在这种情况下，新的系统变量值将用于重新初始化尝试。

    如果authentication_ldap_simple_max_pool_size=0以禁用连接池，则插件打开的每个 LDAP 连接都使用系统变量在那时的值。

  • authentication_ldap_simple_log_status

    命令行格式 --authentication-ldap-simple-log-status=#
    系统变量 authentication_ldap_simple_log_status
    作用范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1
    最小值 1
    最大值（≥ 8.0.18） 6
    最大值（≤ 8.0.17） 5

    对于简单的 LDAP 身份验证，写入错误日志的消息的日志级别。下表显示了允许的级别值及其含义。

    表 8.31 authentication_ldap_simple_log_status 的日志级别

    选项数值 记录的消息类型
    1 无消息
    2 错误消息
    3 错误和警告消息
    4 错误、警告和信息消息
    5 与前一级别相同，加上来自 MySQL 的调试消息
    6 与前一级别相同，加上来自 LDAP 库的调试消息

    MySQL 8.0.18 版本中提供日志级别 6。

  • authentication_ldap_simple_max_pool_size

    命令行格式 --authentication-ldap-simple-max-pool-size=#
    系统变量 authentication_ldap_simple_max_pool_size
    作用范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1000
    最小值 0
    最大值 32767
    单位 连接数

    对于简单的 LDAP 身份��证，连接到 LDAP 服务器的连接池的最大大小。要禁用连接池，请将此变量设置为 0。

    此变量与 authentication_ldap_simple_init_pool_size 结合使用。请参阅该变量的描述。

  • authentication_ldap_simple_referral

    命令行格式 --authentication-ldap-simple-referral[={OFF|ON}]
    引入版本 8.0.20
    系统变量 authentication_ldap_simple_referral
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 布尔值
    默认值 OFF

    对于简单的 LDAP 认证，是否启用 LDAP 搜索引荐。请参阅 LDAP 搜索引荐。

  • authentication_ldap_simple_server_host

    命令行格式 --authentication-ldap-simple-server-host=host_name
    系统变量 authentication_ldap_simple_server_host
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串

    对于简单的 LDAP 认证，LDAP 服务器主机。此变量的允许值取决于认证方法：

    • 对于 authentication_ldap_simple_auth_method_name=SIMPLE: LDAP 服务器主机可以是主机名或 IP 地址。

    • 对于 authentication_ldap_simple_auth_method_name=AD-FOREST。LDAP 服务器主机可以是 Active Directory 域名。例如，对于 LDAP 服务器 URL 为 ldap://example.mem.local:389，域名可以是 mem.local。

      Active Directory 森林设置可以拥有多个域（LDAP 服务器 IP），可以使用 DNS 发现。在 Unix 和类 Unix 系统上，可能需要进行一些额外的设置来配置您的 DNS 服务器，使用指定 Active Directory 域的 LDAP 服务器的 SRV 记录。有关 DNS SRV 的信息，请参阅 RFC 2782。

      假设您的配置具有以下属性：

      • 提供有关 Active Directory 域信息的名称服务器的 IP 地址为 10.172.166.100。

      • LDAP 服务器的名称为 ldap1.mem.local 到 ldap3.mem.local，IP 地址为 10.172.166.101 到 10.172.166.103。

      希望能够通过 SRV 搜索发现 LDAP 服务器。例如，在命令行中，类似这样的命令应该列出 LDAP 服务器：

      host -t SRV _ldap._tcp.mem.local

      执行以下 DNS 配置：

      1. 添加一行到 /etc/resolv.conf，指定提供有关 Active Directory 域信息的名称服务器：

        nameserver 10.172.166.100

      2. 针对 LDAP 服务器配置适当的区域文件，包含 LDAP 服务器的 SRV 记录：

        _ldap._tcp.mem.local. 86400 IN SRV 0 100 389 ldap1.mem.local.
_ldap._tcp.mem.local. 86400 IN SRV 0 100 389 ldap2.mem.local.
_ldap._tcp.mem.local. 86400 IN SRV 0 100 389 ldap3.mem.local.

      3. 如果服务器主机无法解析，可能还需要在 /etc/hosts 中指定 LDAP 服务器的 IP 地址。例如，向文件中添加如下行：

        10.172.166.101 ldap1.mem.local
10.172.166.102 ldap2.mem.local
10.172.166.103 ldap3.mem.local

      配置 DNS 如刚才描述的那样，服务器端 LDAP 插件可以发现 LDAP 服务器，并在所有域中尝试进行身份验证，直到身份验证成功或没有更多服务器为止。

      Windows 不需要像刚才描述的设置。给定 authentication_ldap_simple_server_host 值中的 LDAP 服务器主机，Windows LDAP 库会搜索所有域并尝试进行身份验证。

  • authentication_ldap_simple_server_port

    命令行格式 --authentication-ldap-simple-server-port=port_num
    系统变量 authentication_ldap_simple_server_port
    范围 全局
    动态 是
    SET_VAR Hint Applies 否
    类型 整数
    默认值 389
    最小值 1
    最大值 32376

    简单 LDAP 身份验证所需的 LDAP 服务器 TCP/IP 端口号。

    从 MySQL 8.0.14 开始，如果 LDAP 端口号配置为 636 或 3269，则插件将使用 LDAPS（LDAP over SSL）而不是 LDAP。（LDAPS 与 startTLS 不同。）

  • authentication_ldap_simple_tls

    命令行格式 --authentication-ldap-simple-tls[={OFF|ON}]
    系统变量 authentication_ldap_simple_tls
    范围 全局
    动态 是
    SET_VAR Hint Applies 否
    类型 布尔值
    默认值 OFF

    对于简单的 LDAP 认证，插件与 LDAP 服务器的连接是否安全。如果启用此变量，插件将使用 TLS 安全连接到 LDAP 服务器。此变量可用于覆盖默认的 OpenLDAP TLS 配置；请参阅 LDAP 可插拔认证和 ldap.conf。如果启用此变量，您可能还希望设置 authentication_ldap_simple_ca_path 变量。

    MySQL LDAP 插件支持 StartTLS 方法，该方法在普通 LDAP 连接的基础上初始化 TLS。

    从 MySQL 8.0.14 开始，可以通过设置 authentication_ldap_simple_server_port 系统变量来使用 LDAPS。

  • authentication_ldap_simple_user_search_attr

    命令行格式 --authentication-ldap-simple-user-search-attr=value
    系统变量 authentication_ldap_simple_user_search_attr
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 字符串
    默认值 uid

    对于简单的 LDAP 认证，指定 LDAP 目录条目中用户名称的属性名称。如果未提供用户的可分辨名称，认证插件将使用此属性搜索名称。例如，如果 authentication_ldap_simple_user_search_attr 的值为 uid，则搜索用户名称 user1 将找到具有 uid 值为 user1 的条目。

8.4.2 连接控制插件

原文：dev.mysql.com/doc/refman/8.0/en/connection-control.html

8.4.2.1 连接控制插件安装

8.4.2.2 连接控制系统和状态变量

MySQL 服务器包含一个插件库，使管理员能够在一定数量的连续失败尝试之后，向连接尝试的服务器响应引入逐渐增加的延迟。这种能力提供了一个减缓措施，可以减缓针对 MySQL 用户账户的暴力攻击。插件库包含两个插件：

  • CONNECTION_CONTROL 检查传入的连接尝试，并根据需要向服务器响应添加延迟。该插件还公开了系统变量，使其操作可以配置，并提供了一个状态变量，提供基本的监控信息。

    CONNECTION_CONTROL 插件使用审计插件接口（参见 编写审计插件）。为了收集信息，它订阅了 MYSQL_AUDIT_CONNECTION_CLASSMASK 事件类，并处理 MYSQL_AUDIT_CONNECTION_CONNECT 和 MYSQL_AUDIT_CONNECTION_CHANGE_USER 子事件，以检查服务器是否应在响应连接尝试之前引入延迟。

  • CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 实现了一个 INFORMATION_SCHEMA 表，公开了有关失败连接尝试的更详细的监控信息。

以下各节提供有关连接控制插件安装和配置的信息。有关 CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表的信息，请参阅 第 28.6.2 节，“INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表”。

原文：dev.mysql.com/doc/refman/8.0/en/connection-control-installation.html

8.4.2.1 连接控制插件安装

本节描述了如何安装连接控制插件CONNECTION_CONTROL和CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS。有关安装插件的一般信息，请参见第 7.6.1 节，“安装和卸载插件”。

要使服务器可用，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如果需要，通过在服务器启动时设置plugin_dir的值来配置插件目录位置。

插件库文件的基本名称是connection_control。文件名后缀因平台而异（例如，对于 Unix 和类 Unix 系统，为.so，对于 Windows 为.dll）。

要在服务器启动时加载插件，请使用--plugin-load-add选项命名包含它们的库文件。使用此插件加载方法，选项必须在每次服务器启动时给出。例如，将以下行放入服务器的my.cnf文件中，根据需要调整您平台的.so后缀：

[mysqld]
plugin-load-add=connection_control.so

修改my.cnf后，重新启动服务器以使新设置生效。

或者，要在运行时加载插件，请使用以下语句，根据需要调整您平台的.so后缀：

INSTALL PLUGIN CONNECTION_CONTROL
  SONAME 'connection_control.so';
INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS
  SONAME 'connection_control.so';

INSTALL PLUGIN立即加载插件，并在mysql.plugins系统表中注册它，以使服务器在每次后续正常启动时加载它，而无需--plugin-load-add。

要验证插件安装，请检查信息模式PLUGINS表，或使用SHOW PLUGINS语句（参见第 7.6.2 节，“获取服务器插件信息”）。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE 'connection%';
+------------------------------------------+---------------+
| PLUGIN_NAME                              | PLUGIN_STATUS |
+------------------------------------------+---------------+
| CONNECTION_CONTROL                       | ACTIVE        |
| CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS | ACTIVE        |
+------------------------------------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断信息。

如果插件之前已经使用INSTALL PLUGIN注册过，或者使用--plugin-load-add加载过，您可以在服务器启动时使用--connection-control和--connection-control-failed-login-attempts选项来控制插件的激活。例如，要在启动时加载插件并防止它们在运行时被移除，请使用以下选项：

[mysqld]
plugin-load-add=connection_control.so
connection-control=FORCE_PLUS_PERMANENT
connection-control-failed-login-attempts=FORCE_PLUS_PERMANENT

如果希望防止服务器在没有给定连接控制插件的情况下运行，请使用 FORCE 或 FORCE_PLUS_PERMANENT 的选项值，以强制服务器启动失败，如果插件未成功初始化。

注意

可以安装一个插件而不安装另一个插件，但必须同时安装两个插件才能实现完整的连接控制功能。特别是，仅安装 CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 插件几乎没有用处，因为没有 CONNECTION_CONTROL 插件提供数据来填充 CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表，该表始终为空。

  • 连接延迟配置

  • 连接失败评估

  • 连接失败监控

连接延迟配置

要启用其操作配置，CONNECTION_CONTROL 插件公开了这些系统变量：

  • connection_control_failed_connections_threshold: 在服务器在为账户添加延迟以进行后续连接尝试之前允许的连续失败连接尝试次数。要禁用失败连接计数，请将 connection_control_failed_connections_threshold 设置为零。

  • connection_control_min_connection_delay: 连接失败的最小延迟时间（毫秒）超过阈值。

  • connection_control_max_connection_delay: 连接失败的最大延迟时间（毫秒）超过阈值。

如果 connection_control_failed_connections_threshold 不为零，则启用了失败连接计数，并具有以下属性：

  • 延迟为零，直到connection_control_failed_connections_threshold 连续失败的连接尝试。

  • 之后，服务器会为后续连续尝试添加递增延迟，直到成功连接发生。初始未调整的延迟从 1000 毫秒（1 秒）开始，每次尝试增加 1000 毫秒。也就是说，一旦账户激活延迟，后续失败尝试的未调整延迟为 1000 毫秒、2000 毫秒、3000 毫秒等。

  • 客户端实际经历的延迟是未调整的延迟，调整后的值在connection_control_min_connection_delay和connection_control_max_connection_delay系统变量的值范围内。

  • 一旦账户激活延迟，随后该账户的第一次成功连接也会经历延迟，但是对于后续连接，失败计数会被重置。

例如，使用默认的connection_control_failed_connections_threshold值为 3，账户的前三次连续连接尝试失败不会有延迟。账户在第四次及后续失败连接中实际调整的延迟取决于connection_control_min_connection_delay和connection_control_max_connection_delay的值：

  • 如果connection_control_min_connection_delay和connection_control_max_connection_delay分别为 1000 和 20000，调整后的延迟与未调整的延迟相同，最多不超过 20000 毫秒。第四次及后续失败连接延迟为 1000 毫秒、2000 毫秒、3000 毫秒等。

  • 如果connection_control_min_connection_delay和connection_control_max_connection_delay分别为 1500 和 20000，第四次及后续失败连接的调整延迟为 1500 毫秒、2000 毫秒、3000 毫秒等，最多不超过 20000 毫秒。

  • 如果 connection_control_min_connection_delay 和 connection_control_max_connection_delay 分别为 2000 和 3000，则第四次及后续失败连接的调整延迟为 2000 毫秒、2000 毫秒和 3000 毫秒，所有后续失败连接也将延迟 3000 毫秒。

您可以在服务器启动或运行时设置CONNECTION_CONTROL系统变量。假设您希望在服务器开始延迟其响应之前允许四次连续失败的连接尝试，最小延迟为 2000 毫秒。要在服务器启动时设置相关变量，请将以下行放入服务器的my.cnf文件中：

[mysqld]
plugin-load-add=connection_control.so
connection_control_failed_connections_threshold=4
connection_control_min_connection_delay=2000

要在运行时设置并持久化变量，请使用以下语句：

SET PERSIST connection_control_failed_connections_threshold = 4;
SET PERSIST connection_control_min_connection_delay = 2000;

SET PERSIST 为正在运行的 MySQL 实例设置一个值。它还保存该值，导致其在后续服务器重新启动时保留。要更改正在运行的 MySQL 实例的值，而不使其在后续重新启动时保留，使用GLOBAL关键字而不是PERSIST。参见 Section 15.7.6.1, “变量赋值的 SET 语法”。

connection_control_min_connection_delay 和 connection_control_max_connection_delay 系统变量的最小值和最大值均为 1000 和 2147483647。此外，每个变量的允许值范围还取决于另一个变量的当前值：

  • connection_control_min_connection_delay 不能设置为大于当前值connection_control_max_connection_delay。

  • connection_control_max_connection_delay 不能设置为小于当前值connection_control_min_connection_delay。

因此，为了对某些配置所需的更改进行设置，您可能需要按特定顺序设置变量。假设当前的最小延迟和最大延迟分别为 1000 和 2000，并且您想将它们设置为 3000 和 5000。您不能首先将connection_control_min_connection_delay设置为 3000，因为这大于当前的connection_control_max_connection_delay值 2000。相反，先将connection_control_max_connection_delay设置为 5000，然后将connection_control_min_connection_delay设置为 3000。

连接失败评估

当安装了CONNECTION_CONTROL插件时，它会检查连接尝试并跟踪它们是失败还是成功。为此，连接失败尝试是指客户端用户和主机匹配已知的 MySQL 账户，但提供的凭据不正确，或者不匹配任何已知账户。

失败连接计数基于每次连接尝试的用户/主机组合。适用用户名称和主机名称的确定考虑了代理，并按以下方式进行：

  • 如果客户端用户代理另一个用户，则失败连接计数的账户是代理用户，而不是被代理用户。例如，如果external_user@example.com代理了proxy_user@example.com，连接计数使用代理用户external_user@example.com，而不是被代理用户proxy_user@example.com。external_user@example.com和proxy_user@example.com必须在mysql.user系统表中有有效条目，并且它们之间必须在mysql.proxies_priv系统表中定义代理关系（参见第 8.2.19 节，“代理用户”）。

  • 如果客户端用户没有代理另一个用户，但匹配了一个mysql.user条目，则计数使用与该条目对应的CURRENT_USER()值。例如，如果用户user1从主机host1.example.com连接匹配了user1@host1.example.com条目，则计数使用user1@host1.example.com。如果用户匹配了user1@%.example.com、user1@%.com或user1@%条目，计数分别使用user1@%.example.com、user1@%.com或user1@%。

对于刚才描述的情况，连接尝试匹配了一些mysql.user条目，请求成功或失败取决于客户端是否提供了正确的身份验证凭据。例如，如果客户端提供了错误的密码，连接尝试将失败。

如果连接尝试与任何 mysql.user 条目不匹配，则尝试失败。在这种情况下，没有 CURRENT_USER() 值可用，连接失败计数使用客户端提供的用户名和服务器确定的客户端主机。例如，如果客户端尝试作为用户 user2 从主机 host2.example.com 连接，则用户名称部分在客户端请求中可用，服务器确定主机信息。用于计数的用户/主机组合是 user2@host2.example.com。

注意

服务器维护关于哪些客户端主机可能连接到服务器的信息（基本上是 mysql.user 条目的主机值的并集）。如果客户端尝试从任何其他主机连接，服务器在连接设置的早期阶段拒绝尝试：

ERROR 1130 (HY000): Host '*host_name*' is not
allowed to connect to this MySQL server

因为这种类型的拒绝发生得如此早，CONNECTION_CONTROL 看不到它，并且不计数。

连接失败监控

要监视失败连接，请使用以下信息来源：

  • Connection_control_delay_generated 状态变量指示服务器在响应失败连接尝试时添加延迟的次数。这不包括在达到由 connection_control_failed_connections_threshold 系统变量定义的阈值之前发生的尝试。

  • INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表提供了关于每个账户（用户/主机组合）连续失败连接尝试的当前数量的信息。这计算所有失败尝试，无论它们是否被延迟。

在运行时为 connection_control_failed_connections_threshold 赋值会产生以下效果：

  • 所有累积的失败连接计数器被重置为零。

  • Connection_control_delay_generated 状态变量被重置为零。

  • CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表变为空。

原文：dev.mysql.com/doc/refman/8.0/en/connection-control-variables.html

8.4.2.2 连接控制系统和状态变量

本节描述了CONNECTION_CONTROL插件提供的系统和状态变量，以便配置和监视其操作。

  • 连接控制系统变量

  • 连接控制状态变量

连接控制系统变量

如果安装了CONNECTION_CONTROL插件，则会公开这些系统变量：

  • connection_control_failed_connections_threshold

    命令行格式 --connection-control-failed-connections-threshold=#
    系统变量 connection_control_failed_connections_threshold
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 3
    最小值 0
    最大值 2147483647

    在服务器在向帐户添加延迟以进行后续连接尝试之前允许的连续失败连接尝试次数：

    • 如果变量具有非零值N，则服务器从连续失败尝试N+1 开始添加延迟。如果帐户已达到连接响应被延迟的点，则下一个成功连接也会延迟。

    • 将此变量设置为零会禁用失败连接计数。在这种情况下，服务器永远不会添加延迟。

    有关connection_control_failed_connections_threshold与其他连接控制系统和状态变量的交互信息，请参见第 8.4.2.1 节，“连接控制插件安装”。

  • connection_control_max_connection_delay

    命令行格式 --connection-control-max-connection-delay=#
    系统变量 connection_control_max_connection_delay
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 2147483647
    最小值 1000
    最大值 2147483647
    单位 毫秒

    如果connection_control_failed_connections_threshold大于零，则服务器响应失败连接尝试的最大延迟（以毫秒为单位）。

    有关connection_control_max_connection_delay如何与其他连接控制系统和状态变量交互的信息，请参见第 8.4.2.1 节，“连接控制插件安装”。

  • connection_control_min_connection_delay

    命令行格式 --connection-control-min-connection-delay=#
    系统变量 connection_control_min_connection_delay
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1000
    最小值 1000
    最大值 2147483647
    单位 毫秒

    服务器响应失败连接尝试的最小延迟（以毫秒为单位），如果connection_control_failed_connections_threshold大于零。

    有关connection_control_min_connection_delay如何与其他连接控制系统和状态变量交互的信息，请参见第 8.4.2.1 节，“连接控制插件安装”。

连接控制状态变量

如果安装了CONNECTION_CONTROL插件，则会公开此状态变量：

  • Connection_control_delay_generated

    服务器在响应失败连接尝试时添加延迟的次数。这不包括在达到由connection_control_failed_connections_threshold系统变量定义的阈值之前发生的尝试。

    这个变量提供了一个简单的计数器。要获取更详细的连接控制监控信息，请查看INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表；参见 Section 28.6.2, “The INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS Table”。

    在运行时为connection_control_failed_connections_threshold赋值会将Connection_control_delay_generated重置为零。

8.4.3 密码验证组件

原文：dev.mysql.com/doc/refman/8.0/en/validate-password.html

8.4.3.1 密码验证组件的安装和卸载

8.4.3.2 密码验证选项和变量

8.4.3.3 过渡到密码验证组件

validate_password 组件通过要求帐户密码并启用潜在密码的强度测试来提高安全性。该组件公开了系统变量，使您能够配置密码策略，并公开了用于组件监视的状态变量。

注意

在 MySQL 8.0 中，validate_password 插件被重新实现为 validate_password 组件。（有关组件的一般信息，请参见 第 7.5 节，“MySQL 组件”。）以下说明描述了如何使用组件，而不是插件。有关使用 validate_password 插件形式的说明，请参见 密码验证插件，在 MySQL 5.7 参考手册 中。

validate_password 插件形式仍然可用，但已被弃用；预计将在将来的 MySQL 版本中删除。使用插件的 MySQL 安装应该过渡到使用组件。请参见 第 8.4.3.3 节，“过渡到密码验证组件”。

validate_password 组件实现了以下功能：

  • 对于将明文值作为密码分配的 SQL 语句，validate_password 会根据当前密码策略检查密码，并在密码弱时拒绝密码（该语句返回一个 ER_NOT_VALID_PASSWORD 错误）。这适用于 ALTER USER、CREATE USER 和 SET PASSWORD 语句。

  • 对于 CREATE USER 语句，validate_password 要求提供密码，并且该密码必须符合密码策略。即使帐户最初被锁定，解锁帐户后也需要满足策略要求的密码，否则稍后访问该帐户将不需要密码。

  • validate_password 实现了一个 VALIDATE_PASSWORD_STRENGTH() SQL 函数，用于评估潜在密码的强度。该函数接受一个密码参数，并返回一个从 0（弱）到 100（强）的整数。

注意

对于分配或修改帐户密码的语句（ALTER USER，CREATE USER和SET PASSWORD），这里描述的validate_password功能仅适用于使用将凭据内部存储到 MySQL 的身份验证插件的帐户。对于使用针对 MySQL 外部凭据系统执行身份验证的插件的帐户，密码管理也必须在该系统外部处理。有关内部凭据存储的更多信息，请参阅 Section 8.2.15, “Password Management”。

前面的限制不适用于使用VALIDATE_PASSWORD_STRENGTH()函数，因为它不直接影响帐户。

例子：

  • validate_password在以下语句中检查明文密码。根据要求密码至少为 8 个字符长的默认密码策略，密码较弱，该语句将产生错误：

    mysql> ALTER USER USER() IDENTIFIED BY 'abc';
ERROR 1819 (HY000): Your password does not satisfy the current
policy requirements

  • 由于原始密码值不可用进行检查，指定为散列值的密码不会被检查：

    mysql> ALTER USER 'jeffrey'@'localhost'
       IDENTIFIED WITH mysql_native_password
       AS '*0D3CED9BEC10A777AEC23CCC353A8C08A633045E';
Query OK, 0 rows affected (0.01 sec)

  • 即使帐户最初被锁定，由于没有包含符合当前密码策略的密码，此帐户创建语句将失败：

    mysql> CREATE USER 'juanita'@'localhost' ACCOUNT LOCK;
ERROR 1819 (HY000): Your password does not satisfy the current
policy requirements

  • 要检查密码，请使用VALIDATE_PASSWORD_STRENGTH()函数：

    mysql> SELECT VALIDATE_PASSWORD_STRENGTH('weak');
+------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('weak') |
+------------------------------------+
|                                 25 |
+------------------------------------+
mysql> SELECT VALIDATE_PASSWORD_STRENGTH('lessweak$_@123');
+----------------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('lessweak$_@123') |
+----------------------------------------------+
|                                           50 |
+----------------------------------------------+
mysql> SELECT VALIDATE_PASSWORD_STRENGTH('N0Tweak$_@123!');
+----------------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('N0Tweak$_@123!') |
+----------------------------------------------+
|                                          100 |
+----------------------------------------------+

要配置密码检查，请修改名称形式为validate_password.*xxx*的系统变量；这些是控制密码策略的参数。请参阅 Section 8.4.3.2, “Password Validation Options and Variables”。

如果未安装validate_password，则validate_password.*xxx*系统变量不可用，语句中的密码不会被检查，VALIDATE_PASSWORD_STRENGTH()函数始终返回 0。例如，如果没有安装插件，帐户可以被分配少于 8 个字符的密码，甚至可以没有密码。

假设已安装validate_password，它实现了三个级别的密码检查：LOW，MEDIUM和STRONG。默认为MEDIUM；要更改此设置，请修改validate_password.policy的值。这些策略实施越来越严格的密码测试。以下描述是针对默认参数值的，可以通过更改相应的系统变量来修改这些值。

  • LOW策略仅测试密码长度。密码必须至少为 8 个字符长。要更改此长度，请修改validate_password.length。

  • MEDIUM策略添加了密码必须包含至少 1 个数字字符、1 个小写字符、1 个大写字符和 1 个特殊（非字母数字）字符的条件。要更改这些值，请修改validate_password.number_count、validate_password.mixed_case_count和validate_password.special_char_count。

  • STRONG策略添加了一个条件，即长度为 4 或更长的密码子串不得与字典文件中的单词匹配（如果已指定）。要指定字典文件，请修改validate_password.dictionary_file。

此外，validate_password支持拒绝与当前会话的有效用户帐户的用户名部分匹配的密码，无论是正向还是反向。为了控制这种能力，validate_password暴露了一个validate_password.check_user_name系统变量，默认情况下已启用。

原文：dev.mysql.com/doc/refman/8.0/en/validate-password-installation.html

8.4.3.1 密码验证组件的安装和卸载

本节描述了如何安装和卸载 validate_password 密码验证组件。有关安装和卸载组件的一般信息，请参阅第 7.5 节，“MySQL 组件”。

注意

如果使用MySQL Yum 仓库、MySQL SLES 仓库或由 Oracle 提供的 RPM 软件包安装 MySQL 8.0，则在首次启动 MySQL 服务器后，默认启用 validate_password 组件。

从使用 Yum 或 RPM 软件包升级到 MySQL 8.0 时，validate_password 插件会保留在原位。要从 validate_password 插件过渡到 validate_password 组件，请参阅第 8.4.3.3 节，“过渡到密码验证组件”。

要使组件库文件可被服务器使用，必须将其放置在 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如有必要，在服务器启动时通过设置plugin_dir的值来配置插件目录位置。

要安装 validate_password 组件，请使用以下语句：

INSTALL COMPONENT 'file://component_validate_password';

组件安装是一次性操作，不需要每次服务器启动都执行。INSTALL COMPONENT加载组件，并在 mysql.component 系统表中注册它，以便在随后的服务器启动期间加载它。

要卸载 validate_password 组件，请使用以下语句：

UNINSTALL COMPONENT 'file://component_validate_password';

UNINSTALL COMPONENT卸载组件，并从 mysql.component 系统表中注销它，以使其在随后的服务器启动期间不加载。

原文：dev.mysql.com/doc/refman/8.0/en/validate-password-options-variables.html

8.4.3.2 密码验证选项和变量

本节描述了validate_password提供的系统和状态变量，以便配置和监视其操作。

  • 密码验证组件系统变量

  • 密码验证组件状态变量

  • 密码验证插件选项

  • 密码验证插件系统变量

  • 密码验证插件状态变量

密码验证组件系统变量

如果启用了validate_password组件，则会公开几个系统变量，以便配置密码检查：

mysql> SHOW VARIABLES LIKE 'validate_password.%';
+-------------------------------------------------+--------+
| Variable_name                                   | Value  |
+-------------------------------------------------+--------+
| validate_password.changed_characters_percentage | 0      |
| validate_password.check_user_name               | ON     |
| validate_password.dictionary_file               |        |
| validate_password.length                        | 8      |
| validate_password.mixed_case_count              | 1      |
| validate_password.number_count                  | 1      |
| validate_password.policy                        | MEDIUM |
| validate_password.special_char_count            | 1      |
+-------------------------------------------------+--------+

要更改密码检查的方式，您可以在服务器启动时或运行时设置这些系统变量。以下列表描述了每个变量的含义。

  • validate_password.changed_characters_percentage

    命令行格式 --validate-password.changed-characters-percentage[=value]
    引入版本 8.0.34
    系统变量 validate_password.changed_characters_percentage
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 整数
    默认值 0
    最小值 0
    最大值 100

    表示用户在更改现有密码时必须更改的密码中的字符数的最小数量，作为所有字符的百分比，以便validate_password接受用户自己帐户的新密码。这仅适用于更改现有密码时，在设置用户帐户的初始密码时没有影响。

    除非安装了validate_password，否则此变量不可用。

    默认情况下，validate_password.changed_characters_percentage 允许在新密码中重复使用当前密码中的所有字符。有效百分比范围为 0 到 100。如果设置为 100%，则拒绝使用当前密码中的所有字符，不考虑大小写。字符 'abc' 和 'ABC' 被视为相同字符。如果 validate_password 拒绝新密码，则会报告一个错误，指示必须有多少个字符不同。

    如果 ALTER USER 语句未在 REPLACE 子句中提供现有密码，则不会强制执行此变量。是否需要 REPLACE 子句取决于密码验证策略适用于特定帐户。有关策略概述，请参阅 密码验证-必需策略。

  • validate_password.check_user_name

    命令行格式 --validate-password.check-user-name[={OFF|ON}]
    系统变量 validate_password.check_user_name
    作用范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 布尔值
    默认值 ON

    validate_password 是否将密码与当前会话的有效用户帐户的用户名部分进行比较，并在匹配时拒绝密码。此变量仅在安装了 validate_password 时才可用。

    默认情况下，validate_password.check_user_name 已启用。该变量控制用户名称匹配，与 validate_password.policy 的值无关。

    当启用 validate_password.check_user_name 时，会产生以下影响：

    • 检查发生在调用 validate_password 的所有上下文中，包括使用诸如 ALTER USER 或 SET PASSWORD 来更改当前用户密码的语句，以及调用诸如 VALIDATE_PASSWORD_STRENGTH() 的函数。

    • 用于比较的用户名取自当前会话的 USER() 和 CURRENT_USER() 函数的值。一个含义是，具有足够权限设置另一个用户密码的用户可以将密码设置为该用户的名称，并且不能将该用户的密码设置为执行语句的用户的名称。例如，'root'@'localhost' 可以将 'jeffrey'@'localhost' 的密码设置为 'jeffrey'，但不能将密码设置为 'root。

    • 仅使用 USER() 和 CURRENT_USER() 函数值的用户名部分，而不使用主机名部分。如果用户名为空，则不进行比较。

    • 如果密码与用户名相同或其反转，则会发生匹配，密码将被拒绝。

    • 用户名匹配区分大小写。密码和用户名值按字节逐字节比较为二进制字符串。

    • 如果密码与用户名匹配，VALIDATE_PASSWORD_STRENGTH() 返回 0，无论如何设置其他 validate_password 系统变量。

  • validate_password.dictionary_file

    命令行格式 --validate-password.dictionary-file=file_name
    系统变量 validate_password.dictionary_file
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 文件名

    字典文件的路径名，validate_password 用于检查密码。除非安装了 validate_password，否则此变量不可用。

    默认情况下，此变量的值为空，不执行字典检查。要执行字典检查，变量值必须非空。如果文件命名为相对路径，则解释为相对于服务器数据目录。文件内容应为小写，每行一个单词。内容被视为具有字符集 utf8mb3。允许的最大文件大小为 1MB。

    为了在检查密码期间使用字典文件，密码策略必须设置为 2 (STRONG)；请参阅 validate_password.policy 系统变量的描述。假设是真的，密码的每个长度为 4 到 100 的子字符串将与字典文件中的单词进行比较。任何匹配都会导致密码被拒绝。比较不区分大小写。

    对于VALIDATE_PASSWORD_STRENGTH()，密码将根据所有策略进行检查，包括STRONG，因此强度评估将包括字典检查，无论validate_password.policy的值如何。

    validate_password.dictionary_file 可以在运行时设置，分配一个值会导致读取命名文件而无需重新启动服务器。

  • validate_password.length

    命令行格式 --validate-password.length=#
    系统��量 validate_password.length
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 8
    最小值 0

    validate_password要求密码中包含的最小字符数。除非安装了validate_password，否则此变量不可用。

    validate_password.length 的最小值是几个其他相关系统变量的函数。该值不能设置为小于以下表达式的值：

    validate_password.number_count
+ validate_password.special_char_count
+ (2 * validate_password.mixed_case_count)

    如果validate_password由于前面的约束调整了validate_password.length的值，则会将消息写入错误日志。

  • validate_password.mixed_case_count

    命令行格式 --validate-password.mixed-case-count=#
    系统变量 validate_password.mixed_case_count
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1
    最小值 0

    如果密码策略为MEDIUM或更强，validate_password要求密码中包含的小写和大写字符的最小数量。除非安装了validate_password，否则此变量不可用。

    对于给定的validate_password.mixed_case_count值，密码必须具有相同数量的小写字符和大写字符。

  • validate_password.number_count

    命令行格式 --validate-password.number-count=#
    系统变量 validate_password.number_count
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1
    最小值 0

    validate_password要求密码具有的数字（数字）字符的最小数量，如果密码策略为MEDIUM或更强。除非安装了validate_password，否则此变量不可用。

  • validate_password.policy

    命令行格式 --validate-password.policy=value
    系统变量 validate_password.policy
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 枚举
    默认值 1
    有效值 0``1``2

    由validate_password强制执行的密码策略。除非安装了validate_password，否则此变量不可用。

    validate_password.policy影响validate_password如何使用其其他设置策略的系统变量，除了检查密码是否与用户名匹配，这是由validate_password.check_user_name独立控制的。

    可以使用数值 0、1、2 或相应的符号值LOW、MEDIUM、STRONG来指定validate_password.policy的值。以下表格描述了每个策略执行的测试。对于长度测试，所需长度是validate_password.length系统变量的值。类似地，其他测试的所需值由其他validate_password.*xxx*变量给出。

    策略 执行的测试
    0 或 LOW 长度
    1 或 MEDIUM 长度；数字、小写/大写字母和特殊字符
    2 或 STRONG 长度；数字、小写/大写字母和特殊字符；字典文件

  • validate_password.special_char_count

    命令行格式 --validate-password.special-char-count=#
    系统变量 validate_password.special_char_count
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 1
    最小值 0

    如果密码策略为MEDIUM或更强时，validate_password要求密码具有的最小非字母数字字符数。除非安装了validate_password，否则此变量不可用。

密码验证组件状态变量

如果启用了validate_password组件，则会公开提供操作信息的状态变量：

mysql> SHOW STATUS LIKE 'validate_password.%';
+-----------------------------------------------+---------------------+
| Variable_name                                 | Value               |
+-----------------------------------------------+---------------------+
| validate_password.dictionary_file_last_parsed | 2019-10-03 08:33:49 |
| validate_password.dictionary_file_words_count | 1902                |
+-----------------------------------------------+---------------------+

以下列表描述了每个状态变量的含义。

  • validate_password.dictionary_file_last_parsed

    上次解析字典文件的时间。除非安装了validate_password，否则此变量不可用。

  • validate_password.dictionary_file_words_count

    从字典文件中读取的单词数量。除非安装了validate_password，否则此变量不可用。

密码验证插件选项

注意

在 MySQL 8.0 中，validate_password插件被重新实现为validate_password组件。validate_password插件已被弃用；预计在未来的 MySQL 版本中将其移除。因此，其选项也已被弃用，您应该预期它们也将被移除。使用插件的 MySQL 安装应该过渡到使用组件。参见第 8.4.3.3 节，“过渡到密码验证组件”。

使用此选项来控制validate_password插件的激活：

  • --validate-password[=*value*]

    命令行格式 --validate-password[=value]
    类型 枚举
    默认值 ON
    有效数值 ON``OFF``FORCE``FORCE_PLUS_PERMANENT

    此选项控制服务器在启动时如何加载已弃用的validate_password插件。该值应为插件加载选项中可用的值之一，如第 7.6.1 节，“安装和卸载插件”中所述。例如，--validate-password=FORCE_PLUS_PERMANENT告诉服务器在启动时加载插件，并防止在服务器运行时将其移除。

    只有在之前使用INSTALL PLUGIN注册了validate_password插件或者使用--plugin-load-add加载了该插件时，此选项才可用。参见第 8.4.3.1 节，“密码验证组件的安装和卸载”。

密码验证插件系统变量

注意

在 MySQL 8.0 中，validate_password插件被重新实现为validate_password组件。validate_password插件已被弃用；预计在 MySQL 的未来版本中将被移除。因此，其系统变量也已被弃用，您应该预期它们也将被移除。改用validate_password组件的相应系统变量；请参阅密码验证组件系统变量。使用插件的 MySQL 安装应该过渡到使用组件。请参阅第 8.4.3.3 节，“过渡到密码验证组件”。

  • validate_password_check_user_name

    命令行格式 --validate-password-check-user-name[={OFF|ON}]
    系统变量 validate_password_check_user_name
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 布尔
    默认值 ON

    此validate_password插件系统变量已被弃用；预计在 MySQL 的未来版本中将被移除。请改用validate_password组件的相应validate_password.check_user_name系统变量。

  • validate_password_dictionary_file

    命令行格式 --validate-password-dictionary-file=file_name
    系统变量 validate_password_dictionary_file
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 文件名

    此validate_password插件系统变量已被弃用；预计在 MySQL 的未来版本中将被移除。请改用validate_password组件的相应validate_password.dictionary_file系统变量。

  • validate_password_length

    命令行格式 --validate-password-length=#
    系统变量 validate_password_length
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 整数
    默认值 8
    最小值 0

    此 validate_password 插件系统变量已被弃用；预计在 MySQL 的未来版本中将被移除。请改用 validate_password 组件的相应 validate_password.length 系统变量。

  • validate_password_mixed_case_count

    命令行格式 --validate-password-mixed-case-count=#
    系统变量 validate_password_mixed_case_count
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 整数
    默认值 1
    最小值 0

    此 validate_password 插件系统变量已被弃用；预计在 MySQL 的未来版本中将被移除。请改用 validate_password 组件的相应 validate_password.mixed_case_count 系统变量。

  • validate_password_number_count

    命令行格式 --validate-password-number-count=#
    系统变量 validate_password_number_count
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 整数
    默认值 1
    最小值 0

    此 validate_password 插件系统变量已被弃用；预计在 MySQL 的未来版本中将被移除。请改用 validate_password 组件的相应 validate_password.number_count 系统变量。

  • validate_password_policy

    命令行格式 --validate-password-policy=value
    系统变量 validate_password_policy
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 枚举
    默认值 1
    有效值 0``1``2

    此 validate_password 插件系统变量已被弃用；预计在 MySQL 的未来版本中将被移除。请改用 validate_password 组件的相应 validate_password.policy 系统变量。

  • validate_password_special_char_count

    命令行格式 --validate-password-special-char-count=#
    系统变量 validate_password_special_char_count
    范围 全局
    动态 是
    SET_VAR 提示适用 否
    类型 整数
    默认值 1
    最小值 0

    此validate_password插件系统变量已被弃用；预计将在 MySQL 的未来版本中移除。请改用validate_password组件的相应validate_password.special_char_count系统变量。

密码验证插件状态变量

注意

在 MySQL 8.0 中，validate_password插件被重新实现为validate_password组件。validate_password插件已被弃用；预计将在 MySQL 的未来版本中移除。因此，其状态变量也已被弃用；预计将被移除。请使用validate_password组件的相应状态变量；请参阅密码验证组件状态变量。使用插件的 MySQL 安装应该过渡到使用组件。请参阅第 8.4.3.3 节，“过渡到密码验证组件”。

  • validate_password_dictionary_file_last_parsed

    此validate_password插件状态变量已被弃用；预计将在 MySQL 的未来版本中移除。请改用validate_password组件的相应validate_password.dictionary_file_last_parsed状态变量。

  • validate_password_dictionary_file_words_count

    此validate_password插件状态变量已被弃用；预计将在 MySQL 的未来版本中移除。请改用validate_password组件的相应validate_password.dictionary_file_words_count状态变量。

原文：dev.mysql.com/doc/refman/8.0/en/validate-password-transitioning.html

8.4.3.3 过渡到密码验证组件

注意

在 MySQL 8.0 中，validate_password插件被重新实现为validate_password组件。validate_password插件已被弃用；预计将在 MySQL 的未来版本中删除。

目前使用validate_password插件的 MySQL 安装应该过渡到使用validate_password组件。为此，请使用以下过程。该过程在卸载插件之前安装组件，以避免出现没有密码验证发生的时间窗口。（组件和插件可以同时安装。在这种情况下，服务器尝试使用组件，如果组件不可用，则退回到插件。）

  1. 安装validate_password组件：

    INSTALL COMPONENT 'file://component_validate_password';

  2. 测试validate_password组件以确保其按预期工作。如果需要设置任何validate_password.*xxx*系统变量，可以使用SET GLOBAL在运行时执行。（必须进行的任何选项文件更改在下一步中执行。）

  3. 调整任何引用插件系统和状态变量的引用，以引用相应的组件系统和状态变量。假设以前您使用类似于以下选项文件在启动时配置插件：

    [mysqld]
validate-password=FORCE_PLUS_PERMANENT
validate_password_dictionary_file=/usr/share/dict/words
validate_password_length=10
validate_password_number_count=2

    那些设置适用于插件，但必须修改以适用于组件。要调整选项文件，请省略--validate-password选项（仅适用于插件，而不是组件），并将系统变量引用从适用于插件的无点名称修改为适用于组件的有点名称：

    [mysqld]
validate_password.dictionary_file=/usr/share/dict/words
validate_password.length=10
validate_password.number_count=2

    对于在运行时引用validate_password插件系统和状态变量的应用程序，需要进行类似的调整。将无点插件变量名称更改为相应的有点组件变量名称。

  4. 卸载validate_password插件：

    UNINSTALL PLUGIN validate_password;

    如果在服务器启动时使用--plugin-load或--plugin-load-add选项加载validate_password插件，请从服务器启动过程中省略该选项。例如，如果该选项在服务器选项文件中列出，请从文件中删除。

  5. 重新启动服务器。

8.4.4 MySQL 密钥环

原文：dev.mysql.com/doc/refman/8.0/en/keyring.html

8.4.4.1 密钥环组件与密钥环插件的比较

8.4.4.2 密钥环组件安装

8.4.4.3 密钥环插件安装

8.4.4.4 使用 component_keyring_file 基于文件的密钥环组件

8.4.4.5 使用 component_keyring_encrypted_file 加密文件密钥环组件

8.4.4.6 使用 keyring_file 基于文件的密钥环插件

8.4.4.7 使用 keyring_encrypted_file 加密文件密钥环插件

8.4.4.8 使用 keyring_okv KMIP 插件

8.4.4.9 使用 keyring_aws 亚马逊 Web 服务密钥环插件

8.4.4.10 使用 HashiCorp Vault 密钥环插件

8.4.4.11 使用 Oracle Cloud 基础设施 Vault 密钥环组件

8.4.4.12 使用 Oracle Cloud 基础设施 Vault 密钥环插件

8.4.4.13 支持的密钥环密钥类型和长度

8.4.4.14 迁移密钥

8.4.4.15 通用密钥环密钥管理功能

8.4.4.16 插件特定的密钥环密钥管理功能

8.4.4.17 密钥环元数据

8.4.4.18 密钥环命令选项

8.4.4.19 密钥环系统变量

MySQL 服务器支持一个密钥环，使内部服务器组件和插件能够安全地存储敏感信息以供以后检索。该实现包括以下元素：

  • 管理支持存储或与存储后端通信的密钥环组件和插件。密钥环的使用涉及从可用组件和插件中安装一个。密钥环组件和插件都管理密钥环数据，但配置不同，可能存在操作上的差异（参见第 8.4.4.1 节，“密钥环组件与密钥环插件”）。

    这些密钥环组件可用：

    • component_keyring_file: 将密钥环数据存储在服务器主机的本地文件中。从 MySQL 8.0.24 版本开始，可在 MySQL 社区版和 MySQL 企业版发行版中使用。参见第 8.4.4.4 节，“使用 component_keyring_file 基于文件的密钥环组件”。

    • component_keyring_encrypted_file: 将密钥环数据存储在服务器主机本地的加密、受密码保护的文件中。自 MySQL 8.0.24 起在 MySQL 企业版发行版中可用。参见 Section 8.4.4.5, “使用 component_keyring_encrypted_file 加密文件型密钥环组件”。

    • component_keyring_oci：将密钥环数据存储在 Oracle Cloud 基础设施 Vault 中。自 MySQL 8.0.31 起在 MySQL 企业版发行版中可用。参见 Section 8.4.4.11, “使用 Oracle Cloud 基础设施 Vault 密钥环组件”。

    可用的密钥环插件包括：

    • keyring_file（自 MySQL 8.0.34 起弃用）：将密钥环数据存储在服务器主机本地的文件中。在 MySQL 社区版和 MySQL 企业版发行版中可用。参见 Section 8.4.4.6, “使用 keyring_file 文件型密钥环插件”。

    • keyring_encrypted_file（自 MySQL 8.0.34 起弃用）：将密钥环数据存储在服务器主机本地的加密、受密码保护的文件中。在 MySQL 企业版发行版中可用。参见 Section 8.4.4.7, “使用 keyring_encrypted_file 加密文件型密钥环插件”。

    • keyring_okv：用于与支持 KMIP 的后端密钥环存储产品（如 Oracle Key Vault 和 Gemalto SafeNet KeySecure Appliance）一起使用的 KMIP 1.1 插件。在 MySQL 企业版发行版中可用。参见 Section 8.4.4.8, “使用 keyring_okv KMIP 插件”。

    • keyring_aws：与亚马逊 Web 服务密钥管理服务通信，用于密钥生成并使用本地文件进行密钥存储。在 MySQL 企业版发行版中可用。参见 Section 8.4.4.9, “使用 keyring_aws 亚马逊 Web 服务密钥环插件”。

    • keyring_hashicorp：与 HashiCorp Vault 通信，用于后端存储。自 MySQL 8.0.18 起在 MySQL 企业版发行版中可用。参见 Section 8.4.4.10, “使用 HashiCorp Vault 密钥环插件”。

    • keyring_oci（自 MySQL 8.0.31 起弃用）：与 Oracle Cloud 基础设施 Vault 通信，用于后端存储。自 MySQL 8.0.22 起在 MySQL 企业版发行版中可用。参见 Section 8.4.4.12, “使用 Oracle Cloud 基础设施 Vault 密钥环插件”。

  • 用于 keyring 密钥管理的 keyring 服务接口。此服务可在两个级别访问：

    • SQL 接口：在 SQL 语句中，调用 Section 8.4.4.15, “General-Purpose Keyring Key-Management Functions” 中描述的函数。

    • C 接口：在 C 语言代码中，调用 Section 7.6.9.2, “The Keyring Service” 中描述的 keyring 服务函数。

  • 密钥元数据访问：

    • Performance Schema keyring_keys 表公开了 keyring 中密钥的元数据。密钥元数据包括密钥 ID、密钥所有者和后端密钥 ID。keyring_keys 表不公开任何敏感的 keyring 数据，如密钥内容。自 MySQL 8.0.16 版本起可用。参见 Section 29.12.18.2, “The keyring_keys table”。

    • Performance Schema keyring_component_status 表提供了关于正在使用的 keyring 组件的状态信息，如果已安装。自 MySQL 8.0.24 版本起可用。参见 Section 29.12.18.1, “The keyring_component_status Table”。

  • 密钥迁移功能。MySQL 支持在密钥库之间迁移密钥，使得 DBA 可以将 MySQL 安装从一个密钥库切换到另一个。参见 Section 8.4.4.14, “Migrating Keys Between Keyring Keystores”。

  • 从 MySQL 8.0.24 版本开始，keyring 插件的实现已经修订为使用组件基础架构。这是通过使用名为 daemon_keyring_proxy_plugin 的内置插件来实现的，该插件充当插件和组件服务 API 之间的桥梁。参见 Section 7.6.8, “The Keyring Proxy Bridge Plugin”。

警告

对于加密密钥管理，component_keyring_file 和 component_keyring_encrypted_file 组件，以及 keyring_file 和 keyring_encrypted_file 插件并不是用作合规性解决方案。诸如 PCI、FIPS 等安全标准要求使用密钥管理系统来在密钥库或硬件安全模块（HSM）中安全、管理和保护加密密钥。

在 MySQL 中，keyring 服务的消费者包括：

  • InnoDB 存储引擎使用 keyring 存储其表空间加密的密钥。参见 Section 17.13, “InnoDB Data-at-Rest Encryption”。

  • MySQL 企业审计使用密钥环存储审计日志文件加密密码。请参见加密审计日志文件。

  • 二进制日志和中继日志管理支持基于密钥环的日志文件加密。启用日志文件加密后，密钥环存储用于加密二进制日志文件和中继日志文件密码的密钥。请参见第 19.3.2 节，“加密二进制日志文件和中继日志文件”。

  • 解密持久化敏感系统变量的文件密钥的主密钥存储在密钥环中。MySQL 服务器实例必须启用密钥环组件以支持对持久化系统变量值进行安全存储，而不是使用不支持该功能的密钥环插件。请参见持久化敏感系统变量。

有关一般密钥环安装说明，请参见第 8.4.4.2 节，“密钥环组件安装”和第 8.4.4.3 节，“密钥环插件安装”。有关特定密钥环组件或插件的安装和配置信息，请参见描述该组件的部分。

有关使用密钥环函数的信息，请参见第 8.4.4.15 节，“通用密钥环密钥管理函数”。

密钥环组件、插件和函数访问提供与密钥环接口的密钥环服务。有关访问此服务和编写密钥环插件的信息，请参见第 7.6.9.2 节，“密钥环服务”和编写密钥环插件。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-component-plugin-comparison.html

8.4.4.1 密钥环组件与密钥环插件

MySQL Keyring 最初使用服务器插件实现了密钥库功能，但从 MySQL 8.0.24 开始开始过渡到使用组件基础架构。本节简要比较了密钥环组件和插件，以提供它们之间差异的概述。这可能有助于您从插件过渡到组件，或者如果您刚开始使用密钥环，则有助于您选择是使用组件还是插件。

  • 密钥环插件加载使用 --early-plugin-load 选项。密钥环组件加载使用清单。

  • 密钥环插件配置基于特定于插件的系统变量。对于密钥环组件，不使用系统变量。相反，每个组件都有自己的配置文件。

  • 与密钥环插件相比，密钥环组件在密钥类型和长度方面的限制较少。请参阅第 8.4.4.13 节，“支持的密钥环密钥类型和长度”。

    注意

    component_keyring_oci（类似于keyring_oci插件）只能生成类型为AES且大小为 16、24 或 32 字节的密钥。

  • 密钥环组件支持对持久化系统变量值进行安全存储，而密钥环插件不支持该功能。

    必须在 MySQL 服务器实例上启用密钥环组件，以支持对持久化系统变量值进行安全存储。以这种方式可以保护的敏感数据包括出现在系统变量值中的私钥和密码等项目。在存储持久化系统变量的操作系统文件中，敏感系统变量的名称和值以加密格式存储，以及用于解密它们的生成文件密钥。生成的文件密钥又使用存储在密钥环中的主密钥进行加密。请参阅持久化敏感系统变量。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-component-installation.html

8.4.4.2 密钥环组件安装

密钥环服务使用者要求必须安装密钥环组件或插件：

  • 若要使用密钥环组件，请从这里的说明开始。

  • 若要使用密钥环插件，请从 Section 8.4.4.3, “Keyring Plugin Installation”开始。

  • 如果打算与所选的密钥环组件或插件一起使用密钥环函数，请在安装该组件或插件后安装这些函数，使用 Section 8.4.4.15, “General-Purpose Keyring Key-Management Functions”中的说明。

注意

一次只能启用一个密钥环组件或插件。启用多个密钥环组件或插件是不受支持的，结果可能不如预期。

MySQL 提供以下密钥环组件选择：

  • component_keyring_file: 将密钥环数据存储在服务器主机上的文件中。在 MySQL Community Edition 和 MySQL Enterprise Edition 发行版中可用。

  • component_keyring_encrypted_file: 将密钥环数据存储在服务器主机上的加密、受密码保护的文件中。在 MySQL Enterprise Edition 发行版中可用。

  • component_keyring_oci: 将密钥环数据存储在 Oracle Cloud Infrastructure Vault 中。在 MySQL Enterprise Edition 发行版中可用。

要供服务器使用，组件库文件必须位于 MySQL 插件目录中（由 plugin_dir 系统变量命名的目录）。如有必要，在服务器启动时通过设置 plugin_dir 的值来配置插件目录位置。

必须在服务器启动序列的早期加载密钥环组件或插件，以便其他组件在它们自己的初始化过程中可以根据需要访问它。例如，InnoDB 存储引擎使用密钥环进行表空间加密，因此必须在 InnoDB 初始化之前加载并可用密钥环组件或插件。

注意

如果需要支持持久化系统变量值的安全存储，则必须在 MySQL 服务器实例上启用密钥环组件。密钥环插件不支持此功能。请参阅持久化敏感系统变量。

与密钥环插件不同，密钥环组件不是使用--early-plugin-load服务器选项加载或使用系统变量配置的。相反，服务器在启动期间使用清单确定要加载哪个密钥环组件，并且加载的组件在初始化时会查阅自己的配置文件。因此，要安装密钥环组件，您必须：

  1. 编写一个清单，告诉服务器要加载哪个密钥环组件。

  2. 为该密钥环组件编写一个配置文件。

安装密钥环组件的第一步是编写一个指示要加载哪个组件的清单。在启动期间，服务器会读取全局清单文件或与本地清单文件配对的全局清单文件：

  • 服务器将尝试从安装服务器的目录中读取其全局清单文件。

  • 如果全局清单文件指示使用本地清单文件，则服务器将尝试从数据目录读取其本地清单文件。

  • 尽管全局和本地清单文件位于不同的目录中，但文件名在两个位置都是mysqld.my。

  • 清单文件不存在并不是一个错误。在这种情况下，服务器不会尝试加载与文件相关联的任何组件。

本地清单文件允许为服务器的多个实例设置组件加载，以便每个服务器实例的加载指令特定于给定的数据目录实例。这使得不同的 MySQL 实例可以使用不同的密钥环组件。

服务器清单文件具有以下属性：

  • 清单文件必须采用有效的 JSON 格式。

  • 清单文件允许这些项：

    • "read_local_manifest"：此项仅允许在全局清单文件中。如果该项不存在，则服务器仅使用全局清单文件。如果该项存在，则其值为true或false，指示服务器是否应从本地清单文件中读取组件加载信息。

      如果全局清单文件中存在"read_local_manifest"项以及其他项，则服务器首先检查"read_local_manifest"项的值：

      • 如果值为false，服务器将处理全局清单文件中的其他项，并忽略本地清单文件。

      • 如果值为true，服务器将忽略全局清单文件中的其他项，并尝试读取本地清单文件。

    • "components"：此项指示要加载的组件。该项值是一个字符串，指定一个有效的组件 URN，例如"file://component_keyring_file"。组件 URN 以file://开头，并指示位于 MySQL 插件目录中实现组件的库文件的基本名称。

  • 服务器对清单文件的访问权限应为只读。例如，mysqld.my服务器清单文件可能由root拥有，并对root读/写，但对用于运行 MySQL 服务器的帐户应为只读。如果在启动期间发现清单文件对该帐户为读/写，则服务器会向错误日志写入警告，建议将文件设置为只读。

  • 数据库管理员有责任创建要使用的任何清单文件，并确保它们的访问模式和内容正确。如果发生错误，服务器启动将失败，管理员必须根据服务器错误日志中的诊断信息纠正任何问题。

根据前面的清单文件属性，要配置服务器以加载component_keyring_file，请在mysqld安装目录中创建一个名为mysqld.my的全局清单文件，并在数据目录中可选地创建一个名为mysqld.my的本地清单文件。以下说明描述了如何加载component_keyring_file。要加载不同的密钥环组件，请用其名称替换component_keyring_file。

  • 仅使用全局清单文件时，文件内容如下所示：

    {
  "components": "file://component_keyring_file"
}

    在mysqld安装的目录中创建此文件。

  • 或者，要使用全局和本地清单文件对，全局文件如下所示：

    {
  "read_local_manifest": true
}

    在mysqld安装的目录中创建此文件。

    本地文件如下所示：

    {
  "components": "file://component_keyring_file"
}

    在数据目录中创建此文件。

有了清单后，继续配置密钥环组件。要做到这一点，请查看您选择的密钥环组件的说明，以获取特定于该组件的配置说明：

  • component_keyring_file: 第 8.4.4.4 节，“使用基于文件的 component_keyring_file 密钥环组件”。

  • component_keyring_encrypted_file: 第 8.4.4.5 节，“使用基于文件的 component_keyring_encrypted_file 加密密钥环组件”。

  • component_keyring_oci: 第 8.4.4.11 节，“使用 Oracle Cloud 基础设施 Vault 密钥环组件”。

执行任何特定于组件的配置后，启动服务器。通过检查性能模式keyring_component_status表来验证组件安装：

mysql> SELECT * FROM performance_schema.keyring_component_status;
+---------------------+-------------------------------------------------+
| STATUS_KEY          | STATUS_VALUE                                    |
+---------------------+-------------------------------------------------+
| Component_name      | component_keyring_file                          |
| Author              | Oracle Corporation                              |
| License             | GPL                                             |
| Implementation_name | component_keyring_file                          |
| Version             | 1.0                                             |
| Component_status    | Active                                          |
| Data_file           | /usr/local/mysql/keyring/component_keyring_file |
| Read_only           | No                                              |
+---------------------+-------------------------------------------------+

Component_status值为Active表示组件初始化成功。

如果组件无法加载，服务器启动将失败。检查服务器错误日志以获取诊断信息。如果组件加载但由于配置问题而无法初始化，服务器将启动，但Component_status值为Disabled。检查服务器错误日志，纠正配置问题，并使用ALTER INSTANCE RELOAD KEYRING语句重新加载配置。

密钥环组件应该只能通过使用清单文件加载，而不是使用INSTALL COMPONENT语句加载。使用该语句加载的密钥环组件可能在服务器启动序列中的某些组件需要使用密钥环时太晚可用，比如InnoDB，因为它们在mysql.component系统表中注册并在后续服务器重启时自动加载。但mysql.component是一个InnoDB表，因此在InnoDB初始化后才能在启动时加载任何在其中命名的组件。

如果组件尝试访问密钥环服务时没有可用的密钥环组件或插件，该服务将无法被该组件使用。因此，该组件可能无法初始化或以有限功能初始化。例如，如果InnoDB在初始化时发现有加密表空间，它会尝试访问密钥环。如果密钥环不可用，InnoDB只能访问未加密的表空间。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-plugin-installation.html

8.4.4.3 Keyring Plugin Installation

Keyring 服务的使用者要求安装一个 keyring 组件或插件：

  • 若要使用 keyring 插件，请从这里的说明开始。（此外，有关安装插件的一般信��，请参见 Section 7.6.1, “Installing and Uninstalling Plugins”。)

  • 若要使用 keyring 组件，请从 Section 8.4.4.2, “Keyring Component Installation”开始。

  • 如果您打算与所选的 keyring 组件或插件一起使用 keyring 函数，请在安装该组件或插件后安装函数，使用 Section 8.4.4.15, “General-Purpose Keyring Key-Management Functions”中的说明。

注意

一次只能启用一个 keyring 组件或插件。不支持启用多个 keyring 组件或插件，结果可能不如预期。

如果您需要支持持久化系统变量值的安全存储，而不是支持该功能的 keyring 插件，则必须在 MySQL Server 实例上启用 keyring 组件。请参阅 Persisting Sensitive System Variables。

MySQL 提供以下 keyring 插件选择：

  • keyring_file（自 MySQL 8.0.34 起已弃用）：将 keyring 数据存储在服务器主机本地的文件中。在 MySQL Community Edition 和 MySQL Enterprise Edition 发行版中可用。有关安装替代此插件的组件的说明，请参见 Section 8.4.4.2, “Keyring Component Installation”。

  • keyring_encrypted_file（自 MySQL 8.0.34 起已弃用）：将 keyring 数据存储在服务器主机本地的加密、受密码保护的文件中。仅在 MySQL Enterprise Edition 发行版中可用。有关安装替代此插件的组件的说明，请参见 Section 8.4.4.2, “Keyring Component Installation”。

  • keyring_okv：用于与 KMIP 兼容的后端 keyring 存储产品（如 Oracle Key Vault 和 Gemalto SafeNet KeySecure Appliance）一起使用的 KMIP 1.1 插件。仅在 MySQL Enterprise Edition 发行版中可用。

  • keyring_aws：与亚马逊 Web 服务密钥管理服务通信，用于密钥生成的后端，并使用本地文件进行密钥存储。仅在 MySQL Enterprise Edition 发行版中可用。

  • keyring_hashicorp：与 HashiCorp Vault 通信，用于后端存储。仅在 MySQL Enterprise Edition 发行版中可用。

  • keyring_oci（自 MySQL 8.0.31 起已弃用）：与 Oracle Cloud 基础设施 Vault 进行后端存储通信。请参阅第 8.4.4.12 节，“使用 Oracle Cloud 基础设施 Vault 密钥环插件”。

要让服务器能够使用插件库文件，插件库文件必须位于 MySQL 插件目录中（由plugin_dir系统变量命名的目录）。如果需要，通过在服务器启动时设置plugin_dir的值来配置插件目录位置。

密钥环组件或插件必须在服务器启动序列的早期加载，以便其他组件在其自身初始化期间根据需要访问它。例如，InnoDB 存储引擎使用密钥环进行表空间加密，因此必须在 InnoDB 初始化之前加载并可用密钥环组件或插件。

每个密钥环插件的安装方式类似。以下说明描述了如何安装keyring_file。要使用不同的密钥环插件，请将其名称替换为keyring_file。

keyring_file插件库文件基本名称为keyring_file。文件名后缀因平台而异（例如，Unix 和类 Unix 系统为.so，Windows 为.dll）。

要加载插件，请使用--early-plugin-load选项来命名包含插件库文件的插件。例如，在插件库文件后缀为.so的平台上，请在服务器my.cnf文件中使用以下行，根据需要调整.so后缀以适应您的平台：

[mysqld]
early-plugin-load=keyring_file.so

在启动服务器之前，请查看您选择的密钥环插件的注意事项，以获取特定于该插件的配置说明：

  • keyring_file: 第 8.4.4.6 节，“使用基于文件的 keyring_file 插件”。

  • keyring_encrypted_file: 第 8.4.4.7 节，“使用加密文件的 keyring_encrypted_file 插件”。

  • keyring_okv: 第 8.4.4.8 节，“使用 keyring_okv KMIP 插件”。

  • keyring_aws: 第 8.4.4.9 节，“使用 keyring_aws 亚马逊网络服务密钥环插件”

  • keyring_hashicorp: 第 8.4.4.10 节，“使用 HashiCorp Vault 密钥环插件”

  • keyring_oci: 第 8.4.4.12 节，“使用 Oracle Cloud 基础设施 Vault 密钥环插件”

在执行任何特定于插件的配置后，启动服务器。通过检查信息模式PLUGINS表或使用SHOW PLUGINS语句（参见 Section 7.6.2, “Obtaining Server Plugin Information”）来验证插件安装。例如：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
       FROM INFORMATION_SCHEMA.PLUGINS
       WHERE PLUGIN_NAME LIKE 'keyring%';
+--------------+---------------+
| PLUGIN_NAME  | PLUGIN_STATUS |
+--------------+---------------+
| keyring_file | ACTIVE        |
+--------------+---------------+

如果插件初始化失败，请检查服务器错误日志以获取诊断消息。

插件可以通过--early-plugin-load之外的方法加载，例如--plugin-load或--plugin-load-add选项或INSTALL PLUGIN语句。然而，使用这些方法加载的密钥环插件可能在服务器启动序列中对于某些使用密钥环的组件来说太晚了，比如InnoDB：

  • 使用--plugin-load或--plugin-load-add进行插件加载发生在InnoDB初始化之后。

  • 使用INSTALL PLUGIN安装的插件会在mysql.plugin系统表中注册，并在后续服务器重新启动时自动加载。然而，由于mysql.plugin是一个InnoDB表，其中列出的任何插件只能在InnoDB初始化后的启动期间加载。

如果在组件尝试访问密钥环服务时没有可用的密钥环组件或插件，则该服务无法被该组件使用。因此，该组件可能无法初始化或以有限功能初始化。例如，如果InnoDB在初始化时发现存在加密表空间，它会尝试访问密钥环。如果密钥环不可用，InnoDB只能访问未加密的表空间。为确保InnoDB也可以访问加密表空间，请使用--early-plugin-load加载密钥环插件。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-file-component.html

8.4.4.4 使用基于文件的密钥环组件

component_keyring_file密钥环组件将密钥环数据存储在服务器主机本地的文件中。

警告

对于加密密钥管理，component_keyring_file和component_keyring_encrypted_file组件，以及keyring_file和keyring_encrypted_file插件并不是用作符合法规的解决方案。PCI、FIPS 等安全标准要求使用密钥管理系统来保护、管理和保护密钥库或硬件安全模块（HSM）中的加密密钥。

要使用component_keyring_file进行密钥库管理，您必须：

  1. 按照 8.4.4.2 节“密钥环组件安装”中描述的方式编写一个清单，告诉服务器加载component_keyring_file。

  2. 按照这里的描述为component_keyring_file编写一个配置文件。

当初始化时，component_keyring_file会读取全局配置文件，或者全局配置文件与本地配置文件配对：

  • 该组件尝试从组件库文件安装的目录（即服务器插件目录）中读取其全局配置文件。

  • 如果全局配置文件指示使用本地配置文件，组件将尝试从数据目录中读取其本地配置文件。

  • 尽管全局和本地配置文件位于不同的目录中，但文件名在两个位置都是component_keyring_file.cnf。

  • 如果不存在配置文件，则无法初始化component_keyring_file。没有有效配置是一个错误。

本地配置文件允许设置多个服务器实例使用component_keyring_file，以便每个服务器实例的组件配置特定于给定的数据目录实例。这使得相同的密钥环组件可以与每个实例的不同数据文件一起使用。

component_keyring_file配置文件具有以下属性：

  • 配置文件必须是有效的 JSON 格式。

  • 配置文件允许设置这些配置项：

    • "read_local_config"：此项仅允许在全局配置文件中。如果该项不存在，则组件仅使用全局配置文件。如果该项存在，则其值为true或false，指示组件是否应从本地配置文件中读取配置信息。

      如果全局配置文件中存在"read_local_config"项以及其他项，则组件首先检查"read_local_config"项的值：

      • 如果值为false，组件将处理全局配置文件中的其他项并忽略本地配置文件。

      • 如果数值为true，组件将忽略全局配置文件中的其他项，并尝试读取本地配置文件。

    • "path"：项目值是一个字符串，用于命名用于存储密钥环数据的文件。文件应使用绝对路径而不是相对路径命名。此项目在配置中是强制性的。如果未指定，则component_keyring_file初始化失败。

    • "read_only"：项目值指示密钥环数据文件是否为只读。项目值为true（只读）或false（读/写）。此项目在配置中是强制性的。如果未指定，则component_keyring_file初始化失败。

  • 数据库管理员有责任创建要使用的任何配置文件，并确保其内容正确。如果发生错误，服务器启动将失败，并且管理员必须根据服务器错误日志中的诊断信息纠正任何问题。

鉴于前述配置文件属性，要配置component_keyring_file，请在安装了component_keyring_file库文件的目录中创建一个名为component_keyring_file.cnf的全局配置文件，并在数据目录中创建一个名为component_keyring_file.cnf的本地配置文件（可选）。以下说明假定要以读/写方式使用名为/usr/local/mysql/keyring/component_keyring_file的密钥环数据文件。

  • 要仅使用全局配置文件，文件内容如下所示：

    {
  "path": "/usr/local/mysql/keyring/component_keyring_file",
  "read_only": false
}

    在安装了component_keyring_file库文件的目录中创建此文件。

  • 或者，要使用全局和本地配置文件对，全局文件如下所示：

    {
  "read_local_config": true
}

    在安装了component_keyring_file库文件的目录中创建此文件。

    本地文件如下所示：

    {
  "path": "/usr/local/mysql/keyring/component_keyring_file",
  "read_only": false
}

    在数据目录中创建此文件。

密钥环操作是事务性的：component_keyring_file在写操作期间使用备份文件，以确保如果操作失败，可以回滚到原始文件。备份文件与数据文件具有相同的名称，后缀为.backup。

component_keyring_file支持组成标准 MySQL 密钥环服务接口的函数。这些函数执行的密钥环操作可在两个级别访问：

  • SQL 接口：在 SQL 语句中，调用第 8.4.4.15 节，“通用密钥环密钥管理函数”中描述的函数。

  • C 接口：在 C 语言代码中，调用第 7.6.9.2 节，“密钥环服务”中描述的密钥环服务函数。

示例（使用 SQL 接口）：

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

有关component_keyring_file允许的关键值特征的信息，请参阅第 8.4.4.13 节，“支持的钥匙环键类型和长度”。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-encrypted-file-component.html

8.4.4.5 使用 component_keyring_encrypted_file 加密文件型密钥环组件

注意

component_keyring_encrypted_file 是包含在 MySQL 企业版中的扩展，这是一个商业产品。要了解更多关于商业产品的信息，请参阅 www.mysql.com/products/。

component_keyring_encrypted_file 密钥环组件将密钥环数据存储在一个加密的、受密码保护的文件中，该文件位于服务器主机本地。

警告

对于加密密钥管理，component_keyring_file 和 component_keyring_encrypted_file 组件，以及 keyring_file 和 keyring_encrypted_file 插件并非旨在作为符合监管合规性的解决方案。诸如 PCI、FIPS 等安全标准要求使用密钥管理系统来保护、管理和保护密钥在密钥库或硬件安全模块（HSMs）中。

要使用 component_keyring_encrypted_file 进行密钥库管理，您必须：

  1. 编写一个清单，告诉服务器加载 component_keyring_encrypted_file，如 8.4.4.2 节“密钥环组件安装” 中所述。

  2. 编写一个 component_keyring_encrypted_file 的配置文件，如此处所述。

当初始化时，component_keyring_encrypted_file 会读取全局配置文件或与本地配置文件配对的全局配置文件：

  • 该组件尝试从组件库文件安装的目录（即服务器插件目录）中读取其全局配置文件。

  • 如果全局配置文件指示使用本地配置文件，则组件会尝试从数据目录中读取其本地配置文件。

  • 尽管全局和本地配置文件位于不同的目录中，但文件名在两个位置都是 component_keyring_encrypted_file.cnf。

  • 如果不存在预配置文件，则会出错。component_keyring_encrypted_file 在没有有效配置的情况下无法初始化。

本地配置文件允许设置多个服务器实例使用 component_keyring_encrypted_file，因此每个服务器实例的组件配置特定于给定的数据目录实例。这使得相同的密钥环组件可以与每个实例的不同数据文件一起使用。

component_keyring_encrypted_file 配置文件具有以下属性：

  • 配置文件必须是有效的 JSON 格式。

  • 配置文件允许这些配置项：

    • "read_local_config"：此项仅允许在全局配置文件中出现。如果该项不存在，则组件仅使用全局配置文件。如果该项存在，则其值为true或false，表示组件是否应从本地配置文件中读取配置信息。

      如果全局配置文件中存在"read_local_config"项以及其他项，则组件首先检查"read_local_config"项的值：

      • 如果值为false，组件将处理全局配置文件中的其他项，并忽略本地配置文件。

      • 如果值为true，组件将忽略全局配置文件中的其他项，并尝试读取本地配置文件。

    • "path"：该项值是一个指定用于存储密钥环数据的文件的字符串。文件应使用绝对路径而不是相对路径命名。此项在配置中是强制性的。如果未指定，component_keyring_encrypted_file初始化将失败。

    • "password"：该项值是一个指定访问数据文件密码的字符串。此项在配置中是强制性的。如果未指定，component_keyring_encrypted_file初始化将失败。

    • "read_only"：该项值指示密钥环数据文件是否为只读。该项值为true（只读）或false（读/写）。此项在配置中是强制性的。如果未指定，component_keyring_encrypted_file初始化将失败。

  • 数据库管理员有责任创建要使用的任何配置文件，并确保其内容正确。如果发生错误，服务器启动将失败，管理员必须根据服务器错误日志中的诊断信息纠正任何问题。

  • 存储密码的任何配置文件应具有限制模式，并且只能由用于运行 MySQL 服务器的帐户访问。

给定前述配置文件属性，要配置component_keyring_encrypted_file，请在安装component_keyring_encrypted_file库文件的目录中创建一个名为component_keyring_encrypted_file.cnf的全局配置文件，并可选择在数据目录中创建一个名为component_keyring_encrypted_file.cnf的本地配置文件。以下说明假定要使用一个名为/usr/local/mysql/keyring/component_keyring_encrypted_file的密钥环数据文件进行读/写操作。您还必须选择一个密码。

  • 要仅使用全局配置文件，文件内容如下所示：

    {
  "path": "/usr/local/mysql/keyring/component_keyring_encrypted_file",
  "password": "*password*",
  "read_only": false
}

    在安装component_keyring_encrypted_file库文件的目录中创建此文件。

  • 或者，要使用全局和本地配置文件对，全局文件如下所示：

    {
  "read_local_config": true
}

    在安装component_keyring_encrypted_file库文件的目录中创建此文件。

    本地文件如下所示：

    {
  "path": "/usr/local/mysql/keyring/component_keyring_encrypted_file",
  "password": "*password*",
  "read_only": false
}

    在数据目录中创建此文件。

密钥环操作是事务性的：component_keyring_encrypted_file在写操作期间使用备份文件，以确保如果操作失败，可以回滚到原始文件。备份文件与数据文件同名，后缀为.backup。

component_keyring_encrypted_file支持组成标准 MySQL 密钥环服务接口的函数。这些函数执行的密钥环操作可在两个级别访问：

  • SQL 接口：在 SQL 语句中，调用第 8.4.4.15 节，“通用密钥环密钥管理函数”中描述的函数。

  • C 接口：在 C 语言代码中，调用第 7.6.9.2 节，“密钥环服务”中描述的密钥环服务函数。

示例（使用 SQL 接口）：

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

有关component_keyring_encrypted_file允许的密钥值特性的信息，请参阅第 8.4.4.13 节，“支持的密钥环密钥类型和长度”。

dev.mysql.com/doc/refman/8.0/en/keyring-file-plugin.html

8.4.4.6 使用基于文件的 keyring_file 密钥环插件

keyring_file 密钥环插件将密钥环数据存储在服务器主机上的一个文件中。

截至 MySQL 8.0.34 版本，此插件已被弃用，并可能在将来的 MySQL 版本中被移除。相反，考虑使用 component_keyring_file 组件来存储密钥环数据（参见 第 8.4.4.4 节，“使用 component_keyring_file 基于文件的密钥环组件”）。

警告

对于加密密钥管理，keyring_file 插件并不是一个符合监管合规性的解决方案。诸如 PCI、FIPS 等安全标准要求使用密钥管理系统来在密钥保险库或硬件安全模块（HSM）中安全、管理和保护加密密钥。

要安装 keyring_file，请使用 第 8.4.4.3 节，“密钥环插件安装” 中找到的一般说明，以及此处找到的特定于 keyring_file 的配置信息。

为了在服务器启动过程中可用，必须使用 --early-plugin-load 选项加载 keyring_file。keyring_file_data 系统变量可选地配置 keyring_file 插件用于数据存储的文件位置。默认值是特定于平台的。要显式配置文件位置，请在启动时设置变量值。例如，在服务器的 my.cnf 文件中使用以下行，根据需要调整 .so 后缀和文件位置：

[mysqld]
early-plugin-load=keyring_file.so
keyring_file_data=/usr/local/mysql/mysql-keyring/keyring

密钥环操作是事务性的：keyring_file 插件在写操作期间使用备份文件，以确保如果操作失败，可以回滚到原始文件。备份文件的名称与 keyring_file_data 系统变量的值相同，后缀为 .backup。

有关 keyring_file_data 的更多信息，请参阅 第 8.4.4.19 节，“密钥环系统变量”。

为了确保只有在正确的密钥环存储文件存在时才刷新密钥，keyring_file 在文件中存储了密钥环的 SHA-256 校验和。在更新文件之前，插件会验证文件是否包含预期的校验和。

keyring_file 插件支持组成标准 MySQL 密钥环服务接口的函数。这些函数执行的密钥环操作可在两个级别访问：

  • SQL 接口：在 SQL 语句中，调用第 8.4.4.15 节，“通用密钥环密钥管理函数”中描述的函数。

  • C 接口：在 C 语言代码中，调用第 7.6.9.2 节，“密钥环服务”中描述的密钥环服务函数。

示例（使用 SQL 接口）：

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

有关keyring_file允许的密钥值特性的信息，请参阅第 8.4.4.13 节，“支持的密钥环密钥类型和长度”。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-encrypted-file-plugin.html

8.4.4.7 使用 keyring_encrypted_file 加密文件型密钥环插件

注意

keyring_encrypted_file 插件是包含在 MySQL 企业版中的一个扩展，这是一个商业产品。要了解更多关于商业产品的信息，请参见 www.mysql.com/products/。

keyring_encrypted_file 密钥环插件将密钥环数据存储在一个加密的、受密码保护的文件中，该文件位于服务器主机本地。

截至 MySQL 8.0.34 版本，该插件已被弃用，并可能在未来的 MySQL 版本中被移除。相反，考虑使用 component_encrypted_keyring_file 组件来存储密钥环数据（参见 Section 8.4.4.5, “Using the component_keyring_encrypted_file Encrypted File-Based Keyring Component”）。

警告

对于加密密钥管理，keyring_encrypted_file 插件并不是一个旨在符合监管合规性的解决方案。安全标准如 PCI、FIPS 等要求使用密钥管理系统来保护、管理和保护密钥库或硬件安全模块（HSM）中的加密密钥。

要安装 keyring_encrypted_file，请使用在 Section 8.4.4.3, “Keyring Plugin Installation” 中找到的一般说明，以及在此处找到的特定于 keyring_encrypted_file 的配置信息。

为了在服务器启动过程中可用，keyring_encrypted_file 必须使用 --early-plugin-load 选项加载。要为加密密钥环数据文件指定密码，请设置 keyring_encrypted_file_password 系统变量。（密码是必需的；如果在服务器启动时未指定，keyring_encrypted_file 初始化将失败。）keyring_encrypted_file_data 系统变量可选地配置 keyring_encrypted_file 插件用于数据存储的文件位置。默认值是特定于平台的。要显式配置文件位置，请在启动时设置变量值。例如，在服务器 my.cnf 文件中使用这些行，根据需要调整 .so 后缀和文件位置以适应您的平台，并替换您选择的密码：

[mysqld]
early-plugin-load=keyring_encrypted_file.so
keyring_encrypted_file_data=/usr/local/mysql/mysql-keyring/keyring-encrypted
keyring_encrypted_file_password=*password*

因为 my.cnf 文件在写入时会存储密码，所以应该具有限制模式，并且只能被用来运行 MySQL 服务器的账户访问。

Keyring 操作是事务性的：keyring_encrypted_file插件在写操作期间使用备份文件，以确保如果操作失败，可以回滚到原始文件。备份文件的名称与keyring_encrypted_file_data系统变量的值相同，后缀为.backup。

有关用于配置keyring_encrypted_file插件的系统变量的附加信息，请参阅 Section 8.4.4.19, “Keyring 系统变量”。

为确保仅在存在正确的 keyring 存储文件时才刷新密钥，keyring_encrypted_file在文件中存储了密钥环的 SHA-256 校验和。在更新文件之前，插件会验证文件是否包含预期的校验和。此外，keyring_encrypted_file在写入文件之前使用 AES 加密文件内容，并在读取文件后解密文件内容。

keyring_encrypted_file插件支持组成标准 MySQL Keyring 服务接口的函数。这些函数执行的 Keyring 操作可在两个级别访问：

  • SQL 接口：在 SQL 语句中，调用 Section 8.4.4.15, “通用 Keyring 密钥管理函数”中描述的函数。

  • C 接口：在 C 语言代码中，调用 Section 7.6.9.2, “Keyring 服务”中描述的 keyring 服务函数。

示例（使用 SQL 接口）：

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

有关keyring_encrypted_file允许的关键值特征的信息，请参阅 Section 8.4.4.13, “支持的 Keyring 密钥类型和长度”。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-okv-plugin.html

8.4.4.8 使用 keyring_okv KMIP 插件

注意

keyring_okv插件是包含在 MySQL 企业版中的扩展，这是一款商业产品。要了解更多关于商业产品的信息，请参阅www.mysql.com/products/。

密钥管理互操作性协议（KMIP）使密钥管理服务器和其客户端之间能够通信。keyring_okv密钥环插件使用 KMIP 1.1 协议作为 KMIP 后端的客户端进行安全通信。密钥材料仅由后端生成，而不是由keyring_okv生成。该插件与以下支持 KMIP 的产品配合使用：

  • Oracle Key Vault

  • Gemalto SafeNet KeySecure Appliance

  • Townsend Alliance Key Manager

  • Entrust KeyControl

每个 MySQL 服务器实例必须单独注册为 KMIP 的客户端。如果两个或更多 MySQL 服务器实例使用相同的凭据集，它们可能会干扰彼此的功能。

keyring_okv插件支持组成标准 MySQL 密钥环服务接口的功能。这些功能执行的密钥环操作可在两个级别访问：

  • SQL 接口：在 SQL 语句中，调用第 8.4.4.15 节“通用密钥环密钥管理功能”中描述的函数。

  • C 接口：在 C 语言代码中，调用第 7.6.9.2 节“密钥环服务”中描述的密钥环服务函数。

示例（使用 SQL 接口）：

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

有关keyring_okv允许的密钥值特性的信息，请参阅第 8.4.4.13 节“支持的密钥环密钥类型和长度”。

要安装keyring_okv，请使用第 8.4.4.3 节“密钥环插件安装”中的通用说明，以及此处找到的特定于keyring_okv的配置信息。

  • 通用 keyring_okv 配置

  • 为 Oracle Key Vault 配置 keyring_okv

  • 为 Gemalto SafeNet KeySecure Appliance 配置 keyring_okv

  • 为 Townsend Alliance Key Manager 配置 keyring_okv

  • 为 Entrust KeyControl 配置 keyring_okv

  • 保护 keyring_okv 密钥文件的密码

一般 keyring_okv 配置

无论keyring_okv插件使用哪个 KMIP 后端进行密钥存储，keyring_okv_conf_dir系统变量都配置了keyring_okv用于其支持文件的目录位置。默认值为空，因此必须在插件能够与 KMIP 后端通信之前设置变量以命名一个正确配置的目录。否则，keyring_okv在服务器启动期间向错误日志写入一条消息，说明无法通信：

[Warning] Plugin keyring_okv reported: 'For keyring_okv to be
initialized, please point the keyring_okv_conf_dir variable to a directory
containing Oracle Key Vault configuration file and ssl materials'

keyring_okv_conf_dir变量必须命名一个包含以下项目的目录：

  • okvclient.ora：包含keyring_okv与之通信的 KMIP 后端详细信息的文件。

  • ssl：包含用于与 KMIP 后端建立安全连接所需的证书和密钥文件的目录：CA.pem、cert.pem和key.pem。如果密钥文件受密码保护，ssl目录可以包含一个名为password.txt的单行文本文件，其中包含解密密钥文件所需的密码。

keyring_okv正常工作需要okvclient.ora文件和包含证书和密钥文件的ssl目录。用于将这些文件填充到配置目录的过程取决于与keyring_okv一起使用的 KMIP 后端，如其他地方所述。

由keyring_okv用作其支持文件位置的配置目录应具有严格的模式，并且只能由用于运行 MySQL 服务器的帐户访问。例如，在 Unix 和类 Unix 系统上，要使用/usr/local/mysql/mysql-keyring-okv目录，以下命令（以root身份执行）创建目录并设置其模式和所有权：

cd /usr/local/mysql
mkdir mysql-keyring-okv
chmod 750 mysql-keyring-okv
chown mysql mysql-keyring-okv
chgrp mysql mysql-keyring-okv

要在服务器启动过程中可用，必须使用--early-plugin-load选项加载keyring_okv。此外，设置keyring_okv_conf_dir系统变量，告诉keyring_okv在哪里找到其配置目录。例如，在服务器my.cnf文件中使用以下行，根据需要调整平台的.so后缀和目录位置：

[mysqld]
early-plugin-load=keyring_okv.so
keyring_okv_conf_dir=/usr/local/mysql/mysql-keyring-okv

有关keyring_okv_conf_dir的更多信息，请参见第 8.4.4.19 节，“Keyring 系统变量”。

为 Oracle Key Vault 配置 keyring_okv

这里的讨论假定您熟悉 Oracle Key Vault。一些相关信息来源：

在 Oracle Key Vault 术语中，使用 Oracle Key Vault 存储和检索安全对象的客户端称为端点。要与 Oracle Key Vault 通信，必须注册为端点并通过下载和安装端点支持文件进行注册。请注意，必须为每个 MySQL Server 实例注册一个单独的端点。如果两个或更多个 MySQL Server 实例使用相同的端点，则它们可能会干扰彼此的功能。

以下过程简要总结了设置keyring_okv以与 Oracle Key Vault 一起使用的过程：

  1. 创建keyring_okv插件使用的配置目录。

  2. 在 Oracle Key Vault 中注册一个端点以获取注册令牌。

  3. 使用注册令牌获取okvclient.jar客户端软件下载。

  4. 安装客户端软件以填充包含 Oracle Key Vault 支持文件的keyring_okv配置目录。

使用以下过程配置keyring_okv和 Oracle Key Vault 一起工作。此描述仅概述了如何与 Oracle Key Vault 交互。有关详细信息，请访问Oracle Key Vault网站并查阅 Oracle Key Vault 管理员指南。

  1. 创建包含 Oracle Key Vault 支持文件的配置目录，并确保keyring_okv_conf_dir系统变量设置为该目录的名称（有关详细信息，请参阅通用 keyring_okv 配置）。

  2. 以具有系统管理员角色的用户身份登录到 Oracle Key Vault 管理控制台。

  3. 选择“端点”选项卡以到达端点页面。在端点页面上，点击“添加”。

  4. 提供所需的端点信息并点击“注册”。端点类型应为其他。成功注册将产生一个注册令牌。

  5. 从 Oracle Key Vault 服务器注销。

  6. 再次连接到 Oracle Key Vault 服务器，这次不需要登录。使用端点注册令牌进行注册并请求okvclient.jar软件下载。将此文件保存到您的系统中。

  7. 使用以下命令安装okvclient.jar文件（您必须具有 JDK 1.4 或更高版本）：

    java -jar okvclient.jar -d *dir_name* [-v]

    -d选项后面的目录名称是安装提取文件的位置。如果给出-v选项，则会产生日志信息，如果命令失败，这些信息可能会有用。

    当命令要求输入 Oracle Key Vault 端点密码时，请不要提供密码。而是按下Enter键。（结果是端点连接到 Oracle Key Vault 时不需要密码。）

    前面的命令会生成一个 okvclient.ora 文件，应该位于前面 java -jar 命令中 -d 选项指定的目录下的这个位置：

    install_dir/conf/okvclient.ora

    预期的文件内容包括类似于这样的行：

    SERVER=*host_ip*:*port_num*
STANDBY_SERVER=*host_ip*:*port_num*

    SERVER 变量是必需的，STANDBY_SERVER 变量是可选的。keyring_okv 插件尝试与由 SERVER 变量指定的主机上运行的服务器通信，如果失败则退回到 STANDBY_SERVER。

    注意

    如果现有文件不是这种格式，则创建一个新文件，其中包含前面示例中显示的行。此外，在运行 okvutil 命令之前，请考虑备份 okvclient.ora 文件。根据需要恢复文件。

    从 MySQL 8.0.29 开始，您可以指定多个备用服务器（最多 64 个）。如果这样做，keyring_okv 插件会迭代它们，直到建立连接，如果无法建立连接则会失败。要添加额外的备用服务器，请编辑 okvclient.ora 文件，将服务器的 IP 地址和端口号作为 STANDBY_SERVER 变量的值以逗号分隔的列表指定。例如：

    STANDBY_SERVER=*host_ip*:*port_num*,*host_ip*:*port_num*,*host_ip*:*port_num*,*host_ip*:*port_num*

    确保备用服务器列表保持简短、准确和最新，并删除不再有效的服务器。每次连接尝试都会等待 20 秒，因此长列表中存在无效服务器会显著影响 keyring_okv 插件的连接时间，从而影响服务器启动时间。

  8. 转到 Oracle Key Vault 安装程序目录，并通过运行此命令测试设置：

    okvutil/bin/okvutil list

    输出应该类似于这样：

    Unique ID                               Type            Identifier
255AB8DE-C97F-482C-E053-0100007F28B9	Symmetric Key	-
264BF6E0-A20E-7C42-E053-0100007FB29C	Symmetric Key	-

    对于一个全新的 Oracle Key Vault 服务器（一个没有任何密钥的服务器），输出看起来像这样，以表明保险库中没有密钥：

    no objects found

  9. 使用此命令从 okvclient.jar 文件中提取包含 SSL 材料的 ssl 目录：

    jar xf okvclient.jar ssl

  10. 将 Oracle Key Vault 支持文件（okvclient.ora 文件和 ssl 目录）复制到配置目录中。

  11. （可选）如果您希望对密钥文件进行密码保护，请使用 Password-Protecting the keyring_okv Key File 中的说明。

完成前述过程后，重新启动 MySQL 服务器。它会加载 keyring_okv 插件，并且 keyring_okv 使用其配置目录中的文件与 Oracle Key Vault 进行通信。

配置 keyring_okv 以适用于 Gemalto SafeNet KeySecure Appliance

Gemalto SafeNet KeySecure Appliance 使用 KMIP 协议（版本 1.1 或 1.2）。支持 KMIP 1.1 的 keyring_okv 密钥环插件可以使用 KeySecure 作为其 KMIP 后端进行密钥环存储。

使用以下步骤配置 keyring_okv 和 KeySecure 一起工作。描述仅总结了如何与 KeySecure 交互。有关详细信息，请参阅 KeySecure 用户指南 中的添加 KMIP 服务器部分。

  1. 创建包含 KeySecure 支持文件的配置目录，并确保 keyring_okv_conf_dir 系统变量设置为该目录的名称（有关详细信息，请参阅 通用 keyring_okv 配置）。

  2. 在配置目录中，创建一个名为 ssl 的子目录，用于存储所需的 SSL 证书和密钥文件。

  3. 在配置目录中，创建一个名为 okvclient.ora 的文件。它应具有以下格式：

    SERVER=*host_ip*:*port_num*
STANDBY_SERVER=*host_ip*:*port_num*

    例如，如果 KeySecure 在主机 198.51.100.20 上运行，并在端口 9002 上监听，同时也在备用主机 203.0.113.125 上运行，并在端口 8041 上监听，那么 okvclient.ora 文件如下所示：

    SERVER=198.51.100.20:9002
STANDBY_SERVER=203.0.113.125:8041

    从 MySQL 8.0.29 开始，您可以指定多个备用服务器（最多 64 个）。如果这样做，keyring_okv 插件会对它们进行迭代，直到建立连接，如果无法建立连接则会失败。要添加额外的备用服务器，请编辑 okvclient.ora 文件，将服务器的 IP 地址和端口号作为逗号分隔列表指定在 STANDBY_SERVER 变量的值中。例如：

    STANDBY_SERVER=*host_ip*:*port_num*,*host_ip*:*port_num*,*host_ip*:*port_num*,*host_ip*:*port_num*

    确保备用服务器列表保持简短、准确和最新，并删除不再有效的服务器。每次连接尝试都会等待 20 秒，因此长时间的无效服务器列表会显著影响 keyring_okv 插件的连接时间，从而影响服务器启动时间。

  4. 以具有证书颁发机构访问权限的管理员凭据登录到 KeySecure 管理控制台。

  5. 导航至安全性 >> 本地 CA 并创建本地证书颁发机构（CA）。

  6. 转到受信任的 CA 列表。选择默认并点击属性。然后选择受信任证书颁发机构列表的编辑并添加刚创建的 CA。

  7. 下载 CA 并将其保存在 ssl 目录中，文件名为 CA.pem。

  8. 导航至安全性 >> 证书请求并创建证书。然后您可以下载一个包含证书 PEM 文件的压缩 tar 文件。

  9. 从下载的文件中提取 PEM 文件。例如，如果文件名为 csr_w_pk_pkcs8.gz，请使用以下命令进行解压缩和解包：

    tar zxvf csr_w_pk_pkcs8.gz

    提取操作会生成两个文件：certificate_request.pem 和 private_key_pkcs8.pem。

  10. 使用此 openssl 命令解密私钥并创建名为 key.pem 的文件：

    openssl pkcs8 -in private_key_pkcs8.pem -out key.pem

  11. 将 key.pem 文件复制到 ssl 目录中。

  12. 将certificate_request.pem中的证书请求复制到剪贴板中。

  13. 导航至安全性 >> 本地 CA。选择之前创建的相同 CA（用于创建CA.pem文件的那个），然后点击签署请求。将剪贴板中的证书请求粘贴进去，选择客户端的证书目的（密钥环是 KeySecure 的客户端），然后点击签署请求。结果是在新页面中使用所选 CA 签署的证书。

  14. 将签署的证书复制到剪贴板，然后将剪贴板内容保存为名为cert.pem的文件，保存在ssl目录中。

  15. （可选）如果您希望对密钥文件进行密码保护，请使用密码保护 keyring_okv 密钥文件中的说明。

完成上述过程后，重新启动 MySQL 服务器。它会加载keyring_okv插件，并且keyring_okv会使用其配置目录中的文件与 KeySecure 进行通信。

配置用于 Townsend Alliance Key Manager 的keyring_okv

Townsend Alliance Key Manager 使用 KMIP 协议。keyring_okv密钥环插件可以使用 Alliance Key Manager 作为其 KMIP 后端进行密钥环存储。有关更多信息，请参见用于 MySQL 的 Alliance Key Manager。

配置用于 Entrust KeyControl 的keyring_okv

Entrust KeyControl 使用 KMIP 协议。keyring_okv密钥环插件可以使用 Entrust KeyControl 作为其 KMIP 后端进行密钥环存储。有关更多信息，请参见Oracle MySQL 和 Entrust KeyControl 与 nShield HSM 集成指南。

保护 keyring_okv 密钥文件的密码

您可以选择使用密码保护密钥文件，并提供包含密码的文件以启用密钥文件的解密。要这样做，请切换到ssl目录并执行以下步骤：

  1. 加密key.pem密钥文件。例如，使用以下命令，并在提示时输入加密密码：

    $> openssl rsa -des3 -in key.pem -out key.pem.new
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

  2. 将加密密码保存在名为password.txt的单行文本文件中，保存在ssl目录中。

  3. 验证加密密钥文件是否可以使用以下命令解密。解密后的文件应显示在控制台上：

    $> openssl rsa -in key.pem.new -passin file:password.txt

  4. 删除原始的key.pem文件，并将key.pem.new重命名为key.pem。

  5. 更改新的key.pem文件和password.txt文件的所有权和访问模式，以确保它们具有与ssl目录中其他文件相同的限制。

原文：dev.mysql.com/doc/refman/8.0/en/keyring-aws-plugin.html

8.4.4.9 使用 keyring_aws 亚马逊网络服务密钥环插件

注意

keyring_aws插件是 MySQL 企业版中包含的扩展，这是一个商业产品。要了解更多关于商业产品的信息，请参阅www.mysql.com/products/。

keyring_aws密钥环插件与亚马逊网络服务密钥管理服务（AWS KMS）通信，作为密钥生成的后端，并使用本地文件进行密钥存储。所有密钥材料均由 AWS 服务器独家生成，而不是由keyring_aws生成。

MySQL 企业版可以在 Red Hat Enterprise Linux、SUSE Linux Enterprise Server、Debian、Ubuntu、macOS 和 Windows 上与keyring_aws一起使用。MySQL 企业版不支持在以下平台上使用keyring_aws：

  • EL6

  • 通用 Linux（glibc2.12）

  • SLES 12（MySQL Server 5.7 之后的版本）

  • Solaris

这里的讨论假定您对 AWS 有一般了解，特别是对 KMS 有了解。一些相关信息来源：

以下各节提供了keyring_aws密钥环插件的配置和使用信息：

  • keyring_aws 配置

  • keyring_aws 操作

  • keyring_aws 凭据更改

keyring_aws 配置

要安装keyring_aws，请使用第 8.4.4.3 节中找到的一般说明，“密钥环插件安装”，以及此处找到的插件特定配置信息。

插件库文件包含keyring_aws插件和两个可加载函数，keyring_aws_rotate_cmk()和keyring_aws_rotate_keys()。

要配置keyring_aws，您必须获取一个提供与 AWS KMS 通信凭据的秘密访问密钥，并将其写入配置文件：

  1. 创建一个 AWS KMS 账户。

  2. 使用 AWS KMS 创建一个秘密访问密钥 ID 和秘密访问密钥。访问密钥用于验证您的身份及您的应用程序的身份。

  3. 使用 AWS KMS 账户创建一个 KMS 密钥 ID。在 MySQL 启动时，将keyring_aws_cmk_id系统变量设置为 CMK ID 值。此变量是强制性的，没有默认值。（如果需要，可以使用SET GLOBAL在运行时更改其值。）

  4. 如有必要，创建应放置配置文件的目录。该目录应具有限制模式，并且只能由用于运行 MySQL 服务器的帐户访问。例如，在 Unix 和类 Unix 系统上，要将/usr/local/mysql/mysql-keyring/keyring_aws_conf用作文件名，以下命令（以root身份执行）创建其父目录并设置目录模式和所有权：

    $> cd /usr/local/mysql
$> mkdir mysql-keyring
$> chmod 750 mysql-keyring
$> chown mysql mysql-keyring
$> chgrp mysql mysql-keyring

    在 MySQL 启动时，将keyring_aws_conf_file系统变量设置为/usr/local/mysql/mysql-keyring/keyring_aws_conf，以指示服务器配置文件的位置。

  5. 准备keyring_aws配置文件，其中应包含两行：

    • 第 1 行：秘密访问密钥 ID

    • 第 2 行：秘密访问密钥

    例如，如果密钥 ID 为wwwwwwwwwwwwwEXAMPLE，密钥为xxxxxxxxxxxxx/yyyyyyy/zzzzzzzzEXAMPLEKEY，则配置文件如下所示：

    wwwwwwwwwwwwwEXAMPLE
xxxxxxxxxxxxx/yyyyyyy/zzzzzzzzEXAMPLEKEY

在服务器启动过程中可用，必须使用--early-plugin-load选项加载keyring_aws。keyring_aws_cmk_id系统变量是必需的，并配置从 AWS KMS 服务器获取的 KMS 密钥 ID。keyring_aws_conf_file和keyring_aws_data_file系统变量可选地配置keyring_aws插件用于配置信息和数据存储的文件位置。文件位置变量的默认值是特定于平台的。要显式配置位置，请在启动时设置变量值。例如，在服务器my.cnf文件中使用这些行，根据需要调整.so后缀和文件位置：

[mysqld]
early-plugin-load=keyring_aws.so
keyring_aws_cmk_id='arn:aws:kms:us-west-2:111122223333:key/abcd1234-ef56-ab12-cd34-ef56abcd1234'
keyring_aws_conf_file=/usr/local/mysql/mysql-keyring/keyring_aws_conf
keyring_aws_data_file=/usr/local/mysql/mysql-keyring/keyring_aws_data

要成功启动keyring_aws插件，配置文件必须存在并包含有效的秘密访问密钥信息，如前所述初始化。存储文件不需要存在。如果不存在，keyring_aws会尝试创建它（以及必要时的父目录）。

有关用于配置keyring_aws插件的系统变量的更多信息，请参见第 8.4.4.19 节，“Keyring 系统变量”。

启动 MySQL 服务器并安装与keyring_aws插件关联的函数。这是一次性操作，通过执行以下语句执行，根据需要调整.so后缀以适应您的平台：

CREATE FUNCTION keyring_aws_rotate_cmk RETURNS INTEGER
  SONAME 'keyring_aws.so';
CREATE FUNCTION keyring_aws_rotate_keys RETURNS INTEGER
  SONAME 'keyring_aws.so';

有关keyring_aws函数的更多信息，请参见第 8.4.4.16 节，“插件特定的 Keyring 密钥管理函数”。

keyring_aws 操作

在插件启动时，keyring_aws 插件从其配置文件中读取 AWS 秘密访问密钥 ID 和密钥。它还将存储文件中包含的任何加密密钥读入其内存缓存中。

在运行过程中，keyring_aws 在内存缓存中维护加密密钥，并使用存储文件作为本地持久存储。每个 keyring_aws 操作都是事务性的：keyring_aws 要么成功地更改内存中的密钥缓存和密钥环存储文件，要么操作失败，密钥环状态保持不变。

为了确保仅在存在正确的密钥环存储文件时才刷新密钥，keyring_aws 在文件中存储密钥环的 SHA-256 校验和。在更新文件之前，插件会验证文件是否包含预期的校验和。

keyring_aws 插件支持组成标准 MySQL 密钥环服务接口的函数。通过这些函数执行的密钥环操作可在两个级别访问：

  • SQL 接口：在 SQL 语句中，调用 第 8.4.4.15 节，“通用密钥环密钥管理函数” 中描述的函数。

  • C 接口：在 C 语言代码中，调用 第 7.6.9.2 节，“密钥环服务” 中描述的密钥环服务函数。

示例（使用 SQL 接口）：

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

此外，keyring_aws_rotate_cmk() 和 keyring_aws_rotate_keys() 函数“扩展”了密钥环插件接口，提供了标准密钥环服务接口未涵盖的与 AWS 相关的功能。只能通过使用 SQL 调用这些函数来访问这些功能。没有相应的 C 语言密钥服务函数。

有关 keyring_aws 允许的密钥值特性的信息，请参阅 第 8.4.4.13 节，“支持的密钥环密钥类型和长度”。

keyring_aws 凭据更改

假设 keyring_aws 插件在服务器启动时已经正确初始化，可以更改用于与 AWS KMS 通信的凭据：

  1. 使用 AWS KMS 创建新的秘密访问密钥 ID 和秘密访问密钥。

  2. 将新凭据存储在配置文件中（由 keyring_aws_conf_file 系统变量命名的文件）。文件格式如前所述。

  3. 重新初始化 keyring_aws 插件，以便重新读取配置文件。假设新凭据有效，插件应该成功初始化。

    有两种重新初始化插件的方法：

    • 重新启动服务器。这更简单，没有副作用，但不适用于需要最小化服务器停机时间并尽可能少重启的安装。

    • 通过执行以下语句重新初始化插件，根据需要调整.so后缀以适应您的平台，而无需重新启动服务器：

      UNINSTALL PLUGIN keyring_aws;
INSTALL PLUGIN keyring_aws SONAME 'keyring_aws.so';

      注意

      除了在运行时加载插件外，INSTALL PLUGIN 还具有在 mysql.plugin 系统表中注册插件的副作用。因此，如果您决定停止使用keyring_aws，仅仅从用于启动服务器的选项集中删除--early-plugin-load选项是不够的。这样可以阻止插件早期加载，但服务器仍会在启动序列中加载在mysql.plugin中注册的插件。

      因此，如果您执行上述描述的UNINSTALL PLUGIN加INSTALL PLUGIN序列来更改 AWS KMS 凭据，那么要停止使用keyring_aws，需要再次执行UNINSTALL PLUGIN来取消注册插件，同时删除--early-plugin-load选项。

posted @ 2024-06-23 16:25  绝不原创的飞龙  阅读(7)  评论(0)  编辑  收藏  举报