Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uDLmk-009ZQT-Mq for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 11:20:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uDLmj-00AL7x-Jy for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 11:20:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uDLmj-00AL7n-8Z for pgadmin-hackers@lists.postgresql.org; Fri, 09 May 2025 11:20:57 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uDLmg-000way-0O for pgadmin-hackers@postgresql.org; Fri, 09 May 2025 11:20:56 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-326bb1d3e34so16165791fa.3 for ; Fri, 09 May 2025 04:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1746789653; x=1747394453; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fTQhDlrDl+iYpWIWn7AS1qvYsEXnDQcf1aGZ6tmwvOg=; b=Rm/3UTpL2Na/QRcq8A66SBaWH8uB0svcRwC/RrnqKsYrNKONN3+jPKU+Zx+wJQ1PSR xp4GptF4ejpMczUzTyYk5J+rH2D8GikxhTgXAR684bV9hq/jP8NoxmpWL9jVbHADiUtP EEv/Z/Jv5isGyq1D/CfEJtkewLdLtmmOgqXHUvyQJ3QPFmuHO9nJ6E9zTSDDU6BXcoY6 uAPUmHNh0U1eN92RFMDQGetH//xzk6+z6KVClX/LYtHJZagzBVHHxoUBhsP1FOqqO8u4 wXKgke4eLEDTgKWuRbxES+T4CJ78hCrHPR2MT+3rG/iRMneswstTkzbQM5qQ5L6cqbca IPOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746789653; x=1747394453; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fTQhDlrDl+iYpWIWn7AS1qvYsEXnDQcf1aGZ6tmwvOg=; b=fhoMqKOePfGxwOTmzXX4B1fZaWeY34MfOvBxdF/qaSdce03dwT3Gv+0VABnCbONcgO g7+KYs+Bf9sbFtrmGU1lwINpWdM7aB/SDr0J9mqS6hNj8d3+CgFs0SkKadKiGOChxqQ5 bfkilBVULL6c2uqgqcGo9jTNBvIYSEC0cd889ipBmIOKXYufLWhzyqQ1DwuYxxj2w0MS rH3YTVAt1BpD84CAwiO2pxF/Bg2qyvenriyZvf9yb7nACXadFR2c8bRuIeDw0E+bvyaw vqQyXq9RzVjsqEywvGEVHyHVIVrQUQjFK/7POi57l35yDeENTof8chaywXDPwDA9LxEo jYkw== X-Forwarded-Encrypted: i=1; AJvYcCW15Y8Ycsi0iki30MZ728s4UFyvVLFQN7/jsHZIqPuM7OMoCHU3dOR/ErY+oR/Uh0T6foHb0Vsu0fh8Ai54x7A=@postgresql.org X-Gm-Message-State: AOJu0YzWgfbyWbazrwBtzYLYMvTESCHiaxtacprPEBe4FFXzTLlfJI7a 5XRPASwji/2Kc07Lqf48fnxjiyIdrkGS1470iyuT1VC522aTPxK4PA67qwfV1MH0Bp9v2bA6o/b sMKFQLr8Tkwutddtoaa6vNgHP4YB8RZxz42Io X-Gm-Gg: ASbGnct43IR7Pr/an28m8x5vdvbCO+/Wgt5TdU3dY4WFFsvBUj1qHcYpKaNvOU9mI/a doJYpPi+mIFjU+B99FNrRueEVnGCMjHvc97dBAaPjdKkZJm+4KX1MHLIyW0xQ7cygxKBHzs1kRB GWANH0RQOj+WtgdYbCCTW5wJ2n/arrm6iksgU= X-Google-Smtp-Source: AGHT+IH0a2vwIQc5VceeMvyFW7p4sh4iJUusKqZw4+p3Y+DIU/m4HI2Hq75VmL+tYeGb2u0v/MA7b6rkEk1gMONE2fw= X-Received: by 2002:a2e:bd0b:0:b0:30c:7a7:e87c with SMTP id 38308e7fff4ca-326c46acaa8mr11617491fa.35.1746789652980; Fri, 09 May 2025 04:20:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 9 May 2025 12:20:42 +0100 X-Gm-Features: ATxdqUG4SSKe0Xk0NfR_Q_lNwAcnXodzyBY8ByDpgDsFwgNo_zJ7bUKnRIwqI5E Message-ID: Subject: Re: Regarding #8580 To: Akshay Joshi Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000c379f70634b22817" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c379f70634b22817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 9 May 2025 at 12:14, Akshay Joshi wrote: > > > On Fri, May 9, 2025 at 4:20=E2=80=AFPM Dave Page wrot= e: > >> >> >> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >> khushboo.vashi@enterprisedb.com> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 3:23=E2=80=AFPM Dave Page wr= ote: >>> >>>> Hi >>>> >>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>> akshay.joshi@enterprisedb.com> wrote: >>>> >>>>> Hi Hackers/Dave, >>>>> >>>>> I have started working on issue #8580 >>>>> , where the >>>>> correct error message should be displayed based on the user's >>>>> authentication source when an incorrect password is provided. >>>>> >>>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES =3D >>>>> ['internal', 'ldap']. A user with the email a@xyz.com exists only as >>>>> an internal user in the database, and there is no corresponding LDAP = entry >>>>> for this user. When this user attempts to log in with an incorrect >>>>> password, the system first tries internal authentication, which fails= . It >>>>> then proceeds to check the next authentication source (LDAP), as per = the >>>>> configured logic. Since no matching LDAP user exists, an LDAP-related= error >>>>> is returned, even though the user is intended to be authenticated onl= y >>>>> internally. His/her account will never get locked. >>>>> >>>>> This behavior appears to be incorrect to me. I=E2=80=99m proposing tw= o >>>>> possible solutions to address it: >>>>> *Solution 1 (Logic Changes): * >>>>> *Scenario 1: ['internal', 'ldap']:* >>>>> >>>>> - If a user exists in the database with the specified >>>>> authentication source (internal), attempt to authenticate using in= ternal. >>>>> If authentication fails, return an error. No need to check for the= LDAP or >>>>> next auth source. >>>>> >>>>> Yes. >>>> >>>>> >>>>> - If no user-auth source combination is found for internal, >>>>> proceed to the next authentication source (LDAP). Attempt LDAP log= in, and >>>>> if successful (and auto-create is enabled), create the user in the= database. >>>>> >>>>> Yes. >>>> >>>> >>>>> *Scenario 2: ['ldap', 'internal']* >>>>> >>>>> - If the LDAP user does not exist in the database, but the >>>>> same user exists as an internal user, first try LDAP authenticatio= n. If it >>>>> fails, fall back to internal or the next configured auth source in= the >>>>> list. >>>>> >>>>> Yes. >>>> >>>>> >>>>> - If the LDAP user does exist in the database, attempt to >>>>> authenticate via LDAP. If LDAP authentication fails, return the er= ror >>>>> without checking for the next authentication source. >>>>> >>>>> Yes. >>>> >>> >>> >>> If the user is registered for multiple authentications (per entries in >>> our database), the next in line should be checked if one fails.=3D >>> >> >> I think that's reasonable, but *only* in that case where there's another >> source already present in the DB. >> > > In that case, the core issue remains unresolved. As mentioned earlier, > the system checks internal authentication first (based on the configured > order), and then attempts LDAP if the user exists. However, it consistent= ly > returns an error for LDAP, and the account is never locked even after > exceeding the maximum number of login attempts. > So, just lock all matching accounts. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --000000000000c379f70634b22817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 9 May 2= 025 at 12:14, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:


