Hi Buchan,

summary first: the su - <network_user> problem is solved thanks to your question. ssh <network_user>@<client> works only under certain circumstances (see below).

...

I want to use TLS-communication between my ldap server and the clients.

[...]

...

Next, I activated TLSVerifyClient on the server side

Why ? You don't need this to address your single remaining problem, unless you haven't stated it in full.

Sorry, I did not point out that I want only valid users/services to be able to get information from the ldap server at all. A valid service or user shall be identified by a certificate that is signed by a valid CA of mine. All other connection attempts shall be rejected. That is how I understood the combination of TLS_REQCRT (to verify the server) and TLSVerifyClient (to verify the client). Am I wrong here?

Since I use the ldap server for network user authentication, I can (as local user) make a su - <network_user>, enter the password and get authenticated, but have a look at the shell:

<local user>@<client>:~$ su - <network_user> Password: <network user password here> id: cannot find name for group ID <network_user group> I have no name!@<client>:~$

Does 'strace -e open id' tell you anything interesting (specifically about the key/cert)?

Wow, one single question of yours gave me several hours of work and the solution for my first problem. Thanks ;-)

I ensured that the requested files are readable by the user (they already were, but I checked it again, even made a chmod -R 777 on the directory). This was not the problem.

But after creating a new certificate for that network user with the CN set to the users username (instead of the surname/name before), the problem with su - <network_user> disappeared. Now I can su from a certified local user to my network user.

<local user>@<client>:~$ su - <network user> Password: <network user>@<client>:~$

That's cool!

...

In /etc/ldap.conf (ubuntu 8.04 uses this as replacement for lib(pam|nss)_ldap.conf),

Actually, Ubuntu reverts back to the upstream location, lib(pam|nss)_ldap.conf is a Debian-ism.

Thanks for the info, did not know that.

...

I set the values for

tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem tls_key /usr/lib/ssl/private/<client>.ldap.key.pem

You didn't indicate any of the other /etc/ldap.conf settings, such as tls_cacertfile, tls_check_peer. Additionally, you don't specify if you are using nscd, or whether the logged in user (below) can read the tls_cert and tls_key files.

Since the verification of the server certificate works out fine, I only provided the client-verification specific values. Here are the missing values:

base dc=... uri ldaps://<fqdn of my server>/ ldap_version 3 bind_policy soft pam_password md5

tls_check_peer yes tls_cacertfile /usr/lib/ssl/cacerts/<serverca>.chain.pem tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem tls_key /usr/lib/ssl/private/<client>.ldap.key.pem nss_initgroups_ignoreusers backup,bin,daemon,dhcp,fetchmail,games,gnats,irc,klog,libuuid,list,lp,mail,man, \ messagebus,news,postfix,proxy,root,sshd,statd,sync,sys,syslog,uucp,www-data,zimbra

The nss_initgroups_ignoreusers entry is automatically created when executing /etc/init.d/libnss-ldap restart or when booting the system.

I disabled the nscd caches for passwd and group before starting to deal with TLS just to make sure that the ldap server is always contacted.

==== /etc/nscd.conf ==== ... enable-cache passwd no ... enable-cache group no ... == END /etc/nscd.conf ==

After tideous testing I found out something new:

I wanted to strace the sshd, too and therefore stopped the running instance with /etc/init.d/ssh stop and started a new instance manually

<local user>@<client> sudo -s root@<client># /usr/sbin/sshd -D

Doing so, the login via SSH works sout perfectly. I assumed that this is because sshd would read the .ldaprc of <local user>, which has a valid cert/key entry (see above), so I straced the above command. But:

root@<client>:/etc/init.d# strace -e open /usr/sbin/sshd -D 2>&1 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libwrap.so.0", O_RDONLY) = 3 open("/lib/libpam.so.0", O_RDONLY) = 3 open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libselinux.so.1", O_RDONLY) = 3 open("/usr/lib/libck-connector.so.0", O_RDONLY) = 3 open("/usr/lib/libdbus-1.so.3", O_RDONLY) = 3 open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 open("/lib/libutil.so.1", O_RDONLY) = 3 open("/usr/lib/libz.so.1", O_RDONLY) = 3 open("/lib/libnsl.so.1", O_RDONLY) = 3 open("/lib/libcrypt.so.1", O_RDONLY) = 3 open("/lib/libresolv.so.2", O_RDONLY) = 3 open("/usr/lib/libgssapi_krb5.so.2", O_RDONLY) = 3 open("/usr/lib/libkrb5.so.3", O_RDONLY) = 3 open("/usr/lib/libk5crypto.so.3", O_RDONLY) = 3 open("/lib/libcom_err.so.2", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/lib/libkrb5support.so.0", O_RDONLY) = 3 open("/lib/libkeyutils.so.1", O_RDONLY) = 3 open("/etc/selinux/config", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/mounts", O_RDONLY) = 3 open("/dev/null", O_RDWR) = 3 open("/proc/14556/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3 open("/etc/ssh/sshd_config", O_RDONLY) = 3 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 open("/etc/gai.conf", O_RDONLY) = 3 open("/etc/nsswitch.conf", O_RDONLY) = 3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libnss_files.so.2", O_RDONLY) = 3 open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = 3 open("/etc/ssh/ssh_host_rsa_key", O_RDONLY) = 3 open("/etc/ssh/blacklist.RSA-2048", O_RDONLY) = 3 open("/etc/ssh/ssh_host_dsa_key", O_RDONLY) = 3 open("/etc/ssh/blacklist.DSA-1024", O_RDONLY) = 3 open("/etc/localtime", O_RDONLY) = 4 open("/var/run/sshd.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4

Now if I do ssh <network_user>@<client> from any machine in the net, everything works out perfectly:

<some id>@<some host>:~> ssh <network_user>@<client> <network_user>@<client>'s password: Last login: Fri Aug 29 21:23:06 2008 from <fqdn of some host> <network user>@<client>:~$

But not a single ldap or libnss/libpam config file is stat'ed or read by the above sshd at all. The only thing that can be seen is that after logging out, the above sshd command echos

--- SIGCHLD (Child exited) @ 0 (0) ---

and that's it.

When I kill the above sshd and do /etc/init.d/ssh start again, the login still works out. But after restarting the sytem, the login fails as always.

As far as I can see, /etc/init.d/ssh starts sshd as root, obviously not chrooted or something similar.

Do you have any idea, what this is all about?

Kind regards,

Hauke

--