Linux系统中配置LDAP服务端与客户端集成完全教程

OpenLDAP slapd服务启动失败，十有八九是slapd.d配置目录未正确初始化，或者文件权限设置不当。解决办法并不复杂——先停掉服务、备份旧配置、使用slaptest重建目录结构，再将所有权交给ldap用户。顺带提醒，olcSuffix和olcRootDN的格式必须规范且相互一致，否则后续还会出现各种麻烦。

slapd服务无法启动？检查slapd.d配置目录初始化与权限设置

OpenLDAP从2.4版本起，默认采用cn=config动态配置模式。如果仍试图直接编辑slapd.conf，系统自然不会生效。常见报错如“ldap_add: Invalid syntax (21)”，或直接启动失败——根本原因相同：配置目录未正确生成，或权限不到位。

• 先停止slapd服务：systemctl stop slapd
• 将旧配置目录备份：mv /etc/openldap/slapd.d /etc/openldap/slapd.d.bak
• 使用slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d重新生成配置结构（前提是slapd.conf存在且语法合法）
• 最后关键一步：chown -R ldap:ldap /etc/openldap/slapd.d，若遗忘此步，slapd进程将无法读取配置文件

olcSuffix和olcRootDN配置不一致导致ldapsearch返回“No such object”

客户端能连接却查不到数据，这是最常见的“软故障”。并非网络不通，而是服务端未正确声明管辖范围。olcSuffix必须与后续所有LDIF导入、客户端查询的Base DN完全一致，且dc=格式不能缺失。

• 编辑 /etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif
• olcSuffix取值必须是一个完整的域名形式，例如olcSuffix: dc=example,dc=com（切勿写成example.com或仅单个example）
• olcRootDN必须与olcSuffix匹配，正确写法：olcRootDN: cn=admin,dc=example,dc=com
• 修改后必须重启服务：systemctl restart slapd，再用slaptest -u验证语法是否正确

nslcd.conf中uri和base配置不匹配导致getent passwd失败

客户端能ping通服务器，ldapsearch -x -H ldap://192.168.10.5 -b "dc=example,dc=com"也能正常返回，但getent passwd输出为空——这种情况问题通常出在/etc/nslcd.conf。可能是uri与base不一致，或binddn/bindpw权限不足。

• uri必须包含协议和结尾斜杠：uri ldap://192.168.10.5/（漏掉斜杠会导致连接重定向失败）
• base必须与服务端olcSuffix完全一致：base dc=example,dc=com
• 若服务端启用了TLS，uri应写成ldaps://，并配置tls_cacertfile指向CA证书路径
• binddn需具备读取posixAccount和posixGroup条目的权限，通常直接使用olcRootDN

PAM加载pam_ldap.so后本地用户登录变慢或失败

添加pam_ldap.so后，连root用户登录都要等待十秒，甚至本地账户完全无法进入——这说明PAM链路将LDAP查询作为必选项，未设置fallback控制。

• 不要在auth [default=bad]这类严格模式下加载pam_ldap.so
• 推荐写法：auth [success=done default=ignore] pam_ldap.so use_first_pass ——LDAP认证成功则跳过后续模块，失败则忽略，继续走本地认证
• 务必确认/etc/pam.d/system-auth中该行位于pam_unix.so之前，否则本地密码校验会被跳过
• 如果只想让远程SSH使用LDAP，则将此行添加到/etc/pam.d/sshd，不要改动全局的system-auth

实际部署中最容易被忽略的，其实是slaptest -u和getent passwd这两个验证步骤。slaptest -u不通过，slapd不会加载配置；getent passwd不返回LDAP用户，后续所有PAM/NSS配置都是徒劳。因此不必急着调整PAM，先确保getent能正常返回结果再说。