This tickles a bug as reported by Thorsten Marquardt in
https://sourceforge.net/p/davical/mailman/message/58766531/ with this
error message reported:
Exception [0] ldap_get_attributes(): Argument #2 ($entry) must be of
type LDAP\ResultEntry, false given
At line 718 of /usr/share/davical-master/inc/drivers_ldap.php
You need to look in 3da860e5d5e732c2dedb62a73c76608a2b7098a4 for that line
number as I've just made some improvements to the code the last few commits.
Add a new value for i_use_mode_kerberos: "allow_fallback_ldap_auth",
which will fallback to username/password authentication when the
REMOTE_USER value is unset.
Currently, when `i_use_mode_kerberos` is enabled in the LDAP driver,
Davical checks the `REMOTE_USER` server variable, followed by the
`REDIRECT_REMOTE_USER` variable, for a matching username. If a matching
username is not found, authentication fails immediately.
This commit modifies the LDAP driver to fallback to standard LDAP
password authentication when `i_use_mode_kerberos` is enabled and
neither of these server variables are set. This allows
non-kerberos-enabled clients to authenticate as well.
Fixes#323
Add a new 'sasl' option to the LDAP driver, which invokes
ldap_sasl_bind() instead of ldap_bind().
This allows authenticating to LDAP using the GSSAPI (kerberos) or
EXTERNAL mechanisms, rather than a bindDN and password.
Note that for GSSAPI binds, PHP needs access to valid kerberos
credentials (for example, by setting the KRB5CCNAME environment variable
for the PHP process).
Tested with OpenLDAP/Heimdal kerberos, but should also work with Active
Directory.
This changes 48c6512a70740c403027b66e9d609e9b871d29c0, in Eric's commit it
needs a flag to go fetch the record and apply the mapping to find the
username field. This approach looks for a telltale that this is DN (naively
an "=") and then either grabs the first element from the DN if the username
attr matches or fetches the entry from LDAP.
There have also been attempts in the past to special case uniqueMember and
to add a group_member_dnfix config option.
This should handle the cases where people use uid/cn/whatever for the
username.
The logic actually handled updated group details, but only new groups were
being passed in. This will cause changes to what is being used for the
fullname to flow through.
This is to be consistent with group_mapping_field. The code is backwards
compatible with mapping_field.
In sync_LDAP_groups assign user_mapping once, not for every group.
Usinger "username" for the group name is confusing and misleading. Just
use name, but support our users who still have username.
We don't use fullname, drop it from the example.
Deprecated: Required parameter $username follows optional parameter $attributes in inc/drivers_ldap.php on line 190
Deprecated: Required parameter $passwd follows optional parameter $attributes in inc/drivers_ldap.php on line 190
Deprecated: Required parameter $ua_string follows optional parameter $min_age in inc/external-fetch.php on line 42
As explained in https://www.php.net/manual/en/migration80.deprecated.php,
If a parameter with a default value is followed by a required
parameter, the default value has no effect. This is deprecated as of
PHP 8.0.0 and can generally be resolved by dropping the default
value, without a change in functionality
despite its name, $c->do_not_sync_from_ldap did not stop accounts in
LDAP from being created in Davical, it only stopped accounts not in LDAP
from being deactived in Davical (like a local admin account)
The checks to test if a "modified" attribute was found in the
$valid array used in_array, which fails.
Replace this with array_key_exists calls.
This fixes https://gitlab.com/davical-project/davical/issues/108
[ $mapping['modified'] is a key in $valid, not a value. This is a
regression introduced in 970b61ac, for 1.1.5 ]
