On 8/14/19 1:09 AM, Quanah Gibson-Mount wrote:
> --On Tuesday, August 13, 2019 4:25 PM +0000 JC
> <lovecraftes...@yahoo.com> wrote:
>> Now it seems to be the case that, with a user entry in OpenLDAP as
>> described above, getpwnam("james") will look for an entry such that the
>> its uid attribute takes the value "james". I.e. if the value of uid is,
>> say, "James" then it will be ignored. Which, following the discussion
>> above, doesn't fit my goal.
> The "uid" attribute is explicitly defined to be case insensitive in
> RFC1274, see section 9.3.1 "userid".  This is reflected in the OpenLDAP
> core schema:

Some more notes to add:

Having EQUALITY caseIgnoreMatch means that "(uid=james)" and
"(uid=James)" will return entries containing all variants of etc. JAMES,
James, jAmEs.

This also means that enabling unique overlay (slapo-unique) will enforce
case-insensitive uniqueness on uid values, so that there are now two
distinct entries matching uid=james and uid=James.

This solves searching for the entry by user name.

The other big problem is that POSIX standard defines all POSIX names
(user names, group names) to be case-sensitive. This matches also the
case-sensitive file name semantics. So one has to look more closely on
how the NSS subsystem used handles this. The default for nss-pam-ldapd
(aka nslcd) treats 'uid' values retrieved from LDAP server as

Even if you switch to case-insensitive handling in /etc/nslcd.conf you
might run into issues with applications consuming the data via NSS.

To avoid all this mess in my Æ-DIR I'm always normalizing the 'uid'
values (and 'cn' values in group entries) to lower-case and avoid mixed
cases by proper data maintenance.

Ciao, Michael.

Reply via email to