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
