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 : [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/ > -- ## 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/
