i've enabled the plain sasl mech, and testing with ldapwhoami works, but only if the userpassword is left as plaintext. if hashing [ssha] is used, it fails. a simple bind succeeds. what am i doing wrong?
ldapwhoami -H 'ldap://dsa4.example.com/' -Y 'plain' -U 'flash' -w
'xxxxxxxx' SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed
524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 slap_listener_activate(7): 524b7989 daemon: epoll: listen=7 busy 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 >>> slap_listener(ldap:///) 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 daemon: listen=7, new connection on 16 524b7989 daemon: added 16r (active) listener=(nil) 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 conn=1014 fd=16 ACCEPT from IP=192.168.1.81:35171 (IP=0.0.0.0:389) 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 16r524b7989 524b7989 daemon: read active on 16 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 connection_get(16) 524b7989 connection_get(16): got connid=1014 524b7989 connection_read(16): checking for input on id=1014 ber_get_next ldap_read: want=8, got=8 0000: 30 22 02 01 01 60 1d 02 0"...`..
ldap_read: want=28, got=28 0000: 01 03 04 00 a3 16 04 05 50 4c 41 49 4e 04 0d 00 ........PLAIN... 0010: 66 6c 61 73 68 00 74 69 67 67 65 72 flash.xxxxxxx ber_get_next: tag 0x30 len 34 contents: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103750 end=0x7f1580103772 len=34 0000: 02 01 01 60 1d 02 01 03 04 00 a3 16 04 05 50 4c ...`..........PL 0010: 41 49 4e 04 0d 00 66 6c 61 73 68 00 74 69 67 67 AIN...flash.xxxx 0020: 65 72 xxxxxx
524b7989 op tag 0x60, time 1380678025 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 524b7989 conn=1014 op=0 do_bind 524b7989 daemon: activity on 1 descriptor ber_scanf fmt ({imt) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103753 end=0x7f1580103772 len=31 0000: 60 1d 02 01 03 04 00 a3 16 04 05 50 4c 41 49 4e `..........PLAIN 0010: 04 0d 00 66 6c 61 73 68 00 74 69 67 67 65 72 ...flash.xxxxxxxx ber_scanf fmt ({m) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f158010375a end=0x7f1580103772 len=24 0000: 00 16 04 05 50 4c 41 49 4e 04 0d 00 66 6c 61 73 ....PLAIN...flas 0010: 68 00 74 69 67 67 65 72 h.xxxxxxxxx
ber_scanf fmt (m) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103763 end=0x7f1580103772 len=15 0000: 00 0d 00 66 6c 61 73 68 00 74 69 67 67 65 72 ...flash.xxxxxxx ber_scanf fmt (}}) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103772 end=0x7f1580103772 len=0
524b7989 >>> dnPrettyNormal: <> 524b7989 <<< dnPrettyNormal: <>, <> 524b7989 conn=1014 op=0 BIND dn="" method=163 524b7989 do_bind: dn () SASL mech PLAIN 524b7989 ==> sasl_bind: dn="" mech=PLAIN datalen=13 524b7989 SASL Canonicalize [conn=1014]: authcid="flash" 524b7989 slap_sasl_getdn: conn 1014 id=flash [len=5] => ldap_dn2bv(16) <= ldap_dn2bv(uid=flash,cn=PLAIN,cn=auth)=0 524b7989 slap_sasl_getdn: u:id converted to uid=flash,cn=PLAIN,cn=auth 524b7989 >>> dnNormalize: <uid=flash,cn=PLAIN,cn=auth> => ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth,0) <= ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,cn=plain,cn=auth)=0 524b7989 <<< dnNormalize: <uid=flash,cn=plain,cn=auth> 524b7989 ==>slap_sasl2dn: converting SASL name uid=flash,cn=plain,cn=auth to a DN 524b7989 ==> rewrite_context_apply [depth=1] string='uid=flash,cn=plain,cn=auth' 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=digest-md5,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=plain,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_context_apply [depth=1] res={0,'uid=flash,ou=people,ou=accounts,dc=example,dc=com'} 524b7989 [rw] authid: "uid=flash,cn=plain,cn=auth" -> "uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 slap_parseURI: parsing uid=flash,ou=people,ou=accounts,dc=example,dc=com ldap_url_parse_ext(uid=flash,ou=people,ou=accounts,dc=example,dc=com) 524b7989 >>> dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> => ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com,0) <= ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 524b7989 <<< dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> 524b7989 <==slap_sasl2dn: Converted SASL name to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 slap_sasl_getdn: dn:id converted to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 SASL Canonicalize [conn=1014]: slapAuthcDN="uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 SASL Canonicalize [conn=1014]: authcid="flash" 524b7989 slap_sasl_getdn: conn 1014 id=flash [len=5] => ldap_dn2bv(16) <= ldap_dn2bv(uid=flash,cn=PLAIN,cn=auth)=0 524b7989 slap_sasl_getdn: u:id converted to uid=flash,cn=PLAIN,cn=auth 524b7989 >>> dnNormalize: <uid=flash,cn=PLAIN,cn=auth> => ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth,0) <= ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,cn=plain,cn=auth)=0 524b7989 <<< dnNormalize: <uid=flash,cn=plain,cn=auth> 524b7989 ==>slap_sasl2dn: converting SASL name uid=flash,cn=plain,cn=auth to a DN 524b7989 ==> rewrite_context_apply [depth=1] string='uid=flash,cn=plain,cn=auth' 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=digest-md5,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=plain,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_context_apply [depth=1] res={0,'uid=flash,ou=people,ou=accounts,dc=example,dc=com'} 524b7989 [rw] authid: "uid=flash,cn=plain,cn=auth" -> "uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 slap_parseURI: parsing uid=flash,ou=people,ou=accounts,dc=example,dc=com ldap_url_parse_ext(uid=flash,ou=people,ou=accounts,dc=example,dc=com) 524b7989 >>> dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> => ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com,0) <= ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 524b7989 <<< dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> 524b7989 <==slap_sasl2dn: Converted SASL name to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 slap_sasl_getdn: dn:id converted to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 SASL Canonicalize [conn=1014]: slapAuthcDN="uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 => mdb_search 524b7989 mdb_dn2entry("uid=flash,ou=people,ou=accounts,dc=example,dc=com") 524b7989 => mdb_dn2id("uid=flash,ou=people,ou=accounts,dc=example,dc=com") 524b7989 <= mdb_dn2id: got id=0x2c 524b7989 => mdb_entry_decode: 524b7989 <= mdb_entry_decode 524b7989 => access_allowed: auth access to "uid=flash,ou=people,ou=accounts,dc=example,dc=com" "entry" requested 524b7989 => dn: [2] uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 => acl_get: [2] matched 524b7989 => acl_get: [2] attr entry 524b7989 => acl_mask: access to entry "uid=flash,ou=people,ou=accounts,dc=example,dc=com", attr "entry" requested 524b7989 => acl_mask: to all values by "", (=0) 524b7989 <= check a_dn_pat: self 524b7989 <= check a_dn_pat: users 524b7989 <= check a_dn_pat: anonymous 524b7989 <= acl_mask: [3] applying auth(=xd) (stop) 524b7989 <= acl_mask: [3] mask: auth(=xd) 524b7989 => slap_access_allowed: auth access granted by auth(=xd) 524b7989 => access_allowed: auth access granted by auth(=xd) 524b7989 base_candidates: base: "uid=flash,ou=people,ou=accounts,dc=example,dc=com" (0x0000002c) 524b7989 => test_filter 524b7989 daemon: activity on:524b7989 PRESENT 524b7989 => access_allowed: auth access to "uid=flash,ou=people,ou=accounts,dc=example,dc=com" "objectClass" requested 524b7989 => dn: [2] uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 => acl_get: [2] matched 524b7989 => acl_get: [2] attr objectClass 524b7989 => acl_mask: access to entry "uid=flash,ou=people,ou=accounts,dc=example,dc=com", attr "objectClass" requested 524b7989 => acl_mask: to all values by "", (=0) 524b7989 <= check a_dn_pat: self 524b7989 <= check a_dn_pat: users 524b7989 <= check a_dn_pat: anonymous 524b7989 <= acl_mask: [3] applying auth(=xd) (stop) 524b7989 <= acl_mask: [3] mask: auth(=xd) 524b7989 => slap_access_allowed: auth access granted by auth(=xd) 524b7989 => access_allowed: auth access granted by auth(=xd) 524b7989 <= test_filter 6 524b7989 => access_allowed: auth access to "uid=flash,ou=people,ou=accounts,dc=example,dc=com" "userPassword" requested 524b7989 => acl_get: [1] attr userPassword 524b7989 => acl_mask: access to entry "uid=flash,ou=people,ou=accounts,dc=example,dc=com", attr "userPassword" requested 524b7989 => acl_mask: to all values by "", (=0) 524b7989 <= check a_dn_pat: anonymous 524b7989 <= acl_mask: [1] applying auth(=xd) (stop) 524b7989 <= acl_mask: [1] mask: auth(=xd) 524b7989 => slap_access_allowed: auth access granted by auth(=xd) 524b7989 => access_allowed: auth access granted by auth(=xd) 524b7989 slap_ap_lookup: str2ad(cmusaslsecretPLAIN): attribute type undefined 524b7989 send_ldap_result: conn=1014 op=0 p=3 524b7989 send_ldap_result: err=0 matched="" text="" 524b7989 SASL [conn=1014] Failure: Password verification failed 524b7989 send_ldap_result: conn=1014 op=0 p=3 524b7989 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed" 524b7989 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 69 bytes to sd 16 0000: 30 43 02 01 01 61 3e 0a 01 31 04 00 04 37 53 41 0C...a>..1...7SA 0010: 53 4c 28 2d 31 33 29 3a 20 75 73 65 72 20 6e 6f SL(-13): user no 0020: 74 20 66 6f 75 6e 64 3a 20 50 61 73 73 77 6f 72 t found: Passwor 0030: 64 20 76 65 72 69 66 69 63 61 74 69 6f 6e 20 66 d verification f 0040: 61 69 6c 65 64 ailed
ldap_write: want=69, written=69 0000: 30 43 02 01 01 61 3e 0a 01 31 04 00 04 37 53 41 0C...a>..1...7SA 0010: 53 4c 28 2d 31 33 29 3a 20 75 73 65 72 20 6e 6f SL(-13): user no 0020: 74 20 66 6f 75 6e 64 3a 20 50 61 73 73 77 6f 72 t found: Passwor 0030: 64 20 76 65 72 69 66 69 63 61 74 69 6f 6e 20 66 d verification f 0040: 61 69 6c 65 64 ailed
524b7989 conn=1014 op=0 RESULT tag=97 err=49 text=SASL(-13): user not found: Password verification failed 524b7989 <== slap_sasl_bind: rc=49 524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 16r524b7989 524b7989 daemon: read active on 16 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 connection_get(16) 524b7989 connection_get(16): got connid=1014 524b7989 connection_read(16): checking for input on id=1014 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B.
ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x7f1584117620 ptr=0x7f1584117620 end=0x7f1584117625 len=5 0000: 02 01 02 42 00 ...B.
524b7989 op tag 0x42, time 1380678025 ber_get_next ldap_read: want=8, got=0
524b7989 ber_get_next on fd 16 failed errno=0 (Success) 524b7989 connection_read(16): input error=-2 id=1014, closing. 524b7989 connection_closing: readying conn=1014 sd=16 for close 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 connection_close: deferring conn=1014 sd=16 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 conn=1014 op=1 do_unbind 524b7989 conn=1014 op=1 UNBIND 524b7989 connection_resched: attempting closing conn=1014 sd=16 524b7989 connection_close: conn=1014 sd=16 524b7989 daemon: removing 16 524b7989 conn=1014 fd=16 closed
On 10/02/13 09:08 -0400, btb wrote:
i've enabled the plain sasl mech, and testing with ldapwhoami works, but only if the userpassword is left as plaintext. if hashing [ssha] is used, it fails. a simple bind succeeds. what am i doing wrong?
ldapwhoami -H 'ldap://dsa4.example.com/' -Y 'plain' -U 'flash' -w
'xxxxxxxx' SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed
524b7989 ==>slap_sasl2dn: converting SASL name uid=flash,cn=plain,cn=auth to a DN 524b7989 ==> rewrite_context_apply [depth=1] string='uid=flash,cn=plain,cn=auth' 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=digest-md5,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=plain,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_context_apply [depth=1] res={0,'uid=flash,ou=people,ou=accounts,dc=example,dc=com'} 524b7989 [rw] authid: "uid=flash,cn=plain,cn=auth" -> "uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 slap_parseURI: parsing uid=flash,ou=people,ou=accounts,dc=example,dc=com ldap_url_parse_ext(uid=flash,ou=people,ou=accounts,dc=example,dc=com) 524b7989 >>> dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> => ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com,0) <= ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 524b7989 <<< dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> 524b7989 <==slap_sasl2dn: Converted SASL name to uid=flash,ou=people,ou=accounts,dc=example,dc=com
libsasl2, with default configuration, requires that the password be stored in cleartext, even for PLAIN.
To support {ssha} in this scenario, I recommend you configure your SASL slapd.conf file to authenticate against saslauthd, which in turn should be configured to perform ldap simple (non-sasl) authentication against slapd. Think of it as a two-level deep recursive authentication.
Create a slapd.conf SASL file (e.g. /usr/lib/sasl2/slapd.conf) with these contents:
pwcheck_method: saslauthd # Disallow shared secret mechanisms mech_list: PLAIN LOGIN GSSAPI EXTERNAL
Run saslauthd with the ldap backend. Run in debug mode to trouble shoot. If slapd is running non-root, modify the permissions to the saslauthd mux (e.g. /var/run/saslauthd/mux) to allow slapd to access it.
See:
http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/components.php http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php The saslauthd manpage saslauthd/LDAP_SASLAUTHD (in the cyrus sasl source)
On Oct 2, 2013, at 09.44, Dan White dwhite@olp.net wrote:
libsasl2, with default configuration, requires that the password be stored in cleartext, even for PLAIN.
To support {ssha} in this scenario, I recommend you configure your SASL slapd.conf file to authenticate against saslauthd, which in turn should be configured to perform ldap simple (non-sasl) authentication against slapd. Think of it as a two-level deep recursive authentication.
Create a slapd.conf SASL file (e.g. /usr/lib/sasl2/slapd.conf) with these contents:
pwcheck_method: saslauthd # Disallow shared secret mechanisms mech_list: PLAIN LOGIN GSSAPI EXTERNAL
thanks, this worked. though the slapd/sasl recursive auth was a bit of a brain teaser to get straight in my head, if i'm honest. :)
a few follow up questions, if i may.
i'd like to, just for the sake of my own edification, understand the internal bits a little better. having gone through this exercise, if i understand correctly now, when a client connects to slapd and uses sasl, slapd hands over [so to speak] the authentication portion to libsasl2 in almost the same way any other server software which might be using libsasl2 does - even though slapd is likely to ultimately be the source of the authentication data? the one notable difference being that when the libsasl2 is used in its default state [e.g. pwcheck_method: auxprop], slapd knows to include/use a "special" internal auxprop module [auxprop_plugin: slapd - i see this referenced in doc/options.html]. this in turn allows slapd to, in essence, work "internally" to itself, but still within the constraints of libsasl2?
that came out a bit long winded, but i'm hoping i have the essence straight.
you mention "libsasl2, with default configuration, requires that the password be stored in cleartext, even for PLAIN.". was that just referring to the default of pwcheck_method: auxprop, or is there some scenario in which pwcheck_method: auxprop could be made to somehow handle hashed password values?
regarding using saslauthd in the mix with slapd/libsasl2, it seems that perhaps olcauthzregexp does not really apply any longer in this scenario? slapd does not need to itself canonicalize the username, as that work is done by the saslauthd ldap auth mechanism? removing the olcauthzregexp elements from my config seems to confirm this, but i'm wondering if there are other effects i've not considered.
lastly, i'm curious about some logging i see going to the syslog auth facility. when using pwcheck_method: saslauthd, i see the following logged when starting slapd:
Oct 7 21:26:12 aurora slapd[20228]: DIGEST-MD5 common mech free Oct 7 21:26:14 aurora slapd[20240]: auxpropfunc error invalid parameter supplied Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Oct 7 21:26:14 aurora slapd[20240]: canonuserfunc error -7 Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb Oct 7 21:26:14 aurora slapd[20240]: sql_select option missing Oct 7 21:26:14 aurora slapd[20240]: auxpropfunc error no mechanism available Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql
i understand from reading various ml discussions that those messages are largely innocuous, but was curious nonetheless why messages that seem to be related to auxprop appear if i've explicitly specified saslauthd. is auxprop still being used in some capacity?
similarly, before using saslauthd, when initially testing using pwcheck_method: auxprop, and setting auxprop_plugin: slapd, as per doc/options.html, i expected to no longer see the complaints about sql and ldapdd, yet they still appear. are my expectations regarding this off-base?
-ben
On 10/07/13 21:49 -0400, btb@bitrate.net wrote:
On Oct 2, 2013, at 09.44, Dan White dwhite@olp.net wrote:
libsasl2, with default configuration, requires that the password be stored in cleartext, even for PLAIN.
To support {ssha} in this scenario, I recommend you configure your SASL slapd.conf file to authenticate against saslauthd, which in turn should be configured to perform ldap simple (non-sasl) authentication against slapd. Think of it as a two-level deep recursive authentication.
Create a slapd.conf SASL file (e.g. /usr/lib/sasl2/slapd.conf) with these contents:
pwcheck_method: saslauthd # Disallow shared secret mechanisms mech_list: PLAIN LOGIN GSSAPI EXTERNAL
thanks, this worked. though the slapd/sasl recursive auth was a bit of a brain teaser to get straight in my head, if i'm honest. :)
a few follow up questions, if i may.
i'd like to, just for the sake of my own edification, understand the internal bits a little better. having gone through this exercise, if i understand correctly now, when a client connects to slapd and uses sasl, slapd hands over [so to speak] the authentication portion to libsasl2 in almost the same way any other server software which might be using libsasl2 does - even though slapd is likely to ultimately be the source of the authentication data? the one notable difference being that when the libsasl2 is used in its default state [e.g. pwcheck_method: auxprop], slapd knows to include/use a "special" internal auxprop module [auxprop_plugin: slapd - i see this referenced in doc/options.html]. this in turn allows slapd to, in essence, work "internally" to itself, but still within the constraints of libsasl2?
Right. libsasl2 authenticates, and the slapd auxprop plugin uses ldap as a database to retrieve authentication data (on behalf of libsasl2).
that came out a bit long winded, but i'm hoping i have the essence straight.
you mention "libsasl2, with default configuration, requires that the password be stored in cleartext, even for PLAIN.". was that just referring to the default of pwcheck_method: auxprop, or is there some scenario in which pwcheck_method: auxprop could be made to somehow handle hashed password values?
That was referring to auxprop. In newer versions (> 2.1.23) of Cyrus SASL there is an undocumented 'pwcheck_method: auxprop-hashed' which you can use to support hashed passwords, but I do not believe that slapd/ldapdb are supported. I assume the hash is either salted or unsalted md5. You would need to use the sasldb or sql auxprops to make use of it.
regarding using saslauthd in the mix with slapd/libsasl2, it seems that perhaps olcauthzregexp does not really apply any longer in this scenario? slapd does not need to itself canonicalize the username, as that work is done by the saslauthd ldap auth mechanism? removing the olcauthzregexp elements from my config seems to confirm this, but i'm wondering if there are other effects i've not considered.
saslauthd does not preform any canonicalization. You'll still use olcauthzregexp for that.
With libsasl2, authentication and canonicalization are independent. Regardless of the authentication method (gssapi/saslauthd/etc), olcauthzregexp is still used to canonicalize the username to a DN.
lastly, i'm curious about some logging i see going to the syslog auth facility. when using pwcheck_method: saslauthd, i see the following logged when starting slapd:
Oct 7 21:26:12 aurora slapd[20228]: DIGEST-MD5 common mech free Oct 7 21:26:14 aurora slapd[20240]: auxpropfunc error invalid parameter supplied Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Oct 7 21:26:14 aurora slapd[20240]: canonuserfunc error -7 Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb Oct 7 21:26:14 aurora slapd[20240]: sql_select option missing Oct 7 21:26:14 aurora slapd[20240]: auxpropfunc error no mechanism available Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql
i understand from reading various ml discussions that those messages are largely innocuous, but was curious nonetheless why messages that seem to be related to auxprop appear if i've explicitly specified saslauthd. is auxprop still being used in some capacity?
What version of slapd are you running? Newer versions should default to only loading the slapd auxprop. You can include:
auxprop_plugin: slapd
if running an older version. But yes, they are innocuous.
Be aware that even if you have 'pwcheck_method: saslauthd' configured, that configuration only affects PLAIN/LOGIN. Auxprop is still used for shared secret mechanisms such as DIGEST-MD5.
similarly, before using saslauthd, when initially testing using pwcheck_method: auxprop, and setting auxprop_plugin: slapd, as per doc/options.html, i expected to no longer see the complaints about sql and ldapdd, yet they still appear. are my expectations regarding this off-base?
No, that would be my expectation as well. Verify your olcSaslAuxprop configuration. In newer versions slapd just ignores your 'auxprop_plugin' option and uses olcSaslAuxprop instead, which defaults to slapd.
Another way to get rid of those log entries is to include dummy options for them:
ldapdb_uri: ldapi:/// sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
On Oct 8, 2013, at 09.56, Dan White dwhite@olp.net wrote:
That was referring to auxprop. In newer versions (> 2.1.23) of Cyrus SASL there is an undocumented 'pwcheck_method: auxprop-hashed' which you can use to support hashed passwords, but I do not believe that slapd/ldapdb are supported. I assume the hash is either salted or unsalted md5. You would need to use the sasldb or sql auxprops to make use of it.
ah, i see. a brief test here [cyrus sasl 2.1.25] seems to support your belief. i did not test against sasldb or sql, but no success against slapd. it's interesting though - i'll hope for maybe some further cultivation in the future :)
regarding using saslauthd in the mix with slapd/libsasl2, it seems that perhaps olcauthzregexp does not really apply any longer in this scenario? slapd does not need to itself canonicalize the username, as that work is done by the saslauthd ldap auth mechanism? removing the olcauthzregexp elements from my config seems to confirm this, but i'm wondering if there are other effects i've not considered.
saslauthd does not preform any canonicalization. You'll still use olcauthzregexp for that.
With libsasl2, authentication and canonicalization are independent. Regardless of the authentication method (gssapi/saslauthd/etc), olcauthzregexp is still used to canonicalize the username to a DN.
maybe i've overlooked something in my experimentation? with 'pwcheck_method: auxprop', the behavior seems quite clear. with olcauthzregexp, a test with ldapwhoami works:
ldapsearch -xLLLH 'ldap://aurora.example.com/' -D 'cn=admin,dc=example,dc=com' -w 'xxxxxxxx' -b 'cn=config' -s base
dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /opt/openldap/var/run/slapd.args olcLogLevel: any olcPidFile: /opt/openldap/var/run/slapd.pid olcSaslSecProps: noanonymous olcAuthzRegexp: {0}uid=([^,]*),cn=digest-md5,cn=auth uid=$1,ou=people,ou=accou nts,dc=example,dc=com
ldapwhoami -H 'ldap://aurora.example.com/' -Y 'digest-md5' -U 'flash' -w 'xxxxxxxx'
SASL/DIGEST-MD5 authentication started SASL username: flash SASL SSF: 128 SASL data security layer installed. dn:uid=flash,ou=people,ou=accounts,dc=example,dc=com
without olcauthzregexp, a test with ldapwhoami fails, as expected:
ldapwhoami -H 'ldap://aurora.example.com/' -Y 'digest-md5' -U 'flash' -w 'xxxxxxxx'
SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
but when using 'pwcheck_method: saslauthd' [and 'mech_list: plain'], a test with ldapwhoami succeeds, even without olcauthzregexp:
ldapsearch -xLLLH 'ldap://aurora.example.com/' -D 'cn=admin,dc=example,dc=com' -w 'xxxxxxxx' -b 'cn=config' -s base
dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /opt/openldap/var/run/slapd.args olcLogLevel: any olcPidFile: /opt/openldap/var/run/slapd.pid olcSaslSecProps: noanonymous
ldapwhoami -H 'ldap://aurora.example.com/' -Y 'plain' -U 'flash' -w 'xxxxxxxx'
SASL/PLAIN authentication started SASL username: flash SASL SSF: 0 dn:uid=flash,cn=plain,cn=auth
lastly, i'm curious about some logging i see going to the syslog auth facility. when using pwcheck_method: saslauthd, i see the following logged when starting slapd:
Oct 7 21:26:12 aurora slapd[20228]: DIGEST-MD5 common mech free Oct 7 21:26:14 aurora slapd[20240]: auxpropfunc error invalid parameter supplied Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Oct 7 21:26:14 aurora slapd[20240]: canonuserfunc error -7 Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb Oct 7 21:26:14 aurora slapd[20240]: sql_select option missing Oct 7 21:26:14 aurora slapd[20240]: auxpropfunc error no mechanism available Oct 7 21:26:14 aurora slapd[20240]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql
i understand from reading various ml discussions that those messages are largely innocuous, but was curious nonetheless why messages that seem to be related to auxprop appear if i've explicitly specified saslauthd. is auxprop still being used in some capacity?
What version of slapd are you running? Newer versions should default to only loading the slapd auxprop. You can include:
auxprop_plugin: slapd
if running an older version. But yes, they are innocuous.
at the moment, i'm using git master from about a month ago:
./slapd -V
@(#) $OpenLDAP: slapd 2.X (Sep 11 2013 19:58:01) $ root@aurora:/root/openldap/master/servers/slapd
Be aware that even if you have 'pwcheck_method: saslauthd' configured, that configuration only affects PLAIN/LOGIN. Auxprop is still used for shared secret mechanisms such as DIGEST-MD5.
i may not be following - if i explicitly set 'pwcheck_method: saslauthd', yet offer a shared secret mech, that config directive will be ignored and act as though pwcheck_method: auxprop is set if the shared secret mech is used? i guess that makes sense, since such a config would be contradictory?
nonetheless, in my test case, i'm using only plain ['mech_list: plain' and 'olcSaslSecProps: noanonymous']. the rootdse corroborates this, showing only an offering of plain:
ldapsearch -xLLLH 'ldap://aurora.example.com/' -s base -b '' 'supportedSASLMechanisms'
dn: supportedSASLMechanisms: PLAIN
but i still see the auxprop messages being logged.
similarly, before using saslauthd, when initially testing using pwcheck_method: auxprop, and setting auxprop_plugin: slapd, as per doc/options.html, i expected to no longer see the complaints about sql and ldapdd, yet they still appear. are my expectations regarding this off-base?
No, that would be my expectation as well. Verify your olcSaslAuxprop configuration. In newer versions slapd just ignores your 'auxprop_plugin' option and uses olcSaslAuxprop instead, which defaults to slapd.
i've tried both with olcSaslAuxprop omitted, and explicitly specifying a value of 'slapd' - neither seems to have an impact on the log messages.
Another way to get rid of those log entries is to include dummy options for them:
ldapdb_uri: ldapi:/// sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
using these dummy options does suppress the log messages, but i'd like to learn what i'm doing wrong if only the slapd plugin is supposed to be in use to begin with.
-ben
btb@bitrate.net wrote:
On Oct 8, 2013, at 09.56, Dan White dwhite@olp.net wrote:
That was referring to auxprop. In newer versions (> 2.1.23) of Cyrus SASL there is an undocumented 'pwcheck_method: auxprop-hashed' which you can use to support hashed passwords, but I do not believe that slapd/ldapdb are supported.
See ITS#7419. We will not support it until it is properly documented. It would be foolish to attempt otherwise.
On 10/09/13 22:20 -0400, btb@bitrate.net wrote:
On Oct 8, 2013, at 09.56, Dan White dwhite@olp.net wrote:
without olcauthzregexp, a test with ldapwhoami fails, as expected:
ldapwhoami -H 'ldap://aurora.example.com/' -Y 'digest-md5' -U 'flash' -w 'xxxxxxxx'
SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
You're comparing apples to oranges here. You should be performing PLAIN authentication for a closer comparison. Of course, you'll need a clear text password in your entry for that to succeed.
but when using 'pwcheck_method: saslauthd' [and 'mech_list: plain'], a test with ldapwhoami succeeds, even without olcauthzregexp:
ldapsearch -xLLLH 'ldap://aurora.example.com/' -D 'cn=admin,dc=example,dc=com' -w 'xxxxxxxx' -b 'cn=config' -s base
dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /opt/openldap/var/run/slapd.args olcLogLevel: any olcPidFile: /opt/openldap/var/run/slapd.pid olcSaslSecProps: noanonymous
ldapwhoami -H 'ldap://aurora.example.com/' -Y 'plain' -U 'flash' -w 'xxxxxxxx'
SASL/PLAIN authentication started SASL username: flash SASL SSF: 0 dn:uid=flash,cn=plain,cn=auth
slapd internally assigns an identity after SASL authentication is successful. ldapwhoami will still succeed without an olcauthzregexp, but will simply point to the generated "pseudo" dn, rather than an actual entry in your tree (unless you have actually created a cn=auth database).
Be aware that even if you have 'pwcheck_method: saslauthd' configured, that configuration only affects PLAIN/LOGIN. Auxprop is still used for shared secret mechanisms such as DIGEST-MD5.
i may not be following - if i explicitly set 'pwcheck_method: saslauthd', yet offer a shared secret mech, that config directive will be ignored and act as though pwcheck_method: auxprop is set if the shared secret mech is used? i guess that makes sense, since such a config would be contradictory?
Shared secret mechanisms will use your configured auxprop plugin. Shared secret mechanisms will always disregard your pwcheck_method config.
Another way to get rid of those log entries is to include dummy options for them:
ldapdb_uri: ldapi:/// sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
using these dummy options does suppress the log messages, but i'd like to learn what i'm doing wrong if only the slapd plugin is supposed to be in use to begin with.
I'm not sure that you are. I suppose a better solution is to remove the ldapdb and sql (and sasldb) shared libraries from your system, in which case they'll never be loaded in to memory.
On Oct 10, 2013, at 09.49, Dan White dwhite@olp.net wrote:
slapd internally assigns an identity after SASL authentication is successful. ldapwhoami will still succeed without an olcauthzregexp, but will simply point to the generated "pseudo" dn, rather than an actual entry in your tree (unless you have actually created a cn=auth database).
apologies. i somehow became blind to the dn: string being returned from ldapwhoami in my comparisons.
Another way to get rid of those log entries is to include dummy options for them:
ldapdb_uri: ldapi:/// sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
using these dummy options does suppress the log messages, but i'd like to learn what i'm doing wrong if only the slapd plugin is supposed to be in use to begin with.
I'm not sure that you are. I suppose a better solution is to remove the ldapdb and sql (and sasldb) shared libraries from your system, in which case they'll never be loaded in to memory.
i did consider this, but that prohibits other programs from using those plugins. i know this is largely an academic exercise at this point, but i'm curious about the theory. based on your insight, and my testing, would it be accurate to say that the nuance is that "load" and "use" are not the same thing? e.g. sasl "loads" [or maybe there's a better term?] all of the auxprop plugins it can find, but then only "uses" the plugins defined by auxprop_plugin?
-ben
openldap-technical@openldap.org
-
btb -
btb＠bitrate.net
-
Dan White -
Howard Chu