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 1uDNMH-009t95-Ju for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 13:01:46 +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 1uDNMG-00AjlB-6H for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 13:01:44 +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 1uDNMF-00Ajl0-Md for pgadmin-hackers@lists.postgresql.org; Fri, 09 May 2025 13:01:43 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uDNMC-000xJX-20 for pgadmin-hackers@postgresql.org; Fri, 09 May 2025 13:01:42 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-3104ddb8051so21153161fa.1 for ; Fri, 09 May 2025 06:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1746795700; x=1747400500; 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=vIF7zCwABtNw7sKG9Bqz9H66sl4gnJw5i9fA2AsHVGM=; b=Sub+UfQiEye9FKqGv5ILWo4bTyJWbo+rWXdvgd9nl4lNZlk2H7KGrdCi04Sgrd+hWy pC577C3vvSPAcNoeik79qjyH2pkuj9BOszLAbTOdTwkyZbhivSZ5NORwoKnUF1aknvtf 5yMUJ+CErexYGstWUxfJoBh1QMpGOIhQKtN9mjlqbjHcJiiRchmhap0ZP5mMqHYfuR/3 INE+nJ44TMANgRww/M/Tzy+R8qOSU2iZclxckoTS2N+CX3u1517T3kRvwy8kbnchwdjg sClWQDcCH73G963kEdG2MvZguovxhvlpycDHEV3Im9GYmzmtiZzq7F0q/CtTJp0QhuWg 9TsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746795700; x=1747400500; 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=vIF7zCwABtNw7sKG9Bqz9H66sl4gnJw5i9fA2AsHVGM=; b=K+pCwg148UPf3jLBLiu0eVzghy6XesE9wnVKZJlZhOWV2jGfxyzlkOMTHCirvvXKn8 2FwCWLlNA7RISuKJZ8X/YSnISeToMi0/aLMzd0Da6rXhhKbELShFGCP9SGBENA9mRTFv 1NnXCQ/Fy7C+uxil7gB2Swt0r6azERRPKEyvLQ6bJ9gqhqdidTRdiA18N9K+1mPf9J++ Zf0z74Gzs2Z3+7B6rkDr/JF0v9c4uvk5dPVZ0Y6LuetizB+blkyl35zS9Capzq61UXiy qKf04MdacqvfYAS1hDLya4iRmYywox9jfFVK2JevKs6DLR2OOVV9yFyKC52qj9SGm+Dz 2N7Q== X-Forwarded-Encrypted: i=1; AJvYcCXjPVHnxWBPxL18/q00I//L8NshVnPJeo8mlHhvMSljr4V8Or5rZE52Xm/Wh/cLSytZIsyW4i/NqREnD2l1WvE=@postgresql.org X-Gm-Message-State: AOJu0YxO/UEEI7p13AJ0RhuIjU5rTlhlr9bB3imYxo5ESTKJdlD0x0jk Gy8ivcN5Lql/n3LRgFf591F0i0FKDUw3g129otN40peIp/w0F5H9B2EDusVjOE1ixw/sNPGBiKc mHuYVc3+1hJsEl5djDSCJXmTywYJHA+Ru5mN5 X-Gm-Gg: ASbGnctL7D1u5xIH9UnA3pfABg0/QNf0FfrysfzfJQjqAntL3GW4DNEAK9FvyIGgYz2 trZNXzRTLr/ORzs91mybOHy8wq379h1OM9S3f/tEanTOBOrO6hvgO3c4rmFPBUWV3fUBMGMNVNI 7N5U6VMYF7220Pq4MDShrce0YX X-Google-Smtp-Source: AGHT+IF586Ewj8LoauaN25KvJj+u0mjLrWgsAPsdYUcMYinFtfw4KuRwd/Fgvvcw6dzxwGO5wy23BOu889bV714yKeg= X-Received: by 2002:a05:651c:322b:b0:30b:bba5:ac18 with SMTP id 38308e7fff4ca-326c4539511mr14423811fa.3.1746795698596; Fri, 09 May 2025 06:01:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 9 May 2025 14:01:27 +0100 X-Gm-Features: ATxdqUEjmWwqkUvsTthOKUd5BN0y9SPIdFhI8IQHU_-AYcVxMPpJdmABGfYR_ts Message-ID: Subject: Re: Regarding #8580 To: Akshay Joshi Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000001c43550634b391e0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001c43550634b391e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 9 May 2025 at 12:48, Akshay Joshi wrote: > > > On Fri, May 9, 2025 at 4:50=E2=80=AFPM Dave Page wrot= e: > >> >> >> On Fri, 9 May 2025 at 12:14, Akshay Joshi >> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 4:20=E2=80=AFPM Dave Page wr= ote: >>> >>>> >>>> >>>> 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 corresponding = LDAP >>>>>>> entry for this user. When this user attempts to log in with an inco= rrect >>>>>>> password, the system first tries internal authentication, which fai= ls. It >>>>>>> then proceeds to check the next authentication source (LDAP), as pe= r the >>>>>>> configured logic. Since no matching LDAP user exists, an LDAP-relat= ed error >>>>>>> is returned, even though the user is intended to be authenticated o= nly >>>>>>> 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 Changes): * >>>>>>> *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 t= he 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 l= ogin, and >>>>>>> if successful (and auto-create is enabled), create the user in t= he 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 authenticat= ion. 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 = error >>>>>>> without checking for the next authentication source. >>>>>>> >>>>>>> Yes. >>>>>> >>>>> >>>>> >>>>> If the user is registered for multiple authentications (per entries i= n >>>>> 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 configure= d >>> order), and then attempts LDAP if the user exists. However, it consiste= ntly >>> 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 Creat= e > User' functionality will not be triggered. > > I think we can either keep the current behavior as it is and close th= e > issue (since I reported it), or add a rule with documentation saying that > login should follow the order of the authentication sources. In most case= s, > 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. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --0000000000001c43550634b391e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


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


