If the user specifies the same LDAP search context more than once,
when we sync users we retrieve the same set of users twice. When we
try to insert the "duplicated" user in the temp table again, the db
barfs and the db layer aborts the whole transaction.
So we try to detect and remove duplicates. This is a bit tricky (LDAP
is such a complex and wonderful protocol) as the contexts are
distinguished names and the matching/comparison rules are complex. But
assuming that we only use the attribute types used in 99.999% of the
distinguished names used for contexts out there (that is: dc, ou, cn,
o, l and c), and also assuming that the user is not using different
encodings/escapings for the same context, we can lower case the
contexts to compare them (and remove duplicates).
This is safe according to RFC-4517 (section 4.2.15. distinguishedNameMatch)
and RFC-4519 (where the EQUAILITY property is defined for the
different user application attribute types).
This shouldn't break any configuration that wasn't broken before :)
Signed-off-by: Iñaki Arenaza <iarenaza@mondragon.edu>
It looks like array_change_key_case() does not work recursively, so we
were not actually lowercasing the expiration attribute key. As the
configuration setting is always lowercase they didn't match.
From 2.0 on we lowercase all the settings related to LDAP attributes
to cope with differences in LDAP servers when returning attribute
names as array indices (some lowercase them, some leave them as
specified in the query, some normalize them, etc.).
But we only lowercase them when saving the settings page. So on sites
that have been migrated from 1.x, it may happen that we still have
mixed-case attribute names. And this is fatal for the user_attribute
setting, as we might not detect it in the returned array from LDAP and
it will be empty (and the db layer throws and exception).
So we just make sure the attribute name is lowercased (and trimmed,
in case it's got some white space around it).
Signed-off-by: Iñaki Arenaza <iarenaza@mondragon.edu>
We need to specify a valid user id in the call to role_assign(). And we only
have to make the call if the user has been added successfully, not
otherwise.
Also make sure we lowercase the memberuser and group distinguished names
before comparing them. Depending on the LDAP server we can get mixed case
values for the DNs, and the user may have specified the creators group/ou
name in a different case.
By the way, this has been broken for ages (since the auth cleanup in 1.8, in
2007!). It's a bit strange nobody noticed before :-O
Credit goes to Joe Chryst.
They now share most of the code again, this time via subclassing, and they
share some code with enrol/ldap. They have also gained some features and a few
fixes.
As authentication and enrolment plugins now have a version number, the LDAP
version number setting was "shadowed" by the plugin version number. So we
rename the LDAP setting name to ldap_version, et voila!
AMOS START
REM fixed $a[] in [auth_dbdeleteuser, auth_db]
REM fixed $a[] in [auth_dbinsertuser, auth_db]
REM fixed $a[] in [auth_dbreviveduser, auth_db]
REM fixed $a[] in [auth_dbsuspenduser, auth_db]
REM fixed $a[] in [auth_dbupdatinguser, auth_db]
AMOS END
