As it turns out, that ran--thanks! Now it's the lookup that's failing...or
was, till I changed it to dbm rather than dbmnz. I think this is done, once
I stir the other half of the eq statement back in.
Thanks to all who helped--it was very useful!
On Tue, Apr 22, 2025 at 4:48 PM Adam D. Barratt
On Tue, 2025-04-22 at 15:28 -0500, Johnnie Adams via Exim-users wrote:
> I've thinned this configuration down to the minimal failure:
[...]
> server_condition = ${if \
>
>
> eq{lookup{$auth1}dbmnz{/etc/exim/allowed_accounts.db}}{quote:$auth2}
> \
>
> }
>
> And I'm getting this error messa
I've thinned this configuration down to the minimal failure:
login:
driver = plaintext
server_set_id = $auth1
server_prompts = <| Username: | Password:
server_advertise_condition = ${if def:tls_in_cipher }
server_condition = ${if \
eq
On Tue, Apr 22, 2025 at 4:04 AM Jeremy Harris via Exim-users <
exim-users@lists.exim.org> wrote:
> On 2025/04/21 7:14 PM, Johnnie Adams via Exim-users wrote:
>
> > The second is, in the meantime, I've got a very small number of users
> which
> > need authentication--less than a dozen. I'm thinkin
On 2025/04/21 7:14 PM, Johnnie Adams via Exim-users wrote:
Honestly, I was flailing around, trying to mitigate the issue, but I think
that's a fool's errand. I'm abandoning trying to make this syntax work.
Understanding would be better than flailing.
The first is, if this is CVE-worthy, who t
On Wed, Apr 16, 2025 at 4:56 PM Jeremy Harris via Exim-users <
exim-users@lists.exim.org> wrote:
> On 2025/04/16 4:38 PM, Johnnie W Adams via Exim-users wrote:
>
> > 10:27:42 160885 re-binding with user=1 password=inner_password
>
> we move on to the "ldapauth" operation. That "1" you arranged
On 2025/04/16 4:38 PM, Johnnie W Adams via Exim-users wrote:
10:27:42 160885 ├considering: ${lookup
ldapdn{user="CN=outer_account,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
pass="outer_password" ldaps://
auth.example.com/OU=Service%20Accounts,DC=ad,DC=example,DC=com?dn?su
This is truly puzzling. I've changed out my authenticator to add parameters
where I think they should go:
server_condition = ${if and{ \
{ !eq{}{$auth1} } \
{ ldapauth { \
user=${lookup
ldapdn{user="CN=outer_account,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=ualr,DC=edu"
pas
This makes sense, and yet, I've tried adding {true}{false} (along with
{yes}{no} and now it is failing when I use good account information. I've
tried this, which I believe should be right:
user=${lookup
ldapdn{user="CN=svc_domainjoin,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
Johnnie W Adams via Exim-users wrote on 10.04.2025 20:29:
> Here's the full authenticator:
>
> begin authenticators
>
>
> login:
>
> driver = plaintext
>
> server_set_id = $auth1
>
> server_prompts = <| Username: | Password:
>
> server_adv
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=Servic
On Fri, Apr 11, 2025 at 6:22 PM Slavko via Exim-users <
exim-users@lists.exim.org> wrote:
> Dňa 10. 4. o 23:04 Johnnie W Adams via Exim-users napísal(a):
>
> > The coding should take both of the 'foo's in, because they are the
> > credentials to be used in the ldapauth test. And they really shou
On Fri, Apr 11, 2025 at 03:19:27PM -0500, Johnnie W Adams wrote:
>I'm still puzzled as to why the user is blank. I certainly entered it in
>the SMTP session.
For ldapauth "user" must be the so-called "Bind DN", special entry
in LDAP object tree, not a user name that was entered in SMTP
Dňa 10. 4. o 23:04 Johnnie W Adams via Exim-users napísal(a):
The coding should take both of the 'foo's in, because they are the
credentials to be used in the ldapauth test. And they really shouldn't be
giving back a 235 Authentication succeeded under any circumstances.
that is main problem
> On Thu, Apr 10, 2025 at 09:06:34PM +0100, Jeremy Harris via Exim-users wrote:
> > On 2025/04/10 8:19 PM, Johnnie W Adams via Exim-users wrote:
> > > 14:16:37 121712 re-binding with user= password=foo
> > >
> > > 14:16:37 121712 Bind succeeded: ldapauth returns OK
> >
> > OK, I see two possibl
On Fri, Apr 11, 2025 at 11:52 AM Chris Siebenmann via Exim-users <
exim-users@lists.exim.org> wrote:
> > On Thu, Apr 10, 2025 at 09:06:34PM +0100, Jeremy Harris via Exim-users
> wrote:
> > > On 2025/04/10 8:19 PM, Johnnie W Adams via Exim-users wrote:
> > > > 14:16:37 121712 re-binding with user=
On 2025/04/11 8:56 AM, Evgeniy Berdnikov via Exim-users wrote:
I do not know how decode this answer, and have no access to server logs,
but for me it looks like a bug in Microsoft's DC.
That seems CVE-worthy.
Meantime, the OP should write his inner lookup to never return an empty answer.
On Thu, Apr 10, 2025 at 09:06:34PM +0100, Jeremy Harris via Exim-users wrote:
> On 2025/04/10 8:19 PM, Johnnie W Adams via Exim-users wrote:
> > 14:16:37 121712 re-binding with user= password=foo
> >
> > 14:16:37 121712 Bind succeeded: ldapauth returns OK
>
> OK, I see two possible problems her
On Thu, Apr 10, 2025 at 3:42 PM Jeremy Harris via Exim-users <
exim-users@lists.exim.org> wrote:
> On 2025/04/10 9:31 PM, Johnnie W Adams via Exim-users wrote:
> > That combination should be user=foo password=foo, because that's what I'm
> > putting into openssl for the session.
>
> No; your codin
On 2025/04/10 9:31 PM, Johnnie W Adams via Exim-users wrote:
That combination should be user=foo password=foo, because that's what I'm
putting into openssl for the session.
No; your coding takes one of those foo's into ldap to get something
back, which it *then* uses in the ldapauth test.
--
C
On Thu, Apr 10, 2025 at 3:07 PM Jeremy Harris via Exim-users <
exim-users@lists.exim.org> wrote:
> On 2025/04/10 8:19 PM, Johnnie W Adams via Exim-users wrote:
> > 14:16:37 121712 re-binding with user= password=foo
> >
> > 14:16:37 121712 Bind succeeded: ldapauth returns OK
>
> OK, I see two pos
On 2025/04/10 8:19 PM, Johnnie W Adams via Exim-users wrote:
14:16:37 121712 re-binding with user= password=foo
14:16:37 121712 Bind succeeded: ldapauth returns OK
OK, I see two possible problems here.
- The exim ldapauth condition returned true for "user= password=foo".
Is that combinati
Here is it, using 'foo' as both account and password:
14:16:37 121712 login authenticator server_condition:
14:16:37 121712 $auth1 = foo
14:16:37 121712 $auth2 = foo
14:16:37 121712 $1 = foo
14:16:37 121712 $2 = foo
14:16:37 121712 ╭considering: ${if and{ { !eq{}{$auth1} } { ldapauth
On 2025/04/09 9:49 PM, Johnnie W Adams via Exim-users wrote:
What is strange is that I have made this work; however, I get 235
Authentication succeeded when I put in bad account information. It's almost
as though Exim is seeing the bind authentication as successful and not
caring about the
On 2025/04/10 6:29 PM, Johnnie W Adams via Exim-users wrote:
server_condition = ${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/
Here's the full authenticator:
begin authenticators
login:
driver = plaintext
server_set_id = $auth1
server_prompts = <| Username: | Password:
server_advertise_condition = ${if def:tls_in_cipher }
server_condition = ${if and{ \
{ !e
On Thu, Apr 10, 2025 at 10:43:00AM -0500, Johnnie W Adams via Exim-users wrote:
> 10:37:07 120872 ├──expanding: $auth1
> 10:37:07 120872 ╰─result: foo
> 10:37:07 120872 ╰──(tainted)
> 10:37:07 120872 SMTP>> 235 Authentication succeeded
Probably you've limited debug options to "e
On 2025/04/10 4:43 PM, Johnnie W Adams via Exim-users wrote:
So the bind authorization is succeeding, which leaves me with the question
of why I can do a 'real' authentication with the account 'foo' and the
password 'foo':
So you ned to look at how that result is being used, with reference
to t
So the bind authorization is succeeding, which leaves me with the question
of why I can do a 'real' authentication with the account 'foo' and the
password 'foo':
10:37:07 120872 ├──expanding: ${if and{ { !eq{}{$auth1} } { ldapauth {
user=${lookup
ldapdn{user="CN=svc_domainjoin,OU=SVCAccounts,OU=I
On 2025/04/10 3:00 PM, Johnnie W Adams via Exim-users wrote:
I don't know how much of the configuration you want to see, but here's the
lookup:
user=${lookup
ldapdn{user="CN=svc_domainjoin,OU=SVCAccounts,OU=ITS,OU=Organizations,DC=ad,DC=example,DC=com"
pass="password" ldaps://
auth.examp
I don't know how much of the configuration you want to see, but here's the
lookup:
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
Hi,
I'm following up on this now that I've gotten a little further and am
getting a very strange result.
What is strange is that I have made this work; however, I get 235
Authentication succeeded when I put in bad account information. It's almost
as though Exim is seeing the bind authen
As you can see, using "foo" and "bar" as my account information gets me
authenticated:
AUTH LOGIN
334 VXNlcm5hbWU6
Zm9v
334 UGFzc3dvcmQ6
YmFy
235 Authentication succeeded
On Wed, Apr 9, 2025 at 3:49 PM Johnnie W Adams wrote:
> Hi,
>
> I'm following up on this now that I've gotten a li
33 matches
Mail list logo
