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 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.