Jason Lixfeld wrote: > On 4-Jul-06, at 10:57 AM, Nigel Wade wrote: > > >>>It looks as though it's nss_ldap failing to bind. I'll have to sort >>>that out on my own. >>> >> >>The way it works here (openldap on Linux - RHEL AS4) is that >>nss_ldap will first >>attempt to bind using the binddn specified in /etc/ldap.conf. This >>requires it >>be able to read /etc/ldap.secret. If it is unable to do this it >>will attempt an >>anonymous bind. In either case the bind must have read access to >>sufficient >>information to satisfy the request. I'm not exactly sure what >>attributes >>check_local_user requires to satisfy its requirements that a user >>is actually local. > > > This call below is for the virtual_alias router that gets the local > user from the mailLocalAddress attribute. This is an anonymous call > that works fine: > > Jul 4 11:21:27 ricky slapd[63012]: conn=64 fd=15 ACCEPT from > IP=127.0.0.1:52080 (IP=0.0.0.0:389) > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=0 BIND dn="" method=128 > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=0 RESULT tag=97 err=0 > text= > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=1 SRCH > base="o=example.ca,ou=hosting,ou=mail,dc=example,dc=ca" scope=0 > deref=0 filter="(objectClass=*)" > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=1 SRCH attr=o > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=1 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=2 SRCH > base="o=example.ca,ou=hosting,ou=mail,dc=example,dc=ca" scope=2 > deref=0 filter="(&(uid=jlixfeld))" > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=2 SRCH > attr=mailLocalAddress > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=2 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=3 SRCH > base="o=mail.example.ca,ou=hosting,ou=mail,dc=example,dc=ca" scope=0 > deref=0 filter="(objectClass=*)" > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=3 SRCH attr=o > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=3 SEARCH RESULT > tag=101 err=32 nentries=0 text= > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=4 SRCH > base="o=mail.example.ca,ou=hosting,ou=mail,dc=example,dc=ca" scope=2 > deref=0 filter="(&(uid=jlixfeld.example.ca))" > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=4 SRCH > attr=mailLocalAddress > > The proxyuser DN is the one listed in ldap.conf and nss_ldap.conf. > The fact that exim is logging the failure is strange, seeing as how > nss/ldap.conf and secret are all set mode o+r (for the purposes of > testing this to get it functional):
I presume here you are specifically doing a LDAP lookup from Exim? That isn't going to use nss_ldap. Exim binds directly to the LDAP server using whatever bind method you specify in exim.conf. > > Jul 4 11:21:27 ricky exim: nss_ldap: failed to bind to LDAP server > ldap://127.0.0.1: Invalid credentials > Jul 4 11:21:27 ricky slapd[63012]: conn=64 op=4 SEARCH RESULT > tag=101 err=32 nentries=0 text= > Jul 4 11:21:27 ricky exim: nss_ldap: could not search LDAP server - > Server is unavailable > Jul 4 11:21:27 ricky kernel: Jul 4 11:21:27 ricky exim: nss_ldap: > could not search LDAP server - Server is unavailable > Jul 4 11:21:27 ricky slapd[63012]: conn=65 fd=16 ACCEPT from > IP=127.0.0.1:58258 (IP=0.0.0.0:389) > Jul 4 11:21:27 ricky slapd[63012]: conn=65 op=0 BIND > dn="cn=Proxyuser,dc=example,dc=ca" method=128 > > This is an anonymous bind searching the entire directory as an > unprivileged user. Again, for the purposes of testing, everything > should be totally opened up with no restrictions, so I'm confused as > to why exim is failing on nss_ldap. This is nss_ldap failing to bind. If nss_ldap can't bind to the LDAP server, how does your 'id' command work? I prefer to use ethereal to capture the packets sent between client and server. That way I get to see the full transaction, rather than a few log entries which slapd chooses to output. > > Jul 4 11:26:16 ricky slapd[63012]: conn=19 op=2 UNBIND > Jul 4 11:26:16 ricky slapd[63012]: conn=19 fd=10 closed > Jul 4 11:26:25 ricky slapd[63012]: conn=68 fd=10 ACCEPT from > IP=127.0.0.1:58440 (IP=0.0.0.0:389) > Jul 4 11:26:25 ricky slapd[63012]: conn=68 op=0 BIND dn="" method=128 > Jul 4 11:26:25 ricky slapd[63012]: conn=68 op=0 RESULT tag=97 err=0 > text= > Jul 4 11:26:25 ricky slapd[63012]: conn=68 op=1 SRCH > base="dc=example,dc=ca" scope=2 deref=0 filter="(objectClass=*)" > Jul 4 11:26:25 ricky slapd[63012]: conn=68 op=1 SEARCH RESULT > tag=101 err=0 nentries=16 text= > Jul 4 11:26:25 ricky slapd[63012]: conn=68 op=2 UNBIND > Jul 4 11:26:25 ricky slapd[63012]: conn=68 fd=10 closed > > Come to think of it: The ldap.secret file isn't any sort of standard > by way of name or location, correct? The file is usually used via > the command line with the -y option to specify the location of the > password file. It is hardwired in nss_ldap (from PADL) on Linux. What implementation of nss_ldap does FreeBSD use? > Perhaps exim is looking for the file in a location > where it does not exist. The location of the file isn't specified in > nss_ldap.conf, nor is there a way to, is there? So where is exim > actually looking for the file, in that case then? > Exim won't be looking for this file at all. This should all be handled by nss_ldap. I don't know the internal workings of Exim, so you might need to debug that to see what it is really doing. I would expect that it is simply using getpwnam/getpwent, and this in turn is using nss_ldap if it is configured to do so in /etc/nsswitch.conf. -- Nigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : [EMAIL PROTECTED] Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
