On 8/14/19 1:09 AM, Quanah Gibson-Mount wrote:
--On Tuesday, August 13, 2019 4:25 PM +0000 JC lovecraftesque@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 case-sensitive.
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.