From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: In my migration from RedHat 8 to Fedora Core 1, I copied some LDAP automount maps over of the form: # /home, auto.master, my, domain, edu dn: cn=/home, ou=auto.master,dc=my,dc=domain,dc=edu objectClass: automount automountInformation: ldap:ou=auto.home,dc=sfo,dc=csun,dc=edu cn: /home These failed to work on Fedora; error messages of the form /var/log/messages.1:Dec 31 10:12:05 apollo automount[23310]: lookup(ldap): couldn't connect to (null) appeared in /var/log/messages. The fix was to explicitly put the LDAP host name in the map: # /home, auto.master, my, domain, edu dn: cn=/home, ou=auto.master,dc=my,dc=domain,dc=edu objectClass: automount automountInformation: ldap:ldap.my.domain.edu:ou=auto.home,dc=sfo,dc=csun,dc=edu cn: /home which works but, in my opinion, should not be needed. Version-Release number of selected component (if applicable): autofs-3.1.7-42 How reproducible: Always Steps to Reproduce: 1. Create an auto.master LDAP map of the form: # auto.master, your.domain.com dn: ou=auto.master,dc=your,dc=domain,dc=com objectClass: top objectClass: automountMap ou: auto.master 2. Create an automount entry of the form: # /auto, auto.master, sfo, csun, edu dn: cn=/auto, ou=auto.master, dc=your,dc=domain,dc=com objectClass: automount automountInformation: ldap:apollo.sfo.csun.edu:ou=auto.auto,dc=your,dc=domain,dc=com cn: /auto 3. Restart ldap and autofs. Actual Results: Error messages of the form "couldn't connect to (null)" from automount Expected Results: Automount should look at the host name in /etc/openldap/ldap.conf Additional info:
We have had the same symptoms here, but the proposed workaround of putting the ldap server name into the automountInformation attribute did not help. Using autofs 3.1.7-42 and openldap-servers 2.1.22-8, we found out following: 1) When first accessing auto.master, autofs binds anonymously (dn="") using LDAPv3 protocol. But after this initial step, things become weird. 2) autofs changes to LDAPv2 protocol, which in this version of slapd is not enabled by default and must be specifically allowed. 3) autofs tries to bind with the dn it received as the last search result. Subsequent connections by autofs are logged as follows: ... ... BIND dn="" ... (autofs looks for the auto.master map) ... ... BIND dn="" ... (autofs reads the automount maps in auto.master) ... ... BIND dn="ou=auto.misc,..." ... (autofs reads automountInformation in auto.misc, but binds with the last search result) ... That looks very buggy, and chances are high that a wrong variable has been used. In this version of slapd, trying to bind with a dn but without password has been disabled for security reasons, but it used to result in anonymous binds. So perhaps this is a very old bug which only recently started to become annoying. In this verison of slapd, it must be specifically allowed. Workaround: in /etc/slapd.conf, the following security parameters must be set (separated by whitespace): allow bind_v2 bind_anon_dn Once this was done, our autofs worked, with or without specifiying the name of the ldap server in the automountInformation attribute. Unfortunately, we are not sure where the problem is happening, whether it is really in autofs or perhaps something like nss.
Hi. I'm using RHEL3 update 1 with default kernel (2.4.21-9.ELsmp) and autofs-3.1.7-41. OpenLDAP server 2.1.24 is on the separate box. Looks like I have the same issue as in Comment #1. AutoFS tries to bind with version 2. Any workarounds? Feb 9 17:10:38 alien slapd[21047]: [ID 848112 local4.debug] conn=200241 fd=30 ACCEPT from IP=172.27.1.21:33462 (IP=0.0.0.0:389) Feb 9 17:10:38 alien slapd[21047]: [ID 347666 local4.debug] conn=200241 op=0 BIND dn="ou=auto.home,dc=orcsoftware,dc=com" method=128 Feb 9 17:10:38 alien slapd[21047]: [ID 217296 local4.debug] conn=200241 op=0 RESULT tag=97 err=2 text=requested protocol version not allowed Feb 9 17:10:38 alien slapd[21047]: [ID 952275 local4.debug] conn=200241 fd=30 closed Feb 9 17:10:39 alien slapd[21047]: [ID 338319 local4.debug] conn=200216 op=3 UNBIND Feb 9 17:10:39 alien slapd[21047]: [ID 952275 local4.debug] conn=200216 fd=36 closed
I experienced the same problem as described by Stefan, and the workaround proposed works perfectly.
Just a "me too": I had the same symtoms as Stefan and his solution of allowing v2 and anon binds with a dn worked perfectly. Watching an ethereal trace when automount starts up it's completely clear that the client is binding using version 2 and with the DN set to the DN of the automount map. A quick glance at the source seems to point to a bug in autofs. In modules/ lookup_ldap.c it seems to be doing the ldap_bind itself, and using the wrong dn when looking up the maps. I can't see what's triggering the switch to ldap v2, however.
For those of you using fedora, could you try the latest version of autofs from rawhide? autofs-4.1.1-3. Alternatively, you could grab the latest version from my people page: http://people.redhat.com/~jmoyer/
I can confirm that autofs-4.1.1-3 from rawhide fixes this problem. Watching an ethereal trace now shows the bind being done with DN=(null) and version=3, which succeeds just fine with the default slapd.conf as shipped in FC1. Presumably this will all just work in FC2 then.