Hi On Mon, 12 May 2025 at 03:07, Akshay Joshi <akshay.jo...@enterprisedb.com> wrote:
> Hi Dave/Hackers, > > We found another scenario during testing. I know these cases can be > tricky, but they’re valid. For example, if the auth sources are set to > ['ldap', > 'internal'] and there's both an LDAP and internal user with the same > email (e.g., "a...@xyz.com"). > > If the LDAP user tries to log in but forgets the password, the system > first checks LDAP, then internal. Since the internal login also fails, the > error shown is for the internal user, not LDAP. This can confuse users. > I'm not sure how it would confuse users; "Incorrect username or password" applies in both cases - and we shouldn't be exposing information about which authentication methods were attempted and subsequently failed anyway, as that leaks information that could be useful to an attacker. > To avoid this kind of confusion, it might be better to add a separate > 'Login with LDAP' button on the login page (Please refer to the attached > screenshot). This way, users can choose the right option directly. > > On Fri, May 9, 2025 at 6:31 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> 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 >> >> -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com
