Linux配置LDAP服务端与客户端集成

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配置均无效。因此，建议先确保getent测试正常，再调整PAM设置。