MySQL 8.0+ 原生不支持 LDAP 认证，需通过 authentication_pam 插件委托系统 PAM 实现；主流方案是配置 /etc/pam.d/mysqld 调用 pam_ldap.so，并创建 PAM 认证用户，认证由内核态 PAM 完成，MySQL 仅接收结果。
MySQL 8.0+ 原生不支持 LDAP 认证
MySQL 官方服务器（mysqld）本身不具备 LDAP 绑定或查询能力，无法像 PostgreSQL 那样通过 ldap_auth 插件直接对接 LDAP 服务器。所有“MySQL + LDAP”方案都依赖外部代理、PAM 或自定义认证插件实现，不存在开箱即用的内置集成路径。
主流可行方案：PAM 认证插件 + 系统级 LDAP 配置
MySQL 8.0 引入了 authentication_pam 插件，它把用户认证委托给操作系统的 PAM 框架，而 PAM 可通过 pam_ldap.so 或 pam_sss.so 对接 LDAP。这是目前最稳定、生产环境验证最多的路径。
实操关键点：
- 必须使用 MySQL 8.0+，且编译时启用了 PAM 支持（多数 Linux 发行版二进制包已默认启用）
- 需在系统层面配置好
/etc/pam.d/mysqld（或/etc/pam.d/mysql），指向正确的 LDAP 模块和参数 - MySQL 用户需用
CREATE USER 'alice'@'%' IDENTIFIED WITH authentication_pam AS 'mysql';创建，'mysql'是 PAM service name，对应 PAM 配置文件名 - LDAP 用户密码不存于 MySQL，也不经 MySQL 解析——整个认证流程由内核态 PAM 完成，MySQL 仅接收成功/失败信号
常见错误：PAM 日志无输出或始终返回 Access denied
典型现象是 MySQL 登录报 Access denied for user 'alice'@'192.168.1.100' (using password: YES)，但 LDAP 账户确认有效。根本原因几乎都出在 PAM 链路断开：
-
/etc/pam.d/mysqld文件缺失或权限不对（应为 644，且属 root:root） - PAM 配置中未启用
auth [success=done default=ignore]或误写 service name（如写成mysql但实际创建用户时用了'mysqld'） - SELinux 启用时拦截了 mysqld 访问 LDAP 端口（
setsebool -P authlogin_nsswitch_use_ldap on） - SSSD 配置中未设置
ldap_id_use_start_tls = True（若 LDAP 启用 LDAPS 或 StartTLS）
替代方案对比：ProxySQL vs 自研认证中间件
当无法修改操作系统 PAM（如容器化部署、云托管 MySQL 实例），可考虑协议层代理：
-
ProxySQL支持自定义mysql_users表 + 外部脚本调用 LDAP 查询，但需自行维护用户映射表和密码同步逻辑，且不支持 LDAP 组权限自动继承 - 基于
mysql-connector-python写轻量认证网关，监听 MySQL 协议握手阶段，拦截SSLRequest后转 LDAP bind，再透传连接；适合小规模场景，但无法处理 native password 加密协商细节，兼容性风险高 - 云厂商 RDS（如 AWS Aurora、阿里云 RDS）部分提供“企业版 LDAP 集成”，实则是其管控面在连接池层做了 LDAP 校验，底层 MySQL 仍无感知——这类方案不可迁移，且权限粒度受限于厂商接口
真正需要 LDAP 组到 MySQL 角色映射（例如将 LDAP 中 db-admins 组自动赋予 SUPER 权限），只能靠定期同步脚本 + GRANT 批量执行，没有实时联动机制。
