Re: Regarding #8580

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.

--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com