I have an OpenLDAP 2.4.42 server in which I have loaded an LDIF file that contains (among other entries) the following: # james, staff, yoyodyne.com dn: uid=james,ou=staff,dc=yoyodyne,dc=com uid: james cn: james objectClass: account objectClass: posixAccount loginShell: /bin/bash uidNumber: 1010 gidNumber: 100 homeDirectory: /home/james Separately, I have a Centos 7 box that retrieves user information from the OpenLDAP server above, by means of the Name Service Switch framework in the Centos 7 system. Users to be authenticated in this box may not be defined locally, but in the OpenLDAP server alone; PAM has been configured in the Centos system so that, for such users, and when attempting to log in over SSH, a directory is created in the Centos box on the fly as necessary, using the path retrieved from the OpenLDAP server in the homeDirectory attribute for the user. The authentication itself is carried out by a remote RADIUS server; PAM is correctly configured for this too. This works fine as described, in that when one attempts to log in over SSH into the Centos system as james, provided that the right password is supplied, the '/home/james' directory is created in the Centos system and an interactive SSH session is established. What I would be interested in next is an OpenLDAP setup so that the entry for a given user can be retrieved from the OpenLDAP server in a case-insensitive manner. The goal is to be able to authenticate username, password pairs over the SSH interface in the Centos7 system, with the username being cases-insensitive. As far as I can tell, in the process of establishing an SSH session, the OpenSSH daemon in the Centos 7 system will attempt to verify that the username is valid by invoking the gepwnam() Linux system call. This function will attempt to retrieve information for its argument - a username string - in a case-sensitive way. It first looks into the relevant local files and, if nothing is found and the NSS framework is appropriately configured, it will next attempt to obtain the data from an LDAP server. PAM helps me here by providing a PAM module (pam_regex) which enables me to normalize incoming usernames - in essence, this module makes is easy to recast all incoming usernames to strings where all uppercase letters are transformed into their lowercase versions. The problem that I have is that OpenSSH invokes getpwnam() both before and after the pam_regex module has been invoked. Thus, if the username received from the client is, say, James, OpenSSH will invoke getpwnam("James") first, and getpwnam("james") later, after pam_regex has normalized "James". The upshot here seems to be that what I would need is an OpenLDAP setup such that when getpwnam("james") and getpwnam("James") - or any other case combination of "James" - are invoked, the OpenLDAP server would return the same user data. 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. I guess that the question would be the following: Is it possible to configure OpenLDAP so that getpwnam() can retrieve a given entry from the OpenLDAP server in a case-insensitive way? How would one create an entry for a user identified as James so that getpwnam("James"), getpwnam("james"), getpwnam("JAMES"), etc. would all cause the OpenLDAP server to return exactly the same Linux user data (uidNumber, gidNumber, homeDirectory)? Other than the obvious and impractical approach consisting of creating identical entries for all the case combinations of the target name, that is.
Replying to myself, to add something I inadvertently omitted: I am aware that the /etc/nslcd.conf file, that is used to configure the interaction with the LDAP server through NSS in Centos, supports an option (ignorecase) that would enable me to do what I want. The thing is, that option might be a bit too powerful, in that it will eliminate case-sensitive in situations where that might not be advisable - hence my question. I am, however, willing to accept that, in the end, 'ignorecase' may be equivalent to what I am asking anyway, if that's the way it is.
On Tuesday, August 13, 2019, 09:25:26 AM MDT, JC lovecraftesque@yahoo.com wrote:
I have an OpenLDAP 2.4.42 server in which I have loaded an LDIF file that contains (among other entries) the following: # james, staff, yoyodyne.com dn: uid=james,ou=staff,dc=yoyodyne,dc=com uid: james cn: james objectClass: account objectClass: posixAccount loginShell: /bin/bash uidNumber: 1010 gidNumber: 100 homeDirectory: /home/james Separately, I have a Centos 7 box that retrieves user information from the OpenLDAP server above, by means of the Name Service Switch framework in the Centos 7 system. Users to be authenticated in this box may not be defined locally, but in the OpenLDAP server alone; PAM has been configured in the Centos system so that, for such users, and when attempting to log in over SSH, a directory is created in the Centos box on the fly as necessary, using the path retrieved from the OpenLDAP server in the homeDirectory attribute for the user. The authentication itself is carried out by a remote RADIUS server; PAM is correctly configured for this too. This works fine as described, in that when one attempts to log in over SSH into the Centos system as james, provided that the right password is supplied, the '/home/james' directory is created in the Centos system and an interactive SSH session is established. What I would be interested in next is an OpenLDAP setup so that the entry for a given user can be retrieved from the OpenLDAP server in a case-insensitive manner. The goal is to be able to authenticate username, password pairs over the SSH interface in the Centos7 system, with the username being cases-insensitive. As far as I can tell, in the process of establishing an SSH session, the OpenSSH daemon in the Centos 7 system will attempt to verify that the username is valid by invoking the gepwnam() Linux system call. This function will attempt to retrieve information for its argument - a username string - in a case-sensitive way. It first looks into the relevant local files and, if nothing is found and the NSS framework is appropriately configured, it will next attempt to obtain the data from an LDAP server. PAM helps me here by providing a PAM module (pam_regex) which enables me to normalize incoming usernames - in essence, this module makes is easy to recast all incoming usernames to strings where all uppercase letters are transformed into their lowercase versions. The problem that I have is that OpenSSH invokes getpwnam() both before and after the pam_regex module has been invoked. Thus, if the username received from the client is, say, James, OpenSSH will invoke getpwnam("James") first, and getpwnam("james") later, after pam_regex has normalized "James". The upshot here seems to be that what I would need is an OpenLDAP setup such that when getpwnam("james") and getpwnam("James") - or any other case combination of "James" - are invoked, the OpenLDAP server would return the same user data. 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. I guess that the question would be the following: Is it possible to configure OpenLDAP so that getpwnam() can retrieve a given entry from the OpenLDAP server in a case-insensitive way? How would one create an entry for a user identified as James so that getpwnam("James"), getpwnam("james"), getpwnam("JAMES"), etc. would all cause the OpenLDAP server to return exactly the same Linux user data (uidNumber, gidNumber, homeDirectory)? Other than the obvious and impractical approach consisting of creating identical entries for all the case combinations of the target name, that is.
--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:
#attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 14.08.2019 um 01:09 in
Nachricht <59A1EC7FB57F5649201E5D92@[192.168.1.144]>:
‑‑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:
#attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
However UNIX is not case-insensitive. We had the case that entering a valid user's name in capital letters (dammed Shift-lock key) caused an authentication failure, and nscd in turn cached that (case-insensitively), so after that even entering the user name in lower case caused a (cached) authentication failure. (I had tried to convince support that this is a bug in nscd, but failed to convince them)
So be warned: UNIX is not case-insensitive!
Regards, Ulrich
Regards, Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
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.
Thanks everybody for your feedback. If I understand things correctly, there is really nothing much that one can do in the OpenLDAP, for the attribute I am interested in is defined to have case-insensitive values already. Since the string comparison carried out by getpwnam() in Linux is case-sensitive, my only way out seems to be to use 'ignorecase yes' in my /etc/nslcd.conf file - not really that desirable, for a number of reasons, but probably OKin my case.
On Tuesday, August 13, 2019, 05:09:54 PM MDT, Quanah Gibson-Mount quanah@symas.com 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:
#attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
JC -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl