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 1uDMEJ-009eRa-P2 for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 11:49:28 +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 1uDMDJ-00ANIX-VT for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 11:48:25 +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 1uDMDJ-00ANIO-MO for pgadmin-hackers@lists.postgresql.org; Fri, 09 May 2025 11:48:25 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uDMDF-0010xR-0y for pgadmin-hackers@postgresql.org; Fri, 09 May 2025 11:48:24 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-54afb5fcebaso2596284e87.3 for ; Fri, 09 May 2025 04:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1746791300; x=1747396100; 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=Ka99VfoTsFkmaYq2EdTZWM3NjQQkh4x+9MNEB10ry7U=; b=de8GbHl2jUuieIpy04/ItLG5YJu0GrED2Eb5ZrBGYohWN44G0LBG5elq6e0+Dbmlh6 4inF5Nl295UUOQ1nzACZJI8BHmFygUuUntqlMFIfzUiAgD1TcNGV00IJtVRpoyoI/6+P JsiQ32Gq4qQM4rc3gkK440xX75+KnPF1Dax2Lb5vmK2Xf79YhbYvR1DJ1ZxjK2rVd2xX mPTM4bfRm1ssov+tuBJ3LcokWemLkDJ7gTmNF6KE8vfAcMeGM0uEP5x/mgQQ2mqSxGCV nD8pmL+90DCNjryVftm7UwrCWveO7xl0ih/TxcB9GyW8lTB/Tl/j4Zw9IFV1he55xWh9 Mz8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746791300; x=1747396100; 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=Ka99VfoTsFkmaYq2EdTZWM3NjQQkh4x+9MNEB10ry7U=; b=qzwAk42giRgEVkFwMuf7KkaxiIh59khbyYL4uqb9f9kaBADApnQjXKDgngzzeYasME /yIPDZHDhpy9winiGLIuEh0GY6zH6alZXa9K60985THm1164YKYS5+OSFityaDrLRwT4 dn3oWRojdHiYfmDPIEG3+5ZGVvDv0a13kBCwP5h/vmkI9tkshQxJVrQssZ1Mhl4mfFsM kzt7SWUkK9bfAxpPZlNlcYTeubU1UL77AuzO/TzZzGWhLBRIQqSsW/6buBRbw3OgyQIE yE4HSGB14y/Uz+S0bgMuKVZomtLfQePbXEWOuToaezJimNxQhlHiPpqS1Vb9/3AciokE +yvw== X-Forwarded-Encrypted: i=1; AJvYcCW1+HcuxG5KFBu8XazfQvem2vjNx2ZkSXve55VMbVeugZf4V+Mk4dCA1Qo9mohCCIIgSFBoQhlQJUzR/M4NjHQ=@postgresql.org X-Gm-Message-State: AOJu0YybHAYHXyN+542Kd8Tu3iknONbbUCvNJxWu/TNStFshSwn/h29e 8kZymyv2SHrnXhCu6snDz1U71BBg8RQQxfXND+JnNdF5rMSEoPaE3I9tazF5b3oM/+nLj8iJgGV bxXqmyFQs3bGkopGbmWV12/LMbX6Zmn0s4yjG X-Gm-Gg: ASbGncuQqVNXW1T5vg4qWjuXRSyQ9pFblay3ve7ChdwJa8IPAbyzQIBRb8m8OlToden JCf9N58yBwvTWH1p8/XGFEpjrK60Xr63AxzapQEmhnLeRwQMufsZStU/ULGQ3EY0FVu60s2DRLq p+ruwfxEjHGpxb+y+A24WJr4Cc5rA9kh5T3GFQ+nk+vARIHuPr2wpWQw== X-Google-Smtp-Source: AGHT+IFwfT5VjEaAyKijFOwsWhD1rXjz9B28gRll1b3g9SQbSg5UAIWdqF0Lmb8nCP8UcbZS6MAwOedim12VGeN2gi8= X-Received: by 2002:a05:6512:631a:b0:54b:1055:f4c0 with SMTP id 2adb3069b0e04-54fc67acf5bmr1072856e87.4.1746791300237; Fri, 09 May 2025 04:48:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Akshay Joshi Date: Fri, 9 May 2025 17:18:08 +0530 X-Gm-Features: AX0GCFuP-rJequqFRXccc-9dMcKnMimDOQupI4KG0COSSGbF6Jv7i7AHFs5-GgU Message-ID: Subject: Re: Regarding #8580 To: Dave Page Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000f2a80e0634b28ae4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f2a80e0634b28ae4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 9, 2025 at 4:50=E2=80=AFPM Dave Page wrote: > > > On Fri, 9 May 2025 at 12:14, Akshay Joshi > wrote: > >> >> >> On Fri, May 9, 2025 at 4:20=E2=80=AFPM Dave Page wro= te: >> >>> >>> >>> 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 w= rote: >>>> >>>>> 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 fail= s. It >>>>>> then proceeds to check the next authentication source (LDAP), as per= the >>>>>> configured logic. Since no matching LDAP user exists, an LDAP-relate= d error >>>>>> is returned, even though the user is intended to be authenticated on= ly >>>>>> internally. His/her account will never get locked. >>>>>> >>>>>> This behavior appears to be incorrect to me. I=E2=80=99m proposing t= wo >>>>>> 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 i= nternal. >>>>>> If authentication fails, return an error. No need to check for th= e 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 lo= gin, and >>>>>> if successful (and auto-create is enabled), create the user in th= e 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 authenticati= on. If it >>>>>> fails, fall back to internal or the next configured auth source i= n the >>>>>> list. >>>>>> >>>>>> Yes. >>>>> >>>>>> >>>>>> - If the LDAP user does exist in the database, attempt to >>>>>> authenticate via LDAP. If LDAP authentication fails, return the e= rror >>>>>> 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 anothe= r >>> 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 consisten= tly >> 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. > One more scenario I just thought of with 'Auto Create User'. Suppose 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 other authentication sources and throws an error. In this case, the 'Auto Create 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 saying that login should follow the order of the authentication sources. In most cases, users who prefer LDAP can just set the auth source to ['ldap', 'internal'], which should work fine. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > --000000000000f2a80e0634b28ae4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


