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 1uEnUm-00DB3r-35 for pgadmin-hackers@arkaria.postgresql.org; Tue, 13 May 2025 11:08:24 +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 1uEnUk-004oq0-N2 for pgadmin-hackers@arkaria.postgresql.org; Tue, 13 May 2025 11:08:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uEnUk-004ops-DM for pgadmin-hackers@lists.postgresql.org; Tue, 13 May 2025 11:08:22 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uEnUh-001fBL-0n for pgadmin-hackers@postgresql.org; Tue, 13 May 2025 11:08:21 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-54fd1650b83so3090277e87.2 for ; Tue, 13 May 2025 04:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1747134498; x=1747739298; 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=RQZmZ0yX055/wEMda7AxlsISqZq8rhuBRbR1Msnzuxc=; b=jZu0tNb7qYn0bOkjx4paAqzLiv7sxi7cVk3OBizVuHmGOU8zkK4hPFImfGLuaBq3Jh qmNQtFya8lKNGUcBI/ftxppIWklK9352i9p/D5bL8H9yswv2bhjdrQSQtv0WuLF0o7P9 LDvv9KarmHLe/4ZUsY5fub7d/teGNwPwb7Q15lOMPcaYWMTARtM8EaBUtY/ui1PNqcWU CEZ7psBopz5DR+6Fp6Tuuu27FjuFDvNa2lnSA7z41Sijxh5JpqdRQtvoBhUBsabDVZLE LaCd/xLVU6T6/xPQVUYIGBz95CFpBvXY3ZPUxuRI5f2C6UqvCteYBAmxQtcx0fPv/vIM OV4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747134498; x=1747739298; 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=RQZmZ0yX055/wEMda7AxlsISqZq8rhuBRbR1Msnzuxc=; b=bjmIdlcPAyqr5NWxBr9ZacXwMFu7eqlWdfWk8UWwM6z8ooqkSHQw2nDuHRu6caQ0TB xZatN7q05HuE9cobWFvKBfdlUR1C0gBZwBV+RCY1GnQHuwg7ZfiAH5KkScXpXGvJY2re pZZ5gjdD0ZtNLM60Czasjh3Ad07VLnqGdarYnYkyT7fL1de6infnUmSjDCcVYGPfysJy JDxkv/NuuK3VDLGXDqLcocX7Tyb5lBQQXzgDNIVw3oslRJaQIYdNVgqcTuX9Yk/jFeid 3HyU0eE8TBX5PQWJNzhiEwQbOZLtHzyZaJ5RNZkXYzHO9gAS2mJfeMKGR2iFrQTE8Fb8 9GRQ== X-Forwarded-Encrypted: i=1; AJvYcCUl2kq+pNsJjqObOAiJT60rw8HMbOtUKv/7jry4nKiSP/HKGieHeP7v2Z4d2WJxq7D2qlmGofV0zy+t8Rhr2Pw=@postgresql.org X-Gm-Message-State: AOJu0Yzzbp8gKQrUwr5q2HyhRiYLhEQmKnejotikD4RwzOWBAXjCFoTD ypE/c0bYHuB7MCgJVzUHsYDQBW+xuz0SUyElPnAZNrqw84n8OKo3na8RwPNn7SDVuxCSSq21ht8 GElO1h64lNAoAnKN/hRh9+fdYdfHHMLna61yB X-Gm-Gg: ASbGnctcgEbtgJ5cfLzcVzhnpOx+qDGgjW8wZHKY+xKGFlxpQDusR7/xTXgF6JP5YNC mB/hPFRzz0sLP6i8EUAz2j8Fvc4CRrijrQXsTHeJv/tv2BjgLWcHlZU3zIjIZ2NRIlYkFCbwMOJ drjo8Va4/SFB0t0vqxHe+EAgvvIwbNa04Wos5bp6AgP80= X-Google-Smtp-Source: AGHT+IFE2Kf5gyF/mwpcuQcB7Eg1ae9Zlcy3qfkQjWERpom5V3NCOPz4P35q7NRJ/RDLKysoZKCjJ3ctIlLvCcO06FI= X-Received: by 2002:a05:6512:1246:b0:54d:68d3:eeec with SMTP id 2adb3069b0e04-54fc67ec917mr6267723e87.52.1747134498176; Tue, 13 May 2025 04:08:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Tue, 13 May 2025 07:08:06 -0400 X-Gm-Features: AX0GCFv65D6sjrOLm2b-LW8MIcV0pgv6ue-i-SFbMDLkPsPQ6IfK62WWzbGxH8E Message-ID: Subject: Re: Regarding #8580 To: Akshay Joshi Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="00000000000023952f0635027390" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000023952f0635027390 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Mon, 12 May 2025 at 03:07, Akshay Joshi wrote: > Hi Dave/Hackers, > > We found another scenario during testing. I know these cases can be > tricky, but they=E2=80=99re valid. For example, if the auth sources are s= et to ['ldap', > 'internal'] and there's both an LDAP and internal user with the same > email (e.g., "a@xyz.com"). > > If the LDAP user tries to log in but forgets the password, the system > first checks LDAP, then internal. Since the internal login also fails, th= e > error shown is for the internal user, not LDAP. This can confuse users. > I'm not sure how it would confuse users; "Incorrect username or password" applies in both cases - and we shouldn't be exposing information about which authentication methods were attempted and subsequently failed anyway, as that leaks information that could be useful to an attacker. > To avoid this kind of confusion, it might be better to add a separate > 'Login with LDAP' button on the login page (Please refer to the attached > screenshot). This way, users can choose the right option directly. > > On Fri, May 9, 2025 at 6:31=E2=80=AFPM Dave Page wrot= e: > >> >> >> On Fri, 9 May 2025 at 12:48, Akshay Joshi >> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 4:50=E2=80=AFPM Dave Page wr= ote: >>> >>>> >>>> >>>> On Fri, 9 May 2025 at 12:14, Akshay Joshi < >>>> akshay.joshi@enterprisedb.com> wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 9, 2025 at 4:20=E2=80=AFPM Dave Page = wrote: >>>>> >>>>>> >>>>>> >>>>>> 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 wrote: >>>>>>> >>>>>>>> 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 correspondin= g LDAP >>>>>>>>> entry for this user. When this user attempts to log in with an in= correct >>>>>>>>> password, the system first tries internal authentication, which f= ails. It >>>>>>>>> then proceeds to check the next authentication source (LDAP), as = per the >>>>>>>>> configured logic. Since no matching LDAP user exists, an LDAP-rel= ated error >>>>>>>>> is returned, even though the user is intended to be authenticated= only >>>>>>>>> internally. His/her account will never get locked. >>>>>>>>> >>>>>>>>> This behavior appears to be incorrect to me. I=E2=80=99m proposin= g two >>>>>>>>> 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 usin= g internal. >>>>>>>>> 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= login, 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 authentic= ation. If it >>>>>>>>> fails, fall back to internal or the next configured auth sourc= e in the >>>>>>>>> list. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>>>> >>>>>>>>> - If the LDAP user does exist in the database, attempt to >>>>>>>>> authenticate via LDAP. If LDAP authentication fails, return th= e error >>>>>>>>> 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 th= e >>>>> configured order), and then attempts LDAP if the user exists. However= , it >>>>> consistently returns an error for LDAP, and the account is never lock= ed >>>>> even after exceeding the maximum number of login attempts. >>>>> >>>> >>>> So, just lock all matching accounts. >>>> >>> >>> One more scenario I just thought of with 'Auto Create User'. Suppos= e >>> that a@xyz.com exists as an internal user in the database, but there is >>> no corresponding LDAP entry. When the user attempts to log in with an >>> incorrect password, the system checks the database for entries from oth= er >>> authentication sources and throws an error. In this case, the 'Auto Cre= ate >>> User' functionality will not be triggered. >>> >>> I think we can either keep the current behavior as it is and close >>> the issue (since I reported it), or add a rule with documentation sayin= g >>> that login should follow the order of the authentication sources. In mo= st >>> cases, users who prefer LDAP can just set the auth source to ['ldap', >>> 'internal'], which should work fine. >>> >> >> Right, I believe that would be the typical case. >> >> -- >> Dave Page >> pgAdmin: https://www.pgadmin.org >> PostgreSQL: https://www.postgresql.org >> pgEdge: https://www.pgedge.com >> >> --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --00000000000023952f0635027390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Mon, 12 May 2025 at 03:07,= Akshay Joshi <akshay.j= oshi@enterprisedb.com> wrote:
Hi=C2=A0Dave/Hackers,

