On Fri, 9 May 2025 at 12:48, Akshay Joshi <akshay.jo...@enterprisedb.com> wrote:
> > > On Fri, May 9, 2025 at 4:50 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> 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. >> > > 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. > 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
