On Fri, 9 May 2025 at 12:14, Akshay Joshi <akshay.jo...@enterprisedb.com> wrote:
> > > On Fri, May 9, 2025 at 4:20 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 3:23 PM Dave Page <dp...@pgadmin.org> wrote: >>> >>>> Hi >>>> >>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>> akshay.jo...@enterprisedb.com> wrote: >>>> >>>>> Hi Hackers/Dave, >>>>> >>>>> I have started working on issue #8580 >>>>> <https://github.com/pgadmin-org/pgadmin4/issues/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 = >>>>> ['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 only >>>>> internally. His/her account will never get locked. >>>>> >>>>> This behavior appears to be incorrect to me. I’m 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 >>>>> 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 authentication. >>>>> 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 in >>> our database), the next in line should be checked if one fails.= >>> >> >> 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 consistently > 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. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com