We found another scenario during testing.= I know these cases can be tricky, but they=E2=80=99re valid. For example, = if the auth sources are set to ['ldap', 'internal'] and there's both an LDAP and internal user with the same email (e= .g., "a@xyz.com").

If the LDAP user tries to log in but forgets the password, the system fi= rst checks LDAP, then internal. Since the internal login also fails, the er= ror shown is for the internal user, not LDAP. This can confuse users.

I'm not sure how it would confuse users; &q= uot;Incorrect username or password" applies in both cases - and we sho= uldn't be exposing information about which authentication methods were = attempted and subsequently failed anyway, as that leaks information that co= uld be useful to an attacker.
=C2=A0

To avoid this kind of confusion, it might be better to add a separate &#= 39;Login with LDAP' button on the login page (Please refer to the attac= hed screenshot). This way, users can choose the right option directly.

<= /div>

On Fri, May 9, 2025 at 6:31=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
<= /div>


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


On Fri, May 9, 202= 5 at 4:50=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
=


=
On Fri, 9 May 2025 at 12:14, Akshay J= oshi <akshay.joshi@enterprisedb.com> wrote:


On Fri, May 9, 2025 at 4:20=E2=80=AFPM D= ave Page <dpage@p= gadmin.org> wrote:


On Fri, 9 May 2025 at 11:34, Khushboo Vashi <khushboo.vashi@en= terprisedb.com> wrote:


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

