I would like some advice/assistance on how to troubleshoot an
authentication issue on a Debian Sarge box.

I had a fiasco today where one box that I recently acquired the
responsibility of administering was set to stable in the sources.list
but was running all sarge packages. I updated libnss-ldap, ssh, libssl,
and bind9 before realizing my error when authentication to my LDAP
server failed. I subsequently uninstalled the etch packages by manually
installing the sarge packages from /var/cache/apt/archives with dpkg -i
<pkgname>.

I rebooted the host and I am still unable to authenticate my ldap users
using password authentication from the console or using SSH. I am able
to authenticate using ssh's key-based auth where I see a message
indicating that I have no name. I also get the users UID number in any
process list, lsof output, or directory listings.

I have verified all of the /etc/pam.d/* files and /etc/nsswitch.conf,
/etc/libnss-ldap.conf, et al. I am able to authenticate to the LDAP
directory from other hosts on the network using the same configuration.

I'm assuming at this point that some package that I have installed and
subsequently uninstalled (most likely libnss-ldap) has not fully
reverted and I am suffering from a bad library or link. Does anyone
have a good method for troubleshooting this beyond using strace to trace
logins and processes, disabling nscd, and/or rebuilding the box? I
would really like to know how to track down this problem and fix it. I
am not giving a lot of configuration details since the configuration is
a known good one. I am more than willing to provide details on request.

Thanks a lot,

(new to debian)

--
Josh Miller - RHCE, VCP
Linux Solutions Provider
Seattle, WA USA
http://itsecureadmin.com/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Check the URI/host spec in /etc/libnss-ldap.conf to make sure it is
valid... there was a revision or few that mucked up in converting from
host to uri.

the syntax should be:
uri ldapi:/// (if you enabled that)
uri ldap:/// or ldap://fqdn/
uri ldaps://localhost:636/

The next problem comes in if ssl is in use, there are issues with the
code in determining to use ldaps:/// vs ldap:///
So if you need ssl, either use TLS, or force the port to :636

a few checks:
getent passwd <uid>
ldapsearch -Hldap:/// uid=<uid>

--
Rick Nelson
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you.
-- Vance Petree, Virginia Power


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Rich, thanks for the reply.

>
> Check the URI/host spec in /etc/libnss-ldap.conf to make sure it is
> valid... there was a revision or few that mucked up in converting from
> host to uri.

> The next problem comes in if ssl is in use, there are issues with the
> code in determining to use ldaps:/// vs ldap:///
> So if you need ssl, either use TLS, or force the port to :636

I'm fairly certain that the configuration is good. I am able to enumerate
users and groups with getent [passwd|group]. I am not using SSL/TLS at
this time. Also, ldapsearch -x works great in returning the directory
contents (as allowed by ACL) so I'm confident that the ldap configuration
is good.

As a workaround, I have added the LDAP account information to /etc/passwd
(but *not* shadow) and users are able to login successfully and everything
works as it should. This is not an ideal situation from a management
perspective, but it's working until I can build a new box or figure this
out.


--
Josh Miller, RHCE


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org