bcrypt < 5 always truncated overlong passwords for us, since version 5
we need to do that on our own or hope our password library does it for
us.
In order to support both passlib and libpass with bcrypt >= 5 we simply
truncate if needed so it does not matter which of the two libraries is
used.
Closes: #1896
Signed-off-by: Henning Schild <henning@hennsch.de>
In the failed login cache cleanup loop, the tuple unpacking was using
`login` as the local variable name, silently overwriting the current
user's login with the one retrieved from the expired cache entry.
This caused subsequent backend authentication (e.g. IMAP) to be
attempted with the wrong username, resulting in spurious auth failures
for legitimate users whenever an expired failed-cache entry happened
to be present at the same time.
Rename the loop variable to `login_expired` to avoid shadowing the
outer `login` variable, and fix the associated debug log to reference
`login_expired` instead of the previously incorrect `login_cache`.
Fixes: intermittent authentication failures when _cache_failed contains
expired entries from previous failed login attempts by other users.
Signed-off-by: webmaster <webmaster@jbsky.fr>
For ldapi:// connections, which connect - by definition - to a local UNIX
socket, lower the value of config setting 'ldap_ssl_verify_mode' to "NONE"
to avoid certificate validation failures.
The UNIX socket address can NEVER match any DNS name from a certificate,
making the whole certificate validation moot.
This is a workaround for a limitation of Python's LDAP modules, that do not
consider this edge case.
* treat 'ldap_ssl_verify_mode' as string
* perform check for accepted values; fail on illegal ones
* translate to the values nbeeded by the respective LDAP module
when doing the login, based on a module specific dictionary
Python's ldap module, which is modelled along OpenLDAP's API, allows us to
keep the connection and doing a new bind as a different user, superseding
the previous bind.
Use this to simplify the code and avoid duplication.
Until now, every connection to the LDAP server was silently unencryptedr
when using Python's ldap module instead of the ldap3 module.
I.e. using Python's ldap module was inherently insecure, as there was not
even a hint that the config settings for encryption were ignored.
This commit changes this and brings LDAP authentication based on the ldap
module feature-wise on par with the one based on the ldap3 module.
LDAP URIs starting with the scheme 'ldaps' are - by definition - meant to use
LDAPS instead of plain LDAP: infer 'ldap_security' = "tls" if it is not set.
* stop treating it as class property
* refactor to consolidate logic into one big 'if' statement
(for easier removal when the config option gets removed in the future)
* make deprecation warning for 'ldap_use_ssl' more urgent
* raise error if conflicting settings 'ldap_security' = "starttls" and
'ldap_use_ssl' = True are set together
* if not set, infer 'ldap_security' = "tls" from 'ldap_use_ssl' = True,
logging a warning for the admin to update the config
Currently it is not used by _login2(), but it does not hurt to have it
available.
It is a preparation for supporting encrypted connections in _login2().
The evaluation of the quirk for the Authentik LDAP server changes the behaviour
of Python's `ldap3` module, and that module only.
Evaluating the quirk in `__init__` which is used for both, `ldap` and `ldap3`
is thus wrong, and may lead to errors when this setting is used together with
the `ldap` module.
Signed-off-by: Peter Marschall <peter@adpm.de>
Make the remote IP parameter more generic and make it an enum
determining the source instead of a boolean. Also fix the
changelog entry.
Both as requested, I managed to miss those comments previously.
If known, let the auth server know where the client came
from, using REMOTE_ADDR or, optionally/configurably, the
X-Remote-Addr header value (which is needed when running
behind a trusted proxy.)
Addresses #1859.
Instead of searching for the membership attribute on the user side
(usually AD: memberOf, Novell eDirectory: groupMembership) to determine
the groups the user loging on is a member of, allow performing a separate
search for the groups having the user as member and use the found groups' DNs.
The group search is performed in the context of 'ldap_reader_dn', after
the user DN has been found in the directory, but before the authentication
has been performed by doing an LDAP bind in the user's context.
Although this may - in the case of unsuccessful login attempts -
double the number of queries to the LDAP server, it has been done
this way to keep the number of LDAP contexts minimal.
Doing the group search in the context of the user logging on is no viable
option, because there are known implementations where regular users do not
have the necessary permissions to query the groups they are a member in.