On Fri, 9 May 2= 025 at 08:45, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:
Hi Hackers/Dave,

I have started working on issue #8580,=C2=A0where the co= rrect error message should be displayed based on the user's authenticat= ion source when an incorrect password is provided.

Actual Issue:=C2=A0The admin has configured AUTHENTICATION_SOURCES = =3D ['internal', 'ldap']. A user with the email a@xyz.com exists only as an interna= l user in the database, and there is no corresponding LDAP entry for this u= ser. When this user attempts to log in with an incorrect password, the syst= em first tries internal authentication, which fails. It then proceeds to ch= eck the next authentication source (LDAP), as per the configured logic. Sin= ce no matching LDAP user exists, an LDAP-related error is returned, even th= ough the user is intended to be authenticated only internally. His/her acco= unt will never get locked.

This behavior appears t= o be incorrect to me. I=E2=80=99m proposing two possible solutions to addre= ss it:
Solution 1 (Logic Changes):=C2=A0
Scen= ario 1: ['internal', 'ldap']:
  • If a us= er exists in the database with the specified authentication source (interna= l), attempt to authenticate using internal. If authentication fails, return= 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 internal,= proceed to the next authentication source (LDAP). Attempt LDAP login, and = if successful (and auto-create is enabled), create the user in the database= .
Yes.
=C2=A0
Scenario 2: ['ldap', 'intern= al']=C2=A0
  • If the LDAP user does not exist in=C2= =A0the database, but the same=C2=A0user exists=C2=A0as an internal user, fi= rst try LDAP authentication. If it fails, fall back to internal or the next= configured auth source in the list.=C2=A0
Yes.=C2=A0
  • If th= e LDAP user does exist in the database, attempt to authenticate via LDAP. I= f LDAP authentication fails, return the error without checking for the next= authentication source.
Yes.


If the user is re= gistered for multiple authentications (per entries in our database), the ne= xt 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.

=C2=A0 In that case, the core issue rem= ains unresolved. As mentioned earlier, the system checks internal authentic= ation first (based on the configured order), and then attempts LDAP if the = user exists. However, it consistently returns an error for LDAP, and the ac= count is never locked even after exceeding the maximum number of login atte= mpts.

So, just lock all m= atching accounts.=C2=A0

= =C2=A0 =C2=A0 One more scenario I just thought of with 'Auto Create Use= r'. Suppose that=C2=A0a@xyz.com exists as an internal user in the database, but th= ere is no corresponding LDAP entry. When the user attempts to log in with a= n incorrect password, the system checks the database for entries from other= authentication sources and throws an error. In this case, the 'Auto Cr= eate User' functionality will not be triggered.

=C2=A0 =C2=A0 I think we can either keep the current behavior as it is an= d close the issue (since I reported it), or add a rule with documentation s= aying that login should follow the order of the authentication sources. In = most cases, users who prefer LDAP can just set the auth source to [&#= 39;ldap', 'internal'], which should work fine.=C2=A0

Right, I believe that would = be the typical case.
=C2=A0
--


--
--00000000000023952f0635027390--