Bug 112959 - autofs apparently doesn't check ldap.conf
autofs apparently doesn't check ldap.conf
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Moyer
Depends On:
  Show dependency treegraph
Reported: 2004-01-06 13:19 EST by Stephen Walton
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-11 16:03:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Walton 2004-01-06 13:19:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

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
cn: /home

which works but, in my opinion, should not be needed.

Version-Release number of selected component (if applicable):

How reproducible:

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
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

Additional info:
Comment 1 Stefan Christians 2004-02-08 03:46:19 EST
We have had the same symptoms here, but the proposed workaround of
putting the ldap server name into the automountInformation attribute
did not help.

autofs 3.1.7-42 and 
openldap-servers 2.1.22-8, 
we found out following:

When first accessing auto.master, autofs binds anonymously (dn="")
using LDAPv3 protocol.
But after this initial step, things become weird.

autofs changes to LDAPv2 protocol, which in this version of slapd is
not enabled by default and must be specifically allowed.

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.

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.
Comment 2 Alexei Monastyrnyi 2004-02-09 11:17:28 EST
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= (IP=
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" 
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
Comment 3 Andrew Jorgensen 2004-03-04 00:16:34 EST
I experienced the same problem as described by Stefan, and the
workaround proposed works perfectly.
Comment 4 Matthew West 2004-03-29 14:41:26 EST
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 

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.
Comment 5 Jeff Moyer 2004-03-30 19:39:38 EST
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:
Comment 6 Matthew West 2004-03-30 21:22:23 EST
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.

Note You need to log in before you can comment on or make changes to this bug.