我们有一个场景，本地 ldap 实际上会接收所有身份验证请求，然后在密码存储为 {SASL}username 时将身份验证传递给 SASLauthd 模块。因此，身份验证将在远程 openldap 上完成，而授权将在本地 openldap 实例上完成。
我们使用的是 Ubuntu 18 的默认 openldap 发行版，并且没有重建代码，因为 Debian 中的构建配置表明它已经使用 --enable-spasswd --with-cyrus-sasl 构建
/etc/saslauthd.conf根据建议做了如下更改
ldap_servers: ldaps://<remote ldap ip>:636
ldap_search_base: ou=Users,dc=example,dc=com
ldap_filter: (uid=%U)
ldap_bind_dn: cn=admin,dc=example,dc=com
ldap_password: <password>
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_auth_method: bind
ldap_version: 3
ldap_restart: yes
ldap_deref: never
然后/usr/lib/sasl2/slapd.conf添加以下内容。
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
确保 PLAIN 受支持的 sasl 机制。
ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: ANONYMOUS
然后按照建议在本地 LDAP 中为需要进行远程（直通）身份验证的用户 testuser 设置用户密码，并以 {SASL} 格式将密码以纯文本形式保存（不加密，甚至没有 SSHA）[电子邮件保护]因为我们没有使用保存为 {SASL}testuser 的域。检查 sasl 身份验证是否有效：
root@CS-IDAM-TEST1:~# testsaslauthd -u testuser -p <password in remote ldap>
0: OK "Success."
尽管如此，当我尝试以下形式的 ldapsearch 时：
ldapsearch -H ldap://localhost:389 -b "cn=username,ou=Users,dc=local,dc=com" -D "cn=username,ou=Users,dc=local,dc=com" -W "uid=testuser"
请求永远不会到达远程 ldap 以通过 SASL 进行身份验证（尝试使用 -x：无区别），而指向远程 openldap 的相同形式的 ldapsearch 可以完美运行。