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!
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
