Bug#629589: segfault gone, but problems remain
I think we can chock this up to operator error due to flaky DNS - why it worked ~25% of the time is a mystery... krb is pretty sensitive to forward, reverse, and canonical host names. Thanks... looks like 'tis time to update more machines now :) Just to clarify - you consider this bug to be closed and the failure was most probably caused by DNS (which could be checked by putting hostname to /etc/hosts). BTW... Rick, I am still waiting for sendmail to move to Berkeley DB 5.1, so we can finish the transition to db5.1 O. -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On 11/06/11 18:45 -0700, Richard A Nelson wrote: On Sat, 11 Jun 2011, Dan White wrote: Yes, interestingly, this shows up for both failure modes: Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The ldapdb error probably isn't related. You should be able to add: ldapdb_uri: ldapi:/// to /etc/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf to stop it from complaining. Doesn't help - /etc/sasl2/slapd.conf: allowanonymouslogin: 1 allowplaintext: 1 ldapdb_uri: ldapi:/// I forgot, you'll probably also need a (dummy) ldapdb_canon_attr entry, like: ldapdb_canon_attr: uid -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
$ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context $ ldapwhoami SASL/GSSAPI authentication started SASL username: cowboy@REALM SASL SSF: 56 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=... $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) A tad bit unreliable ... and those were back-to-back queries :( -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On 11/06/11 10:54 -0700, Richard A Nelson wrote: $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context $ ldapwhoami SASL/GSSAPI authentication started SASL username: cowboy@REALM SASL SSF: 56 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=... $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) Do you have libsasl2-modules-gssapi-mit or libsasl2-modules-gssapi-heimdal installed, and what version? Is your slapd running on a separate host? If so, is it using the same version of libsasl2-modules-gssapi-*? Do you see anything useful in your /var/log/auth.log on the server or client? What kerberos server are you using, and do you see anything in it's syslog output? Would you mind sharing an anonymized copy of your /etc/ldap.conf and ~/.ldaprc? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On Sat, 11 Jun 2011, Dan White wrote: Do you have libsasl2-modules-gssapi-mit or libsasl2-modules-gssapi-heimdal installed, and what version? ii libsasl2-modules-gssapi-heimdal 2.1.24~rc1.dfsg1+cvs2011-05-23-4 Is your slapd running on a separate host? No, 'tis using ldapi:// If so, is it using the same version of libsasl2-modules-gssapi-*? I have not upgraded my master servers until this is cleared, but the laptop (sacraficial testsite) has its own copy of ldap/kdc/etc. Do you see anything useful in your /var/log/auth.log on the server or client? Yes, interestingly, this shows up for both failure modes: Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb This one for the succes case: Jun 11 15:37:02 sparks-ave ldapwhoami: DIGEST-MD5 common mech free What kerberos server are you using, ii heimdal-kdc1.4.0-6 and do you see anything in it's syslog output? No, just the expected: AS-REQ host/... from IPv4:127.0.0.1 for krbtgt/... Would you mind sharing an anonymized copy of your /etc/ldap.conf and ~/.ldaprc? Not at all :) /etc/ldap/ldap.conf: BASEdc=... URI ldapi:/// TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERTDIR /etc/ssl/certs TLS_CRLCHECK none TLS_REQCERT allow ~/.ldaprc: SASL_MECH gssapi -- Rick Nelson Connection reset by some moron with a backhoeb -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On 11/06/11 10:54 -0700, Richard A Nelson wrote: $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context $ ldapwhoami SASL/GSSAPI authentication started SASL username: cowboy@REALM SASL SSF: 56 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=... $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) On 11/06/11 15:46:24 -0700, Richard A Nelson wrote: No, 'tis using ldapi:// Yes, interestingly, this shows up for both failure modes: Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The ldapdb error probably isn't related. You should be able to add: ldapdb_uri: ldapi:/// to /etc/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf to stop it from complaining. This one for the succes case: Jun 11 15:37:02 sparks-ave ldapwhoami: DIGEST-MD5 common mech free /etc/ldap/ldap.conf: BASEdc=... URI ldapi:/// TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERTDIR /etc/ssl/certs TLS_CRLCHECK none TLS_REQCERT allow ~/.ldaprc: SASL_MECH gssapi I haven't done gssapi over ldapi:/// before - how does your (client) gssapi mech know which kerberos service ticket to submit to the server (ldap/hostname@REALM) for authentication? Maybe it just uses the local hostname? Does it make any difference if you use ldap://hostname instead? When there's a failure, are you getting the ldap/hostname@REALM service ticket from your kerberos server? Does klist look the same between failures and successes? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On Sat, 11 Jun 2011, Dan White wrote: Yes, interestingly, this shows up for both failure modes: Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The ldapdb error probably isn't related. You should be able to add: ldapdb_uri: ldapi:/// to /etc/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf to stop it from complaining. Doesn't help - /etc/sasl2/slapd.conf: allowanonymouslogin: 1 allowplaintext: 1 ldapdb_uri: ldapi:/// and even after the below info, and restarting slapd saslauthd I'm still getting this in /var/log/auth.log: Jun 11 18:40:36 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 18:40:36 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb Jun 11 18:40:36 sparks-ave ldapwhoami: DIGEST-MD5 common mech free This one for the succes case: Jun 11 15:37:02 sparks-ave ldapwhoami: DIGEST-MD5 common mech free /etc/ldap/ldap.conf: BASEdc=... URI ldapi:/// TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERTDIR /etc/ssl/certs TLS_CRLCHECK none TLS_REQCERT allow ~/.ldaprc: SASL_MECH gssapi I haven't done gssapi over ldapi:/// before - how does your (client) gssapi mech know which kerberos service ticket to submit to the server (ldap/hostname@REALM) for authentication? Maybe it just uses the local hostname? Good question ! It apparently does use the canonical host name - I have a ticket for: krbtgt/realm@REALM ldap/sparks-ave.domain@REALM Does it make any difference if you use ldap://hostname instead? Actually, I think you fixed it by mistake :) intermittent reverse resolution issues (I got an error saying couldn't find a ticket for 192.168.1.12@REALM ... instead of sparks-ave ! When there's a failure, are you getting the ldap/hostname@REALM service ticket from your kerberos server? Does klist look the same between failures and successes? The testing has all been done under the same session, after login in, and not resetting krbt credentials: krbtgt/ ldap/sparks-ave host/sparks-ave imap/sparks-ave smtp/sparks-ave I think we can chock this up to operator error due to flaky DNS - why it worked ~25% of the time is a mystery... krb is pretty sensitive to forward, reverse, and cononical host names. Thanks... looks like 'tis time to update more machines now :) -- Rick Nelson ...you might as well skip the Xmas celebration completely, and instead sit in front of your linux computer playing with the all-new-and-improved linux kernel version. (By Linus Torvalds) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
