I've tried to search for these answers, so I apologize if I've missed
them in previous posts in various lists:
I'm setting up FreeBSD 6.1/i386 (soon amd64, I hope) for LDAP login
and I've had some minor issues with it:
1) I can get it to work as a server and client but with the default
startup timeout and bind hard, the slapd startup hangs for quite awhile
on service startup. I've seen the suggestion to set the bind to soft
and lower the timeout value and this helps, but then sshd has problems
querying the ldap service and so one can't login via ssh.
2) My FreeBSD client system can authenticate to it OK, but I'd like
to restrict the unencrypted connect (port 389) to be only for
localhost connection and clients must connect with ssl (port 636).
I've started slapd on the server with flags "-h ldap://127.0.0.1/
ldaps:///" and local server logins work great but the client
hangs on login and whenever commands like "id" or
"whoami" are
issued but the logins and command results ultimately work. I
monitored the net connections with netstat and I see syn connections
to the server's ldap (389) port as well as ldaps (636). I
suspect that even though I set the client's /usr/local/etc/ldap.conf
(and symlinked /etc/ldap.conf and nss_ldap.conf to it) file
with ssl on and port 636, it still is trying 389 first. If I
start the server with "-h ldap:/// ldaps:///" then the 389
connections succeed and everything is fast. A linux client did
not try the 389 port and was fast login in and returning results
with id or whoami. On the FreeBSD client, if I do:
ldapsearch -H ldaps://hostname -b"dc=...." -LL -x
"(uid=testuser)"
this immediately gives me the result. It is something with the
pam or nss that is insisting on doing the port 389 first.
3) My freebsd client sshd when configured for ldap does signal 11
crashes. My freebsd server has no problem with sshd and ldap.
If I turn off ldap and use NIS on the client, it works great.
Any help with these ? I can deal with the slow startup, that's
relatively minor, but 2 and 3 are more problematic for me.
Thanks,
Dirk