Re: Regarding #8580

On Fri, 9 May 2025 at 12:48, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
wrote:

>
>
> On Fri, May 9, 2025 at 4:50 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Fri, 9 May 2025 at 12:14, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
>> wrote:
>>
>>>
>>>
>>> On Fri, May 9, 2025 at 4:20 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 9 May 2025 at 11:34, Khushboo Vashi <
>>>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, May 9, 2025 at 3:23 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi <
>>>>>> akshay(dot)joshi(at)enterprisedb(dot)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(at)xyz(dot)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(at)xyz(dot)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