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能正常返回结果再说。
