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 : nmw@???
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
