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 1uDLIz-009T12-39 for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 10:50:13 +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 1uDLIx-00AGhi-Cu for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 10:50:11 +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 1uDLIx-00AGhU-4U for pgadmin-hackers@lists.postgresql.org; Fri, 09 May 2025 10:50:11 +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 1uDLIt-0010bM-2K for pgadmin-hackers@postgresql.org; Fri, 09 May 2025 10:50:10 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-54fc9e3564cso249568e87.2 for ; Fri, 09 May 2025 03:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1746787807; x=1747392607; 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=Yq9CLcKVCsjrCVi6tmZ3aB+fMGo41TDoFSsS8y/3SfU=; b=cWEtGf8eszZusjoxXptaTI1y1L8EXLuJpGm8Wk0Fn2/nRHUzUdCKWRtaU9xiQxlDQe buCp3ptxW7rMmsulPDD53+TC4UtjuX5iMiRsLEeXMKPdg9ZxVWKXLKSFuHT2FZ3DHUC1 mqarq7pMNXY+1m2s1F598Ts2aXyblouXHe6TterMc6Oh36Dx86Ie1tadOg0kRag7Fuzu qgJM0qVg+mXHb1IoFmLqKAHU7CyVieUVP1dFeM9rPNgLaLRXgjmocGMgh8/N2Q3C1zK7 eoSQRrJi0260Md0eLCV8Djj/EB3uSdPkUJHrtWMEyZisjuCgO5o6ZcgS9snhEuLav/2r TZOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746787807; x=1747392607; 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=Yq9CLcKVCsjrCVi6tmZ3aB+fMGo41TDoFSsS8y/3SfU=; b=PbukyCu2SWffhAc8wOtiHua80NJfXy807yByFQ7VnwxdhmZnYg47pcYrVmkC7PRnpb 4GbUUwVk5MN0JFE+LOt/RC1Efpx65GuskeekH9DdagYox70lp4S6m0OF0U24HXvOxP4j FJG60VtVtJ5fEgjWKW6EfiWcU+JBXx1+ioxnBKugXzKCO4WiX0PURlt5u63m0tjdWMHF VMjMKsjRCUi2pK/lq1DtxoheF0oFENb1NZMOu6FoomMhFXy0y/jB9ijDbVDPZysCyPvx dCc+Zrkxfm0hdyhUxHW+x0KAnVlguO0eh2db+y+9YsbfFdapxPw1qTIEAi9wn6VTend2 HVyw== X-Forwarded-Encrypted: i=1; AJvYcCUKypoYYgBZTK85a0hnYwVjaAdHmorPMGzKF6KfLxPpi/qT1VAsK8C1DwFhjcJvLTNGFt3eiJIr5jE+w6B66SQ=@postgresql.org X-Gm-Message-State: AOJu0YwHtNJgXbchchUBs0hBUxpoeEOduSP3SgpxIPyBg2QlTMqxs/dd 085Z6AocFULjUGzoQlgUUXh1mr/AOREVvH0IEOjw6mv+3kpDv+cugqKv2cMIi0oLqDIlEmtyodN Wu6iJ2upHSSR+LCH6qsri2aJWCuaIQ1Mq37aC X-Gm-Gg: ASbGncsWDvBBxcn1GcRFwLg6YpaV4o73na6fvVr9JVDcY/d869yRe1Pwq0tLnh+WJc0 y1c1kzh6n6ApQYGxwEaCJ6EaylMj3So2dlSK6vvVzhH33aNvrTkP4UeyQ930n4QD26M8jXfSGjD L5zMNE+ObNKF93mPRVffRplOv1 X-Google-Smtp-Source: AGHT+IH4T9xMHSPQT3UaSm/NPJA4H3+Ge7JQKAAGFDNlEI1mbSZWCpHD7uKNF49oJSYRv17rF8eVVAckwfOKIGhuzBQ= X-Received: by 2002:a05:6512:acf:b0:54e:85bc:d13e with SMTP id 2adb3069b0e04-54fc67e2d9cmr1026713e87.52.1746787807076; Fri, 09 May 2025 03:50:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 9 May 2025 11:49:56 +0100 X-Gm-Features: ATxdqUHD_9RBqrcrxsAXt8imuomVsV7C_36g2wocPq-3yIWmAwnRrYm-WhfKXx4 Message-ID: Subject: Re: Regarding #8580 To: Khushboo Vashi Cc: Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000bd36990634b1ba01" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bd36990634b1ba01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 9 May 2025 at 11:34, Khushboo Vashi wrote: > > > On Fri, May 9, 2025 at 3:23=E2=80=AFPM Dave Page wrot= e: > >> Hi >> >> On Fri, 9 May 2025 at 08:45, Akshay Joshi >> 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 e= rror >>> 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 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 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 data= base. >>> >>> 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 authentication. If it fai= ls, >>> 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 erro= r >>> without checking for the next authentication source. >>> >>> Yes. >> > > > If the user is registered for multiple authentications (per entries in ou= r > 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. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --000000000000bd36990634b1ba01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 9 May 2= 025 at 11:34, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:


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

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

I have started working on issue = #8580,=C2=A0where the correct error message should be displayed based o= n the user's authentication source when an incorrect password is provid= ed.


=
This behavior appears to be incorrect to me. I=E2=80=99m proposing two= possible solutions to address it:
Solution 1 (Logic Changes):= =C2=A0
Scenario 1: ['internal', 'ldap']:
  • If a user exists in the database with the specified au= thentication source (internal), attempt to authenticate using internal. If = authentication fails, return an error. No need to check for the LDAP or nex= t auth source.
<= 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">
  • If no user-auth source combin= ation is found for internal, proceed to the next authentication source (LDA= P). Attempt LDAP login, and if successful (and auto-create is enabled), cre= ate the user in the database.


--
--000000000000bd36990634b1ba01--