Okay, so last week I finally got authentication to work between two Ubuntu virtual machines through LDAP. I accomplished this with the PADL_migrationtools package, had to edit a few of the .ldifs by hand so that the server would accept them (removing kerberos items and the like). It still didn't work which drove me up a wall until a helpful soul on #ldap on freenet mentioned that nscd might be running and messing things up (which was precisely the case). So I was pretty elated, being as I'd been working over getting this to work for so long.
After this I wiped the ldap database and started using the PADL migrationtools again on the actual server cluster that we need to use the authentication data from. Again, I had to tweak it a little bit by hand, but managed to get it all accepted by the ldap server without too much trouble.
When I started testing the new directory, I first realized that nothing was working correctly because I had lost the 'admin' account when I wiped the previous database and never made a new one. So, I got that fixed. However I was still having issues authenticating as the ldap admin, using ldapsearch to try to verify that the data was correctly being served. After some further testing I realized that I can authenticate properly when using ldapsearch with the -x flag, but not in the standard manner.
At this point I'm starting to wonder what on earth must've changed. I didn't tweak any of the configuration files for slapd on the server or for openldap on either machine. All of the /etc/pam.d files are in the same configuration that was working for me previously. TLS configuration is the same with the proper certs in the right areas... All of these things I confirmed by successful authentication through pam using ssh and login previously. On the client machine getent passwd is showing the correct information and as root, getent shadow is showing all of the information as well. Still, I cannot bind without the -x with ldapsearch; I can't even run the search anonymously without the -x. The errors that I am receiving in these cases are:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
Why, when ldap is serving the data properly, is it all of a sudden complaining about SASL? I really do not want to implement SASL until I understand it, anyway.
The errors I'm receiving from pam when trying to login using pam_ldap (taken from /var/log/auth.log) are:
May 14 16:52:18 URtr login[4322]: pam_unix(login:auth): authentication failure; logname=dgetsman uid=0 euid=0 tty=tty2 ruser= rhost= user=dgetsman
May 14 16:52:18 URtr login[4322]: pam_ldap: ldap_search_s No such object
May 14 16:52:20 URtr login[4322]: FAILED LOGIN (1) on 'tty2' FOR `dgetsman', Authentication failure
The config files I'm using are at:
All of this was working for me just fine before, but now I just can't bind without that -x on the command line utilities, and when I login on the machine, I can't do it if it's trying to get the shadowed password information from ldap. Everything else is handled correctly, but looking for that one particular entry it will not take it through ldap, only from the files...
I would really appreciate if somebody could clue me in a little bit more about why this is all of a sudden trying to use SASL, how I can disable it, and how I can resume binding again so that I can get those shadowed passwords served so that I can start authenticating with this non-testing data now. I'm not having any luck finding documentation on this as of right now.
Thanks in advance!
<a href="-Damon A. Getsman
Linux/Solaris Sysadmin
</a>
After this I wiped the ldap database and started using the PADL migrationtools again on the actual server cluster that we need to use the authentication data from. Again, I had to tweak it a little bit by hand, but managed to get it all accepted by the ldap server without too much trouble.
When I started testing the new directory, I first realized that nothing was working correctly because I had lost the 'admin' account when I wiped the previous database and never made a new one. So, I got that fixed. However I was still having issues authenticating as the ldap admin, using ldapsearch to try to verify that the data was correctly being served. After some further testing I realized that I can authenticate properly when using ldapsearch with the -x flag, but not in the standard manner.
At this point I'm starting to wonder what on earth must've changed. I didn't tweak any of the configuration files for slapd on the server or for openldap on either machine. All of the /etc/pam.d files are in the same configuration that was working for me previously. TLS configuration is the same with the proper certs in the right areas... All of these things I confirmed by successful authentication through pam using ssh and login previously. On the client machine getent passwd is showing the correct information and as root, getent shadow is showing all of the information as well. Still, I cannot bind without the -x with ldapsearch; I can't even run the search anonymously without the -x. The errors that I am receiving in these cases are:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
Why, when ldap is serving the data properly, is it all of a sudden complaining about SASL? I really do not want to implement SASL until I understand it, anyway.
The errors I'm receiving from pam when trying to login using pam_ldap (taken from /var/log/auth.log) are:
May 14 16:52:18 URtr login[4322]: pam_unix(login:auth): authentication failure; logname=dgetsman uid=0 euid=0 tty=tty2 ruser= rhost= user=dgetsman
May 14 16:52:18 URtr login[4322]: pam_ldap: ldap_search_s No such object
May 14 16:52:20 URtr login[4322]: FAILED LOGIN (1) on 'tty2' FOR `dgetsman', Authentication failure
The config files I'm using are at:
All of this was working for me just fine before, but now I just can't bind without that -x on the command line utilities, and when I login on the machine, I can't do it if it's trying to get the shadowed password information from ldap. Everything else is handled correctly, but looking for that one particular entry it will not take it through ldap, only from the files...
I would really appreciate if somebody could clue me in a little bit more about why this is all of a sudden trying to use SASL, how I can disable it, and how I can resume binding again so that I can get those shadowed passwords served so that I can start authenticating with this non-testing data now. I'm not having any luck finding documentation on this as of right now.
Thanks in advance!
<a href="-Damon A. Getsman
Linux/Solaris Sysadmin
</a>