On Fri, 9 May 2025 a= t 12:14, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:


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


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


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

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

I have started working on issue #8580,=C2=A0where the correct error message should be displayed base= d on the user's authentication source when an incorrect password is pro= vided.

Actual Issue:=C2=A0The admin has con= figured AUTHENTICATION_SOURCES =3D ['internal', 'ldap']. A = user with the email a@xyz.co= m exists only as an internal user in the database, and there is no corr= esponding LDAP entry for this user. When this user attempts to log in with = an incorrect password, the system first tries internal authentication, whic= h fails. It then proceeds to check the next authentication source (LDAP), a= s 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 authenticate= d only internally. His/her account will never get locked.

This behavior appears to be incorrect to me. I=E2=80=99m proposing = two possible solutions to address it:
Solution 1 (Logic Change= s):=C2=A0
Scenario 1: ['internal', 'ldap']= :
  • If a user exists in the database with the specified= authentication source (internal), 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
<= ul>
  • If no user-auth source combination is found for internal, proceed to= the next authentication source (LDAP). Attempt LDAP login, and if successf= ul (and auto-create is enabled), create the user in the database.
    • =
    Yes.
    =C2=A0
    Scenario 2: ['= ;ldap', 'internal']=C2=A0
    • If the LDAP use= r does not exist in=C2=A0the database, but the same=C2=A0user exists=C2=A0a= s an internal user, first try LDAP authentication. If it fails, fall back t= o internal or the next configured auth source in the list.=C2=A0
    <= /div>
    Yes.=C2=A0
    • If the LDAP user does exi= st in the database, attempt to authenticate via LDAP. If LDAP authenticatio= n fails, return the error without checking for the next authentication sour= ce.
    Yes.


    If the user is registered for multipl= e 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 a= nother source already present in the DB.

    =C2=A0 In that case, the core issue remains unresolved. As = mentioned earlier, the system checks internal authentication first (based o= n the configured order), and then attempts LDAP if the user exists. However= , it consistently returns an error for LDAP, and the account is never locke= d even after exceeding the maximum number of login attempts.

    So, just lock all matching accounts.=C2= =A0

    =C2=A0 =C2=A0 One mor= e scenario I just thought of with 'Auto Create User'. Suppose that= =C2=A0a@xyz.com exists as an = internal user in the database, but there is no corresponding LDAP entry. Wh= en the user attempts to log in with an incorrect password, the system check= s the database for entries from other authentication sources and throws an = error. In this case, the 'Auto Create User' functionality will not = be triggered.

    =C2=A0 =C2=A0 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 saying that login should follow the ord= er of the authentication sources. In most cases, users who prefer LDAP can = just set the auth source to ['ldap', 'internal'], which should work fine.=C2=A0

    --
    --000000000000f2a80e0634b28ae4--