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):
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.
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. 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?
> FreeBSD may, of course, be different from Linux in this respect.
> How, if
> nss_ldap is failing to bind, does normal authentication work for you?
> --
> 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
>
> --
> ## 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/
>