On Fri, 9 May 2025 at 12:14, Akshay Joshi <akshay.joshi@enter= prisedb.com> wrote:


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


On F= ri, 9 May 2025 at 11:34, Khushboo Vashi <khushboo.vashi@enterprisedb.com&g= t; wrote:

<= /div>
O= n Fri, May 9, 2025 at 3:23=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
Hi

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

I have star= ted working on issue #8580,=C2=A0where the correct error message= should be displayed based on the user's authentication source when an = incorrect password is provided.

Actual Issue:=C2=A0The admin has configured AUTHENTICATION_SOURCES =3D ['internal&= #39;, 'ldap']. A user with the email a@xyz.com exists only as an internal user in the datab= ase, 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 inte= rnal authentication, which fails. It then proceeds to check the next authen= tication source (LDAP), as per the configured logic. Since no matching LDAP= user exists, an LDAP-related error is returned, even though the user is in= tended to be authenticated only internally. His/her account will never get = locked.

This behavior appears to be incorrect to m= e. I=E2=80=99m proposing two possible solutions to address it:
Solution 1 (Logic Changes):=C2=A0
Scenario 1: ['inter= nal', 'ldap']:
  • If a user exists in the da= tabase with the specified authentication source (internal), attempt to auth= enticate using internal. If authentication fails, return an error. No need = to check for the LDAP or next auth source.
Yes.=C2=A0
  • I= f no user-auth source combination is found for internal, proceed to the nex= t 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', 'internal']=C2=A0=
  • If the LDAP user does not exist in=C2=A0the database, bu= t the same=C2=A0user exists=C2=A0as an internal user, first try LDAP authen= tication. If it fails, fall back to internal or the next configured auth so= urce in the list.=C2=A0
Yes.=C2=A0
  • If the LDAP user does ex= ist in the database, attempt to authenticate via LDAP. If LDAP authenticati= on fails, return the error without checking for the next authentication sou= rce.
Yes.


If the user is registered for multip= le authentications (per entries in our database), the next in line should b= e 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 remains unresolved. As= mentioned earlier, the system checks internal authentication first (based = on the configured order), and then attempts LDAP if the user exists. Howeve= r, 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.= =C2=A0

=C2=A0 =C2=A0 One = more scenario I just thought of with 'Auto Create User'. Suppose th= at=C2=A0a@xyz.com<= /code> exists as an internal user in the database, but there is no correspo= nding LDAP entry. When the user attempts to log in with an incorrect passwo= rd, the system checks the database for entries from other authentication so= urces and throws an error. In this case, the 'Auto Create User' fun= ctionality 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 s= hould 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.=C2=A0

Right, I believe that would be the typical cas= e.
=C2=A0
--
--0000000000001c43550634b391e0--