On Fri, May 9, 2025 at 4:20=E2=80=AF= PM Dave Page <dpa= ge@pgadmin.org> wrote:


On Fri, 9 May 2025 at 11:34, Khushboo Vashi <khushboo.vash= i@enterprisedb.com> wrote:


On Fri, May 9, 2025 at 3:23=E2=80=AFPM Dave Page <= ;dpage@pgadmin.org> wrote:

<= div class=3D"gmail_quote">
On Fri, 9 M= ay 2025 at 08:45, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:
=
Hi Hackers/Dave,
I have started working on issue #8580,=C2=A0where th= e correct error message should be displayed based on the user's authent= ication source when an incorrect password is provided.

=
Actual Issue:=C2=A0The admin has configured AUTHENTICATION_SOUR= CES =3D ['internal', 'ldap']. A user with the email a@xyz.com exists only as an int= ernal user in the database, and there is no corresponding LDAP entry for th= is user. When this user attempts to log in with an incorrect password, the = system first tries internal authentication, which fails. It then proceeds t= o check the next authentication source (LDAP), as per the configured logic.= Since no matching LDAP user exists, an LDAP-related error is returned, eve= n though the user is intended to be authenticated only internally. His/her = account will never get locked.

This behavior appea= rs to be incorrect to me. I=E2=80=99m proposing two possible solutions to a= ddress it:
Solution 1 (Logic Changes):=C2=A0
= Scenario 1: ['internal', 'ldap']:
  • If = a user exists in the database with the specified authentication source (int= ernal), attempt to authenticate using internal. If authentication fails, re= turn an error. No need to check for the LDAP or next auth source.
=
Yes.=C2=A0
  • If no user-auth source combination is found for inter= nal, proceed to the next authentication source (LDAP). Attempt LDAP login, = and if successful (and auto-create is enabled), create the user in the data= base.
Yes.
=C2=A0
Scenario 2: ['ldap', 'in= ternal']=C2=A0
  • If the LDAP user does not exist in= =C2=A0the database, but the same=C2=A0user exists=C2=A0as an internal user,= first try LDAP authentication. If it fails, fall back to internal or the n= ext configured auth source in the list.=C2=A0
Yes.=C2=A0
  • If= the LDAP user does exist in the database, attempt to authenticate via LDAP= . If LDAP authentication fails, return the error without checking for the n= ext authentication source.
Yes.


If the user is= registered for multiple authentications (per entries in our database), the= next in line should be checked if one fails.=3D

I think that's reasonable, but *only* in that c= ase where there's another source already present in the DB.
=

=C2=A0 In that case, the core issue = remains unresolved. As mentioned earlier, the system checks internal authen= tication first (based on the configured order), and then attempts LDAP if t= he user exists. However, it consistently returns an error for LDAP, and the= account is never locked even after exceeding the maximum number of login a= ttempts.

So, just lock al= l matching accounts.=C2=A0

--
<= div dir=3D"ltr">Dave Page
--000000000000c379f70634b22817--