启用mysql ldap认证前必须确认：一是版本与插件匹配（企业版用authentication_ldap_sasl，社区版用pam）；二是插件已启用且状态为active；三是ldap服务可达且支持simple bind。
MySQL 启用 LDAP 认证前必须确认的三件事
MySQL 本身不直接支持 LDAP 认证，必须通过 authentication_ldap_sasl 插件（企业版）或借助 PAM 中转（社区版常用）。你用的是哪个版本、是否已启用插件、LDAP 服务是否可达，这三者任一缺失都会导致“用户能连上但认证失败”或“ERROR 1045 (28000)”。
-
SHOW PLUGINS;查看authentication_ldap_sasl是否为ACTIVE（仅 MySQL Enterprise 8.0+ 支持） - 社区版请转向 PAM：确认系统已安装
pam_ldap或sssd，且/etc/pam.d/mysqld存在并配置正确 - LDAP 连通性不能只靠
ldapsearch测试 bind DN——MySQL 插件默认使用 simple bind，若 LDAP 服务器强制要求 STARTTLS 或证书校验，会静默失败
MySQL + PAM 认证的关键配置路径与权限陷阱
PAM 是社区版对接 LDAP 最可行的路径，但 MySQL 进程必须以能读取 PAM 配置和 LDAP 凭据的身份运行，且系统级 PAM 规则不能被 SELinux 或 AppArmor 拦截。
- MySQL 用户（通常是
mysql）必须属于shadow组，否则无法读取/etc/shadow（即使走 LDAP，PAM 模块仍可能触发本地 fallback 检查） -
/etc/pam.d/mysqld必须存在，内容类似：auth [success=done default=ignore] pam_ldap.so auth required pam_deny.so
——注意顺序，pam_deny.so是兜底拒绝，漏写会导致所有用户免密登录 - MySQL 启动时若报
Plugin 'auth_pam' is not loaded，不是插件没装，而是mysqld启动用户无权读/etc/pam.d/mysqld（检查ls -l /etc/pam.d/mysqld权限应为 644，属主 root）
创建 LDAP 用户时 CREATE USER 的两个硬约束
即使后端走 LDAP，MySQL 内部仍需声明用户，且用户名、认证插件、密码字段三者必须严格匹配 PAM/LDAP 行为，否则 ERROR 1045 或 Access denied for user 会反复出现。
- 用户名必须与 LDAP 中的
uid（或sAMAccountName）完全一致，大小写敏感——MySQL 不做标准化处理 - 必须显式指定插件：
CREATE USER 'jdoe'@'%' IDENTIFIED WITH auth_pam AS 'mysqld';
其中'mysqld'是/etc/pam.d/下的配置文件名（不含路径），拼错就找不到规则 -
IDENTIFIED BY不能带值——PAM 认证下该字段被忽略，填了反而干扰调试；若误写成IDENTIFIED BY 'xxx'，MySQL 会优先尝试本地密码验证，跳过 PAM
调试连接失败时最该看的三个日志位置
LDAP/PAM 认证失败几乎从不直接报 LDAP 错误，而是笼统提示“Access denied”，真正线索藏在系统日志里。MySQL 自身日志对 PAM 流程几乎不记录，别白费劲翻 error.log。
- Linux 系统日志：
journalctl -u mysqld -n 100 --no-pager | grep -i pam，重点找pam_ldap的 connect timeout、bind failed 或 no such user - LDAP 服务端日志（如 OpenLDAP 的
/var/log/slapd.log）：确认 MySQL 的 bind DN 是否有搜索权限，过滤条件是否匹配用户条目（例如(&(objectClass=posixAccount)(uid=jdoe))） - 临时开启 PAM 调试：在
/etc/pam.d/mysqld对应行末加debug，例如pam_ldap.so debug，然后查/var/log/secure
LDAP 属性映射、组权限继承、SSL 证书路径这些细节，全依赖你在 PAM 模块里的配置——MySQL 层面只管把用户名扔给 PAM，剩下的它不管。
