Ok, I will most likely do that.I'm not 100% convinced that it is not autofs, because ldapsearch works fine with SASL + GSSAPI on openSUSE 12.2... of course this is in no way evidence that autofs is faulty.
To me it is still possible that the autofs SASL code is missing something or relying on some defaults, that might have changed with new openldap/cyrus sasl/kerberos versions.
Anyways, thanks to much for your help... Best regards, Joschi Brauchle On 08/09/2012 03:49 PM, Leonardo Chiquitto wrote:
Hello Joschi, Thanks for all the information. As AutoFS is not the culprit here, may I suggest that you open a bug in bugzilla.novell.com against openSUSE 12.2? This way we can involve the Kerberos, SASL and LDAP maintainers to figure out which update broke this use case. Thanks, Leonardo On Thu, Aug 9, 2012 at 6:16 AM, Joschi Brauchle <joschi.brauchle@xxxxxx> wrote:By the way, I can to a successfull ldapsearch from the OpenSUSE 12.2 host using SASL + GSSAPI! Tracing the ldapsearch command, I see that it does set the "Mutual authentication is required" bit to 1 in the KRB-AS-REQ part of the bind request. In the autofs trace, this bit is set to 0... Best regards, Joschi Brauchle PS: I also changed the thread title... On 08/09/2012 11:08 AM, Joschi Brauchle wrote:Ok, so I'm by no means an expert in Wireshark or GSSAPI/Kerberos, but comparing the traces from autofs5.0.5 (!) on two hosts, one OpenSUSE11.4, the other OpenSUSE12.2, I get the following insight: 11.4 host: -------------- -> Sends a bind request including a KRB-AP-REQ, with the "Mutual-authentication-required" bit set to 1. <- Receives a bind response saying "SASLBindInProgress", containing the "serverSASLcreds" plus some more GSSAPI/Kerberos data. <-> Continues on and binds successfully... 12.2 host: -------------- -> Sends a bind request including a KRB-AP-REQ, with the "Mutual-authentication-required" bit set to 0! <- Receives a bind response saying "SASLBindInProgress" but which does NOT contain any "serverSASLcreds" and no further GSSAPI/Kerberos data. -> Sends an unbind request. So the bind request is different, although the autofs version is the same... Why is that? On 08/09/2012 10:45 AM, Joschi Brauchle wrote:Hello Ian, Leonardo, thanks for your help so far! I'm a little confused so far because: - I replaced "ldaps" with "ldap", no change - I double checked DNS of ldap server, it's fine (and works with autofs 5.0.5 on other hosts) - I installed Leonardo's 5.0.7 with the reverted patch, no change (it's now trying twice and failing twice, same error). - I installed autofs 5.0.5 from OpenSUSE 11.4 (which is working fine on there), NO CHANGE! The last part confuses me... even 5.0.5 does not succeed on openSUSE 12.2, so the problem must lie somewhere outside of autofs... , e.g. with the newly used "sss" daemon or something else. Next, I will use wireshark to sniff and compare the traffic between an OS11.4 and OS 12.2 machine and report back. Best regards, Joschi Brauchle On 08/09/2012 04:20 AM, Ian Kent wrote:On Wed, 2012-08-08 at 15:58 +0200, Joschi Brauchle wrote:Hi all, I am successfully using autofs 5.0.5 (on OpenSUSE 11.4) with LDAP + SASL + GSSAPI mech in combination with an OpenLDAP 2.4.26 server (running on SLES11SP1). My /etc/autofs_ldap_auth.conf looks like this: ------------------------------------------------------- <?xml version="1.0" ?> <!-- This files contains a single entry with multiple attributes tied to it. See autofs_ldap_auth.conf(5) for more information. --> <autofs_ldap_sasl_conf authrequired="yes" authtype="GSSAPI" clientprinc="host/<hostname>.<fqdn>@<REALM>" /> ------------------------------------------------------- Now, I am trying to update to OpenSUSE 12.2 with AutoFS 5.0.7, but there the SASL + GSSAPI bind fails (with the same config file from above), with the following debug messaged:In the past this symptom was seen when there was a problem with the host name. That shouldn't be a problem but it would be worth checking that the name in the configuration, the <LDAPSERVER>, is "correct" in the DNS sense. The other thing that I'm not sure about is the service name used with sasl_client_new(). The documentation calls this the "registered name of the service (usually the protocol name)" but sasl_bind_mech() (which is failing) uses the hard coded string "ldap" for this. It could be worth checking if using ldap://<LDAPSERVER> instead of ldaps://<LDAPSERVER> makes a difference, if you can do that. Otherwise we could try a patch which hard codes "ldaps" in the call to check if that is the problem.------------------------------------------------------- Starting automounter version 5.0.7, master map auto.master using kernel protocol version 5.02 lookup_nss_read_master: reading master files auto.master parse_init: parse(sun): init gathered global options: (null) spawn_mount: mtab link detected, passing -n to mount spawn_umount: mtab link detected, passing -n to mount lookup_read_master: lookup(file): read entry +auto.master lookup_nss_read_master: reading master files auto.master parse_init: parse(sun): init gathered global options: (null) lookup_nss_read_master: reading master ldap auto.master parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master". parse_server_string: lookup(ldap): mapname auto.master parse_ldap_config: lookup(ldap): ldap authentication configured with the following options: parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 2, sasl_mech: GSSAPI parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: host/<hostname>.<fqdn>@<REALM> credential cache: (null) parse_init: parse(sun): init gathered global options: (null) find_server: trying server uri ldaps://<LDAPSERVER> do_bind: lookup(ldap): auth_required: 2, sasl_mech GSSAPI sasl_do_kinit: initializing kerberos ticket: client principal host/<hostname>.<fqdn>@<REALM> sasl_do_kinit: calling krb5_parse_name on client principal host/<hostname>.<fqdn>@<REALM> sasl_do_kinit: Using tgs name krbtgt/<REALM>@<REALM> sasl_do_kinit: Kerberos authentication was successful! sasl_bind_mech: Attempting sasl bind with mechanism GSSAPI getuser_func: called with context (nil), id 16385. The LDAP server indicated that the LDAP SASL bind was incomplete, but did not provide the required data to proceed. LDAP SASL bind with mechanism GSSAPI failed. sasl bind with mechanism GSSAPI failed do_bind: lookup(ldap): autofs_sasl_bind returned -1 lookup(ldap): couldn't connect to server ldaps://<LDAPSERVER> do_reconnect: lookup(ldap): failed to find available server lookup(file): failed to read included master map auto.master no mounts in table ------------------------------------------------------- When I compare the logs in the server side, I see that autoFS 5.0.5 binds twice, where the first bind does not provide the principal name, but the second bind does and succeeds. AutoFS 5.0.7 binds only once and does not provide the principal name to the server, hence the bind is rejected. I checked the changes from 5.0.5 to 5.0.7 and it seems like the SASL code was completely re-factored and a change was made to prevent (unnecessary) multiple binds. Maybe though, this does not work correctly with the OpenLDAP server we are using? Unfortunately, turning on full debug log on the server is difficult, because the server runs in production and consequently logs a huge amount of data. I can only turn debugging on/off very quickly, which already leaved me with multiple thousand lines of logs... What can I do to track down the problem? Thanks for any help or suggestions!-- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
