Arthur de Jong <adej...@debian.org> writes: >> nslcd: [8b4567] <group(all)> DEBUG: >> ldap_sasl_interactive_bind_s(NULL,"auto") (uri="ldap://192.168.122.4";) >> nslcd: [8b4567] <group(all)> failed to bind to LDAP server >> ldap://192.168.122.4: Unknown authentication method: Operation now in >> progress > > What is nslcd supposed to do with SASL automatic mode?
From ldap_bind_s(3): ===== The mechs parameter should contain a space-separated list of candidate mechanisms to use. If this parameter is NULL or empty the library will query the supportedSASLMechanisms attribute from the server's rootDSE for the list of SASL mechanisms the server supports. ===== nslcd should then call: ===== nslcd: [8b4567] <group(all)> DEBUG: ldap_sasl_interactive_bind_s(NULL,"") (uri="ldap://192.168.122.4";) ===== I made a quick and dirty change in nslcd/cfg.c line 854: ===== 853 else if (strcasecmp(keyword,"sasl_mech")==0) { get_strdup(filename,lnr,keyword,&line,&cfg->ldc_sasl_mech); get_eol(filename,lnr,keyword,&line); if (strcasecmp(cfg->ldc_sasl_mech,"AUTO")==0) { cfg->ldc_sasl_mech=""; } } ===== With this, I setup nslcd.conf with the following: ===== bindpw Cr4ckM3 krb5_ccname /var/run/nslcd/nslcd.tkt sasl_mech AUTO sasl_realm BABY-GNU.ORG sasl_authcid testsrv sasl_secprops noplain,noanonymous ===== We need to set every possibilities and start k5start to use GSSAPI. The automatic mechanisms search only works if 'security ssf=0 sasl=0' on the LDAP server. I think it's not that usefull, to get supported SASL mechanisms by the LDAP server we can use (if anonymous bind is allowed): ===== ldapsearch -x -b "" -s base -LLL supportedSASLMechanisms ===== I try to make it works with "space-separated list of candidate mechanisms to use" by comment out the 'get_eol' call in cfg.c but it seems 'get_token' should be changed too. I do not get deeper in this point. > >> CRAM-MD5 need SASL SECPROPS minssf=0, I found it empirically, maybe a >> note about it could be usefull (in man page?) > > Another option would be to have the debconf script suggest a value for > secprops if CRAM-MD5 was selected and it was empty at this point. I > guess that would be OK if it wouldn't work otherwise. Well, I made some tests and find the following: #+tblname: Maximum slapd security values by SASL mechanisms | | secprops | ssf | sasl | tls | | ANONYMOUS | none/noplain | 0 | 0 | 0 | | LOGIN | none/noanonymous | 0 | 0 | 0 | | PLAIN | none/noanonymous | 0 | 0 | 0 | | CRAM-MD5 | noplain+noanonymous | 0 | 0 | 0 | | NTLM | noplain+noanonymous | 0 | 0 | 0 | | DIGEST-MD5 | noplain+noanonymous | 128 | 128 | 0 | | GSSAPI | noplain+noanonymous+noactive+passcred | 56 | 56 | 0 | Execpt for DIGEST-MD5 and GSSAPI, minssf must be 0. The nodict SASL disable all the mechanisms in the previous table (maybe useable by EXTERNAL with TLS certification verification?) The slapd's tls security factor require TLS to be activated. Finally, I'm fine with suggesting minssf values if empty since the client library seems to validate the mechanism before using it, for example: - slapd: security ssf=0, sasl-secprops noplain,noanonymous should permit DIGEST-MD5 - client nslcd.conf: sasl_secprops noplain,noanonymous,noactive => DIGEST-MD5 does not work, only GSSAPI is possible. When testing I saw this strange behaviour. - nslcd open the TCP connection to the server and unbind without binding: ===== wireshark No. Time Source Destination Protocol Info 5 7.410819 192.168.122.3 192.168.122.4 TCP 51522 > ldap [SYN] Seq=0 [...] 6 7.411627 192.168.122.4 192.168.122.3 TCP ldap > 51522 [SYN, ACK] Seq=0 [...] 7 7.411648 192.168.122.3 192.168.122.4 TCP 51522 > ldap [ACK] Seq=1 [...] 8 7.421897 192.168.122.3 192.168.122.4 LDAP unbindRequest(1) 9 7.421979 192.168.122.3 192.168.122.4 TCP 51522 > ldap [FIN, ACK] Seq=8 [...] 10 7.422650 192.168.122.4 192.168.122.3 TCP ldap > 51522 [ACK] Seq=1 [...] 11 7.422663 192.168.122.4 192.168.122.3 TCP ldap > 51522 [FIN, ACK] Seq=1 [...] 12 7.422669 192.168.122.3 192.168.122.4 TCP 51522 > ldap [ACK] Seq=9 [...] ===== wireshark and fail with the following message: ===== nslcd: [8b4567] <group(all)> failed to bind to LDAP server ldap://192.168.122.4: Unknown authentication method: Operation now in progress ===== - a ldapsearch do the following: ===== wireshark No. Time Source Destination Protocol Info 3 2.728967 192.168.122.3 192.168.122.4 TCP 51521 > ldap [SYN] Seq=0 [...] 4 2.729699 192.168.122.4 192.168.122.3 TCP ldap > 51521 [SYN, ACK] Seq=0 [...] 5 2.729714 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=1 [...] 6 2.739576 192.168.122.3 192.168.122.4 TCP 51521 > ldap [FIN, ACK] Seq=1 [...] 7 2.740686 192.168.122.4 192.168.122.3 TCP ldap > 51521 [FIN, ACK] Seq=1 [...] 8 2.740702 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=2 [...] ===== wireshark and fail with the following message: ===== ldapsearch ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found ===== ldapsearch The ldap library open the useless connection, but nslcd add a useless unbindRequest. Regards. -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
pgprky8yjhOmj.pgp
Description: PGP signature
