Tweet
I posted a question a while ago with regards to login names.
I find myself a little more educated now, but no farther along in solving my puzzle.
I have the ldap-auth package installed, and I have used oxldapsync to import user info to the database. Up to here, we are good, everything is going as expected. after here, things are not as I expect.
First, supporting info. I would like the usernames to be in the form of firstname.lastname. This is the way the uid attribute in ldap looks. In the oxldapsync mapping file, I have username mapped to uid, and oxldapsync successfully populated the usernames in this format to the login2user table. Also, in the ldapauth.properties file, I have made this entry: uidAttribute=uid. The comment above this line in the file would have me believe this is what I need to do to authenticate against the uid attribute of ldap. I then restarted the admin and groupware deamons.
This set up gives me a login failure when I try to login.
More supporting info: the cn attribute in ldap is in the form of "firstname lastname" (separated by a space this time instead of a dot).
If I manually update the login2user table to have "firstname lastname" instead of "firstname.lastname", and then change the ldapauth.properties file to be uidAttribute=cn, I am able to get logged in. Not with the name I want, but logged in.
I fail to understand why the space is allowed and the dot is not, and I fail to find a place to change the behaviour. I have found a variable CHECK_CONTEXT_LOGIN_MAPPING_REGEXP, which as far as I can tell allows dots and not spaces. Perhaps it is not the dot and space that are the problem, but the uid and cn attributes?
Just for fun, I changed the mapping for username in oxldapsync configuration to cn, found the uidAttribute setting in ldapsync.conf and changed it to cn, and then ran the oxldapsync.pl script. This deleted all users in the database. The only difference between the uid attribute that script will import, and the cn attribute that it will not, at least as far as I can see, is the dot and the space. The oxldapsync logs show no entries at all, and the slapd logs go along for a brief second, then pause, then eventually a message is printed that the connection is lost. From my limited perspective, it appears that the oxldapsync.pl script is not able to handle spaces in the username.
I will continue to drill for solutions, but can someone please point me at something that will help me understand how I can properly authenticate against my uid ldap attribute?
I find myself a little more educated now, but no farther along in solving my puzzle.
I have the ldap-auth package installed, and I have used oxldapsync to import user info to the database. Up to here, we are good, everything is going as expected. after here, things are not as I expect.
First, supporting info. I would like the usernames to be in the form of firstname.lastname. This is the way the uid attribute in ldap looks. In the oxldapsync mapping file, I have username mapped to uid, and oxldapsync successfully populated the usernames in this format to the login2user table. Also, in the ldapauth.properties file, I have made this entry: uidAttribute=uid. The comment above this line in the file would have me believe this is what I need to do to authenticate against the uid attribute of ldap. I then restarted the admin and groupware deamons.
This set up gives me a login failure when I try to login.
More supporting info: the cn attribute in ldap is in the form of "firstname lastname" (separated by a space this time instead of a dot).
If I manually update the login2user table to have "firstname lastname" instead of "firstname.lastname", and then change the ldapauth.properties file to be uidAttribute=cn, I am able to get logged in. Not with the name I want, but logged in.
I fail to understand why the space is allowed and the dot is not, and I fail to find a place to change the behaviour. I have found a variable CHECK_CONTEXT_LOGIN_MAPPING_REGEXP, which as far as I can tell allows dots and not spaces. Perhaps it is not the dot and space that are the problem, but the uid and cn attributes?
Just for fun, I changed the mapping for username in oxldapsync configuration to cn, found the uidAttribute setting in ldapsync.conf and changed it to cn, and then ran the oxldapsync.pl script. This deleted all users in the database. The only difference between the uid attribute that script will import, and the cn attribute that it will not, at least as far as I can see, is the dot and the space. The oxldapsync logs show no entries at all, and the slapd logs go along for a brief second, then pause, then eventually a message is printed that the connection is lost. From my limited perspective, it appears that the oxldapsync.pl script is not able to handle spaces in the username.
I will continue to drill for solutions, but can someone please point me at something that will help me understand how I can properly authenticate against my uid ldap attribute?
Comment