Your internal lookup, in LDAP for "uid=foo" :-
On 2025/04/12 5:30 PM, Johnnie W Adams via Exim-users wrote:
11:25:57 134826 ├considering: ${lookup
ldapdn{user="CN=svc_domainjoin,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
pass="password" ldaps://
auth.example.com/OU=Service%20Accounts,DC=ad,DC=example,DC=com?dn?sub?(uid=${quote_ldap_dn:$auth1})}}
pass=${quote:$auth2} ldaps://auth.example.com/ } } } }
[...]
11:25:57 134826 database lookup required for
user="CN=svc_domainjoin,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
pass="password" ldaps://
auth.example.com/OU=Service%20Accounts,DC=ad,DC=example,DC=com?dn?sub?(uid=foo)
11:25:57 134826 (tainted, quoted:ldap)
[...]
11:25:57 134826 LDAP search: no results
- returned no results
11:25:57 134826 creating new cache entry
11:25:57 134826 lookup failed
- this constitutes a failure. The "fail" result for the ${lookup}
expansion
will get used. You don't have one, which is equivalent to a zero-length string
one:
11:25:57 134826 ├───item-res:
There's the result of that internal ${lookup}. Empty.
This would be the place to fix, as a workaround for the issue discovered
in your LDAP backend.
You then go on to do the ldapdn lookup:
11:25:57 134826 ├──expanding: user=${lookup
ldapdn{user="CN=svc_domainjoin,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
pass="password" ldaps://
auth.example.com/OU=Service%20Accounts,DC=ad,DC=example,DC=com?dn?sub?(uid=${quote_ldap_dn:$auth1})}}
pass=${quote:$auth2} ldaps://auth.example.com/
11:25:57 134826 ╰─────result: user= pass=bar ldaps://auth.example.com/
11:25:57 134826 ╰──(tainted)
And you are passing that empty value in the "user=" element:
> 11:25:57 134826 LDAP parameters: user= pass=bar size=0 time=0 connect=0
dereference=0 referrals=on
11:25:57 134826 perform_ldap_search: ldapauth URL = "ldaps://
auth.example.com/ " server=NULL port=0 sizelimit=0 timelimit=0 tcplimit=0
11:25:57 134826 after ldap_url_parse: host=auth.example.com port=636
11:25:57 134826 re-using cached connection to LDAP server
auth.example.com:636
11:25:57 134826 re-binding with user= password=bar
11:25:58 134826 Bind succeeded: ldapauth returns OK
... and the bind succeeds. That's up to the LDAP backend, even if we regard it
as a bug.
Because the bind succeeded, Exim's ldapauth condition returns true, per its
specification.
11:25:58 134826 ├──expanding: ${if and{ { !eq{}{$auth1} } { ldapauth {
user=${lookup
ldapdn{user="CN=svc_domainjoin,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
pass="password" ldaps://
auth.example.com/OU=Service%20Accounts,DC=ad,DC=example,DC=com?dn?sub?(uid=${quote_ldap_dn:$auth1})}}
pass=${quote:$auth2} ldaps://auth.example.com/ } } } }
11:25:58 134826 ╰─────result: true
So the entire expansion returns "true".
11:25:58 134826 SMTP>> 235 Authentication succeeded
And therefore, the Exim authenticator accepts the offered strings.
--
Cheers,
Jeremy
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
