Hello,
I have a central repository of users/groups based on OpenLDAP which is working on a remote LAN (servers share users credentials and mount their home directories via NFS). They use non-encrypted ldap restricted to the local network.
Now, I have a few servers in our local office and I would like them to authenticate from the remote LDAP server using encryption via ldaps://. (at this stage, without using client-side certificate)
I have run a similar command as I did on the remote servers, replacing ldap://localldapserver by ldaps://ldap.mycompany.com: authconfig --enableldap --enableldapauth --enablecache --enablemkhomedir --ldapserver=ldaps://ldap.mycompany.com --enableldaptls --ldapbasedn=dc=mycompany,dc=com --passalgo=sha256 --updateall
and I put the CA certificate at the right place. (either explicitly pointing to it TLS_CACERT or downloading it to /etc/openldap/cacerts vi system-configuration-authentication)
In all my various tests, ldapsearch -x returns the content of the remote LDAP, so I guess that at least openldap clients are properly configured.
But when I try: getent passwd the command hangs.
Same when I try to: su - myuser
(I also tried configuring with the system-configuration-authentication UI from a box with GNOME, and also tried authconfig without --enableldaptls)
So is there anything specific to authentication ldaps: that I should have done? (as I said, this approach systematically works with plain ldap on this same LDAP server)
Thanks in advance for your help!
Mathieu
Note: all systems involved are running up to date CentOS 5.5
On Wed, Oct 06, 2010 at 10:24:44AM +0200, Mathieu Baudier wrote:
Hello,
Now, I have a few servers in our local office and I would like them to authenticate from the remote LDAP server using encryption via ldaps://. (at this stage, without using client-side certificate)
I have run a similar command as I did on the remote servers, replacing ldap://localldapserver by ldaps://ldap.mycompany.com: authconfig --enableldap --enableldapauth --enablecache --enablemkhomedir --ldapserver=ldaps://ldap.mycompany.com --enableldaptls --ldapbasedn=dc=mycompany,dc=com --passalgo=sha256 --updateall
Did you, on the server, change the new, undocumented, /etc/sysconfig/ldap file's entry for SLAPD_LDAPS and restart the ldap service on the server?
(It's documented in the CentOS wiki's FAQ, however, apparently no one at RH figured it merited mention.)
Did you, on the server, change the new, undocumented, /etc/sysconfig/ldap file's entry for SLAPD_LDAPS and restart the ldap service on the server?
This settings was indeed set to no.
What is funny though is that I actually can connect to the ldaps port without it (since ldapsearch -x is working and I can also connect via ldaps using a graphical client, and the plain ldap port is closed by the firewall)
I changed the settings to yes and restarted the service, but it did not change anything.
On Wed, Oct 06, 2010 at 03:32:03PM +0200, Mathieu Baudier wrote:
Did you, on the server, change the new, undocumented, /etc/sysconfig/ldap file's entry for SLAPD_LDAPS and restart the ldap service on the server?
This settings was indeed set to no.
I changed the settings to yes and restarted the service, but it did not change anything.
About the only other thing I can think of is an issue I ran into on later versions of Fedora. Now, /etc/openldap/ldap.conf needs TLS_REQCERT allow, but I think that's a Fedora thing. (On the other hand, we're only using CentOS as a server, not a client.)
On Wed, 2010-10-06 at 09:49 -0400, Scott Robbins wrote:
On Wed, Oct 06, 2010 at 03:32:03PM +0200, Mathieu Baudier wrote:
Did you, on the server, change the new, undocumented, /etc/sysconfig/ldap file's entry for SLAPD_LDAPS and restart the ldap service on the server?
This settings was indeed set to no.
I changed the settings to yes and restarted the service, but it did not change anything.
About the only other thing I can think of is an issue I ran into on later versions of Fedora. Now, /etc/openldap/ldap.conf needs TLS_REQCERT allow, but I think that's a Fedora thing. (On the other hand, we're only using CentOS as a server, not a client.)
---- TLS_REQCERT allow is not a Fedora thing but rather typically necessary when you use a self-signed cert because there is no chain to a recognized CA. Thus any client whether Fedora, Ubuntu or CentOS might very well need that configuration.
Craig
On Wed, 6 Oct 2010, Mathieu Baudier wrote:
Now, I have a few servers in our local office and I would like them to authenticate from the remote LDAP server using encryption via ldaps://. (at this stage, without using client-side certificate)
I have run a similar command as I did on the remote servers, replacing ldap://localldapserver by ldaps://ldap.mycompany.com: authconfig --enableldap --enableldapauth --enablecache --enablemkhomedir --ldapserver=ldaps://ldap.mycompany.com --enableldaptls --ldapbasedn=dc=mycompany,dc=com --passalgo=sha256 --updateall
and I put the CA certificate at the right place. (either explicitly pointing to it TLS_CACERT or downloading it to /etc/openldap/cacerts vi system-configuration-authentication)
In all my various tests, ldapsearch -x returns the content of the remote LDAP, so I guess that at least openldap clients are properly configured.
But when I try: getent passwd the command hangs.
I've never done ldaps to port 636, only TLS to port 389, so some of my comments may be slightly off-base in your situtation.
Here are the changes I'd review:
1. After installing the CA cert, did you create a hash link? E.g.,
/usr/sbin/cacertdir_rehash /etc/openldap/cacerts
2. Make sure you know the difference between /etc/ldap.conf and /etc/openldap/ldap.conf. The former is used by nss_ldap, the latter by openldap clients.
3. Does /etc/ldap.conf have all the correct TLS entries, e.g.,
ssl start_tls tls_checkpeer yes tls_cacertdir /etc/openldap/cacerts
Additionally, I've had trouble using the "uri" directive in /etc/ldap.conf, esp. with encrypted connections. The "host" and "port" directives have worked better for me.
4. Does /etc/pam.d/system-auth have pam_ldap.so entries for auth, account, password, and session?
5. Are you running nscd? (I've found it indispensable when working with network auth.)
6. Review the changes to /etc/nsswitch.conf to make sure that the passwd, shadow, and group entries all query ldap.
On Wed, 2010-10-06 at 08:32 -0700, Paul Heinlein wrote:
On Wed, 6 Oct 2010, Mathieu Baudier wrote:
Now, I have a few servers in our local office and I would like them to authenticate from the remote LDAP server using encryption via ldaps://. (at this stage, without using client-side certificate)
I have run a similar command as I did on the remote servers, replacing ldap://localldapserver by ldaps://ldap.mycompany.com: authconfig --enableldap --enableldapauth --enablecache --enablemkhomedir --ldapserver=ldaps://ldap.mycompany.com --enableldaptls --ldapbasedn=dc=mycompany,dc=com --passalgo=sha256 --updateall
and I put the CA certificate at the right place. (either explicitly pointing to it TLS_CACERT or downloading it to /etc/openldap/cacerts vi system-configuration-authentication)
In all my various tests, ldapsearch -x returns the content of the remote LDAP, so I guess that at least openldap clients are properly configured.
But when I try: getent passwd the command hangs.
I've never done ldaps to port 636, only TLS to port 389, so some of my comments may be slightly off-base in your situtation.
Here are the changes I'd review:
After installing the CA cert, did you create a hash link? E.g.,
/usr/sbin/cacertdir_rehash /etc/openldap/cacerts
Make sure you know the difference between /etc/ldap.conf and /etc/openldap/ldap.conf. The former is used by nss_ldap, the latter by openldap clients.
Does /etc/ldap.conf have all the correct TLS entries, e.g.,
ssl start_tls tls_checkpeer yes tls_cacertdir /etc/openldap/cacerts
Additionally, I've had trouble using the "uri" directive in /etc/ldap.conf, esp. with encrypted connections. The "host" and "port" directives have worked better for me.
Does /etc/pam.d/system-auth have pam_ldap.so entries for auth, account, password, and session?
Are you running nscd? (I've found it indispensable when working with network auth.)
Review the changes to /etc/nsswitch.conf to make sure that the passwd, shadow, and group entries all query ldap.
---- tls_checkpeer yes could cause problems - always depends
nscd makes things harder to troubleshoot
uri ldap://some_fqdn/ or uri ldaps://some_fqdn/
Craig
-
Craig White -
Mathieu Baudier -
Paul Heinlein -
Scott Robbins