与用户不同,它们不应该在目录树中具有相应的DN(以及密码).相反,他们的凭证应该存储在外部,因此SASL.
我现在正在使用saslauthd(例如,如果能够直接访问sasldb,这不是一个很难的要求)并且使用机制PLAIN和LOGIN可以正常工作,而它使用机制DIGEST-MD5和CRAM失败-MD5.
我错过了什么或做错了什么？如何让它与DIGEST-MD5一起使用？
在/etc/ldap/sasl2/slapd.conf中为SASL配置了OpenLDAP,如下所示：
mech_list: EXTERNAL DIGEST-MD5 CRAM-MD5 PLAIN LOGIN pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
/ etc / default / saslauthd中有趣的(已更改的)选项是：
START=yes MECHANISMS="sasldb"
他们导致saslauthd像这样开始：
/usr/sbin/saslauthd -a sasldb -c -m /var/run/saslauthd -n 5
我使用DIGEST-MD5重现失败的情况,如下所示：
# ldapsearch -U replication -ZZ -Y DIGEST-MD5 -H ldap://ldap-master.example.com/ -b "dc=example,dc=com" "(objectClass=*)"
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
slapd日志中似乎失败的部分(日志记录在其中)看起来像这样：
slapd[23330]: [rw] authid: "uid=replication,cn=digest-md5,cn=auth" -> "uid=replication,cn=auth" slapd[23330]: slap_parseURI: parsing uid=replication,cn=auth slapd[23330]: >>> dnNormalize: <uid=replication,cn=auth> slapd[23330]: <<< dnNormalize: <uid=replication,cn=auth> slapd[23330]: <==slap_sasl2dn: Converted SASL name to uid=replication,cn=auth slapd[23330]: slap_sasl_getdn: dn:id converted to uid=replication,cn=auth slapd[23330]: SASL Canonicalize [conn=1002]: slapAuthcDN="uid=replication,cn=auth" slapd[23330]: SASL [conn=1002] Failure: no secret in database slapd[23330]: SASL [conn=1002] Debug: DIGEST-MD5 common mech dispose slapd[23330]: send_ldap_result: conn=1002 op=2 p=3 slapd[23330]: send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database" slapd[23330]: send_ldap_response: msgid=3 tag=97 err=49
当我手动运行时,在/var/log/auth.log和saslauthd的调试输出中都没有任何内容,这可能表明slapd甚至没有将身份验证转交给saslauthd(与工作案例相比),见下文).
我使用PLAIN或LOGIN重现工作案例,如下所示：
# ldapsearch -U replication -ZZ -Y PLAIN -H ldap://ldap-master.example.com/ -b "dc=example,dc=com" "(objectClass=*)" SASL/PLAIN authentication started Please enter your password: SASL username: replication SASL SSF: 0 # extended LDIF …
slapd日志中指示上述情况失败的相应部分现在如下所示：
slapd[23330]: [rw] authid: "uid=replication,cn=plain,cn=auth slapd[23330]: SASL Canonicalize [conn=1006]: slapAuthcDN="uid=replication,cn=auth" slapd[23330]: daemon: activity on 1 descriptor slapd[23330]: daemon: activity on: slapd[23330]: slapd[23330]: daemon: epoll: listen=8 active_threads=0 tvp=zero slapd[23330]: daemon: epoll: listen=9 active_threads=0 tvp=zero slapd[23330]: daemon: epoll: listen=10 active_threads=0 tvp=zero slapd[23330]: SASL proxy authorize [conn=1006]: authcid="replication" authzid="replication" slapd[23330]: conn=1006 op=1 BIND authcid="replication" authzid="replication" slapd[23330]: SASL Authorize [conn=1006]: proxy authorization allowed authzDN="" slapd[23330]: send_ldap_sasl: err=0 len=-1 slapd[23330]: conn=1006 op=1 BIND dn="uid=replication,cn=auth" mech=PLAIN sasl_ssf=0 ssf=128 slapd[23330]: do_bind: SASL/PLAIN bind: dn="uid=replication,cn=auth" sasl_ssf=0 slapd[23330]: send_ldap_response: msgid=2 tag=97 err=0
/var/log/auth.log和saslauthd的调试输出现在都包含：
saslauthd[23354]: rel_accept_lock : released accept lock saslauthd[23358]: get_accept_lock : acquired accept lock saslauthd[23354]: cache_get_rlock : attempting a read lock on slot: 458 saslauthd[23354]: cache_lookup : [login=replication] [service=] [realm=ldap]: not found,update pending saslauthd[23354]: cache_un_lock : attempting to release lock on slot: 458 saslauthd[23354]: cache_get_wlock : attempting a write lock on slot: 458 saslauthd[23354]: cache_commit : lookup committed saslauthd[23354]: cache_un_lock : attempting to release lock on slot: 458 saslauthd[23354]: do_auth : auth success: [user=replication] [service=ldap] [realm=] [mech=sasldb] saslauthd[23354]: do_request : response: OK
显然,PLAIN和LOGIN与DIGEST-MD5和CRAM-MD5的工作原理必然存在差异.
更新和澄清：
用于授权访问树的DN分别是uid = replication,cn = digest-md5,cn = auth和uid = replication,cn = plain,cn = auth,根据http://www.openldap.org/doc/admin24/sasl.html的第15.2.5节,这些DN没有需要实际存在于树中(至少对于PLAIN和LOGIN必须是真的,因为它在那里工作正常).
出于测试目的,我目前正在使用olcAccess：to * by dn.regex =“replication”读取* break以确保复制登录至少获得对所有内容的读取权限(是的,我知道这不安全,我会给它正确的主LDAP树中的生产权限.
凭据位于/ etc / sasldb2中,使用PLAIN或LOGIN时会成功检查凭据(参见上文).作为参考,它看起来像这样：
# sasldblistusers2 replication@ldap-master: userPassword … # db_dump -p /etc/sasldb2 VERSION=3 format=print type=hash h_nelem=4 db_pagesize=4096 HEADER=END replication\00ldap-master\00userPassword PasswordCensored …
但是,在DIGEST-MD5和CRAM-MD5的情况下,它似乎根本没有联系saslauthd(由于我遗漏了某些东西或者做错了,可能),所以也可能没有咨询数据库.
