389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
Hi there,
here's what I would like to do: Run the 389 directory server on CentOS 6.2 (x86_64). As you guys know, TLS is a must in RHEL 6+ and I do not want to turn it off, switching in sysconfig to RHEL 5 "legacy mode". Instead I would like to use the setupssl2.sh script from the 389-site to set up TLS. This fails completely: I start out switching off & deleteing everything: -------------------------------------------------------------------------- root@ldap:~# service dirsrv stop Shutting down dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin stop Shutting down dirsrv-admin: [ OK ] root@ldap:~# yum remove 389-ds* root@ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv /var/lib/dirsrv /root/.389-console -------------------------------------------------------------------------- Now everything 389-related should be wiped from the box. Please correct me if I'm wrong. Next, I switch off iptables and disable selinux: -------------------------------------------------------------------------- root@ldap:~# service iptables stop root@ldap:~# setenforce 0 -------------------------------------------------------------------------- Now I start from scratch: /etc/hosts: -------------------------------------------------------------------------- root@ldap:~# cat /etc/hosts 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.10.37 ldap.baar.intra.bbcomputing.org -------------------------------------------------------------------------- Installation: -------------------------------------------------------------------------- root@ldap:~# yum install 389-ds ... Running Transaction Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9 Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9 Installing : 389-admin-1.1.29-1.el6.x86_64 3/9 Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9 Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9 Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9 Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9 Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9 Installing : 389-ds-1.2.2-1.el6.noarch 9/9 Installed: 389-ds.noarch 0:1.2.2-1.el6 ... -------------------------------------------------------------------------- Looks ok to me. (Again: Please correct m if I'm wrong) Setup: -------------------------------------------------------------------------- root@ldap:~# setup-ds-admin.pl My answers here: Would you like to continue with set up? [yes]: y Would you like to continue? [yes]: y Choose a setup type [2]: 2 Computer name [ldap.baar.intra.bbcomputing.org]: ldap.baar.intra.bbcomputing.org System User [nobody]: nobody System Group [nobody]: nobody Do you want to register this software with an existing configuration directory server? [no]: n administrator ID [admin]: admin Password: <pw1> Password (confirm): <pw1> Administration Domain [baar.intra.bbcomputing.org]: intra.bbcomputing.org Directory server network port [389]: 389 Directory server identifier [ldap]: bb_auth Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]: dc=bbcomputing,dc=org Directory Manager DN [cn=Directory Manager]: cn=Directory Manager Password: <pw2> Password (confirm): <pw2> Administration port [9830]: 9830 Are you ready to set up your servers? [yes]: y -------------------------------------------------------------------------- Here's the following output: -------------------------------------------------------------------------- Creating directory server . . . Your new DS instance 'bb_auth' was successfully created. Creating the configuration directory server . . . Beginning Admin Server creation . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Starting admin server . . . output: Starting dirsrv-admin: output: [ OK ] The admin server was successfully started. Admin server was successfully created, configured, and started. Exiting . . . Log file is '/tmp/setup1dRGLl.log' -------------------------------------------------------------------------- Again, looks all ok to me. Especially the processes looks good: -------------------------------------------------------------------------- root@ldap:~# ps -ef |grep dirsrv nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w /var/run/dirsrv/slapd-bb_auth.startpid root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv -------------------------------------------------------------------------- And netstat also looks just sweet: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker ... tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd ... -------------------------------------------------------------------------- In fact, I can run 389-console at this point and successfully log into the management console: -------------------------------------------------------------------------- root@ldap:~# 389-console Using: User ID: cn=Directory Manager Password: <pw2> Administration URL: http://localhost:9830 -------------------------------------------------------------------------- So far so good without TLS. Now the pain pain starts: To set up TLS I foung this script in the 389 Howto:SSL docs: http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true So I naively ran this thing: -------------------------------------------------------------------------- root@ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/ Using /etc/dirsrv/slapd-bb_auth/ as sec directory No CA certificate found - will create new one No Server Cert found - will create new one No Admin Server Cert found - will create new one Creating password file for security token Creating noise file Creating new key and cert db Creating encryption key for CA Generating key. This may take a few moments... Creating self-signed CA certificate Generating key. This may take a few moments... Is this a CA certificate [y/N]? Enter the path length constraint, enter to skip [<0 for unlimited path]: > Is this a critical extension [y/N]? Exporting the CA certificate to cacert.asc Generating server certificate for 389 Directory Server on host ldap.baar.intra.bbcomputing.org Using fully qualified hostname ldap.baar.intra.bbcomputing.org for the server name in the server cert subject DN Note: If you do not want to use this hostname, edit this script to change myhost to the real hostname you want to use Generating key. This may take a few moments... Creating the admin server certificate Generating key. This may take a few moments... Exporting the admin server certificate pk12 file pk12util: PKCS12 EXPORT SUCCESSFUL Creating pin file for directory server Importing the admin server key and cert (created above) pk12util: PKCS12 IMPORT SUCCESSFUL Importing the CA certificate from cacert.asc Creating the admin server password file Enabling the use of a password file in admin server Turning on NSSEngine Use ldaps for config ds connections Enabling SSL in the directory server when prompted, provide the directory manager password Password:modifying entry "cn=encryption,cn=config" modifying entry "cn=config" adding new entry "cn=RSA,cn=encryption,cn=config" Enabling SSL in the admin server modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389 Administration Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" Done. You must restart the directory server and the admin server for the changes to take effect. -------------------------------------------------------------------------- Again everything appears good to me, I can even restart the services without any hickups: -------------------------------------------------------------------------- root@ldap:~# service dirsrv restart Shutting down dirsrv: bb_auth... [ OK ] Starting dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin restart Shutting down dirsrv-admin: [ OK ] Starting dirsrv-admin: [ OK ] -------------------------------------------------------------------------- Now I try again to run 389-console with the same credentials and everything as above, and it fails: In the login window it simply hangs saying 'Authenticating User ID "cn=Directory Manager"...' and after some seconds an error messages appears that reads: "Cannot login because of an incorrect User ID, incorrect password or Directory problem. java.io.InterruptedIOException: HTTP response timeout.". netstat now looks like this: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker ... tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd ... -------------------------------------------------------------------------- Honestly, I don't even want an SSL listener on port 636, I really only want a listener on port 389 that requires clients to use start_tls. But I don't care for the moment. Here's more pain: -------------------------------------------------------------------------- root@ldap:~# cat /etc/openldap/ldap.conf URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts -------------------------------------------------------------------------- To my understanding, this should tell CentOS to query the LDAP box mentioned in the URI part, using TLS, for users, but: -------------------------------------------------------------------------- root@ldap:~# id raimund -------------------------------------------------------------------------- produces nothing but these entries in /var/log/messages -------------------------------------------------------------------------- Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed: Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/") Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP server ldap://ldap.baar.intra.bbcomputing.org/: Connect error Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found -------------------------------------------------------------------------- This looks bad. Actually the LDAP server sould respond that this user does not exist (empty directory at this moment), but instaead, these lines indicate that the entire communication with the server ist broken. Now, this is pretty useless, isn't it? I now have two running LDAP services (dirsrv and diesrv-admin). The first can't be contacted at all and the door to the admin server is also slammed shut, because 389-console can't talk to it any more. I went on a bit more and switched off SSL/TLS for the admin server again, then 389-console logins worked at least again, but once in the console, it's not possible to open any of the directories. Please help! I already wasted 1.5 days with this, reinstalling about 15 times! Sure there must be a way to get this running with TLS *and* the 389-console? Cheers, Raimund -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
On 07/07/2012 04:15 AM, Ray wrote:
Hi there, here's what I would like to do: Run the 389 directory server on CentOS 6.2 (x86_64). As you guys know, TLS is a must in RHEL 6+ and I do not want to turn it off, switching in sysconfig to RHEL 5 "legacy mode". Instead I would like to use the setupssl2.sh script from the 389-site to set up TLS. This fails completely: I start out switching off & deleteing everything: -------------------------------------------------------------------------- root@ldap:~# service dirsrv stop Shutting down dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin stop Shutting down dirsrv-admin: [ OK ] remove-ds-admin.pl -y root@ldap:~# yum remove 389-ds* yum remove 389* yum remove 389-ds* won't remove 389-console, 389-admin, etc. root@ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv /var/lib/dirsrv /root/.389-console -------------------------------------------------------------------------- Now everything 389-related should be wiped from the box. Please correct me if I'm wrong. Next, I switch off iptables and disable selinux: -------------------------------------------------------------------------- root@ldap:~# service iptables stop root@ldap:~# setenforce 0 -------------------------------------------------------------------------- Now I start from scratch: /etc/hosts: -------------------------------------------------------------------------- root@ldap:~# cat /etc/hosts 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.10.37 ldap.baar.intra.bbcomputing.org -------------------------------------------------------------------------- Installation: -------------------------------------------------------------------------- root@ldap:~# yum install 389-ds ... Running Transaction Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9 Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9 Installing : 389-admin-1.1.29-1.el6.x86_64 3/9 Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9 Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9 Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9 Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9 Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9 Installing : 389-ds-1.2.2-1.el6.noarch 9/9 Installed: 389-ds.noarch 0:1.2.2-1.el6 ... -------------------------------------------------------------------------- Looks ok to me. (Again: Please correct m if I'm wrong) Setup: -------------------------------------------------------------------------- root@ldap:~# setup-ds-admin.pl My answers here: Would you like to continue with set up? [yes]: y Would you like to continue? [yes]: y Choose a setup type [2]: 2 Computer name [ldap.baar.intra.bbcomputing.org]: ldap.baar.intra.bbcomputing.org System User [nobody]: nobody System Group [nobody]: nobody Do you want to register this software with an existing configuration directory server? [no]: n administrator ID [admin]: admin Password: <pw1> Password (confirm): <pw1> Administration Domain [baar.intra.bbcomputing.org]: intra.bbcomputing.org Directory server network port [389]: 389 Directory server identifier [ldap]: bb_auth Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]: dc=bbcomputing,dc=org Directory Manager DN [cn=Directory Manager]: cn=Directory Manager Password: <pw2> Password (confirm): <pw2> Administration port [9830]: 9830 Are you ready to set up your servers? [yes]: y -------------------------------------------------------------------------- Here's the following output: -------------------------------------------------------------------------- Creating directory server . . . Your new DS instance 'bb_auth' was successfully created. Creating the configuration directory server . . . Beginning Admin Server creation . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Starting admin server . . . output: Starting dirsrv-admin: output: [ OK ] The admin server was successfully started. Admin server was successfully created, configured, and started. Exiting . . . Log file is '/tmp/setup1dRGLl.log' -------------------------------------------------------------------------- Again, looks all ok to me. Especially the processes looks good: -------------------------------------------------------------------------- root@ldap:~# ps -ef |grep dirsrv nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w /var/run/dirsrv/slapd-bb_auth.startpid root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv -------------------------------------------------------------------------- And netstat also looks just sweet: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker ... tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd ... -------------------------------------------------------------------------- In fact, I can run 389-console at this point and successfully log into the management console: -------------------------------------------------------------------------- root@ldap:~# 389-console Using: User ID: cn=Directory Manager Password: <pw2> Administration URL: http://localhost:9830 -------------------------------------------------------------------------- So far so good without TLS. Now the pain pain starts: To set up TLS I foung this script in the 389 Howto:SSL docs: http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true So I naively ran this thing: -------------------------------------------------------------------------- root@ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/ Using /etc/dirsrv/slapd-bb_auth/ as sec directory No CA certificate found - will create new one No Server Cert found - will create new one No Admin Server Cert found - will create new one Creating password file for security token Creating noise file Creating new key and cert db Creating encryption key for CA Generating key. This may take a few moments... Creating self-signed CA certificate Generating key. This may take a few moments... Is this a CA certificate [y/N]? Enter the path length constraint, enter to skip [<0 for unlimited path]: > Is this a critical extension [y/N]? Exporting the CA certificate to cacert.asc Generating server certificate for 389 Directory Server on host ldap.baar.intra.bbcomputing.org Using fully qualified hostname ldap.baar.intra.bbcomputing.org for the server name in the server cert subject DN Note: If you do not want to use this hostname, edit this script to change myhost to the real hostname you want to use Generating key. This may take a few moments... Creating the admin server certificate Generating key. This may take a few moments... Exporting the admin server certificate pk12 file pk12util: PKCS12 EXPORT SUCCESSFUL Creating pin file for directory server Importing the admin server key and cert (created above) pk12util: PKCS12 IMPORT SUCCESSFUL Importing the CA certificate from cacert.asc Creating the admin server password file Enabling the use of a password file in admin server Turning on NSSEngine Use ldaps for config ds connections Enabling SSL in the directory server when prompted, provide the directory manager password Password:modifying entry "cn=encryption,cn=config" modifying entry "cn=config" adding new entry "cn=RSA,cn=encryption,cn=config" Enabling SSL in the admin server modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389 Administration Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" Done. You must restart the directory server and the admin server for the changes to take effect. -------------------------------------------------------------------------- Again everything appears good to me, I can even restart the services without any hickups: -------------------------------------------------------------------------- root@ldap:~# service dirsrv restart Shutting down dirsrv: bb_auth... [ OK ] Starting dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin restart Shutting down dirsrv-admin: [ OK ] Starting dirsrv-admin: [ OK ] -------------------------------------------------------------------------- Now I try again to run 389-console with the same credentials and everything as above, and it fails: In the login window it simply hangs saying 'Authenticating User ID "cn=Directory Manager"...' and after some seconds an error messages appears that reads: "Cannot login because of an incorrect User ID, incorrect password or Directory problem. java.io.InterruptedIOException: HTTP response timeout.". netstat now looks like this: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker ... tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd ... -------------------------------------------------------------------------- Honestly, I don't even want an SSL listener on port 636, I really only want a listener on port 389 that requires clients to use start_tls. But I don't care for the moment. Here's more pain: -------------------------------------------------------------------------- root@ldap:~# cat /etc/openldap/ldap.conf URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts -------------------------------------------------------------------------- To my understanding, this should tell CentOS to query the LDAP box mentioned in the URI part, using TLS, for users, but: -------------------------------------------------------------------------- root@ldap:~# id raimund -------------------------------------------------------------------------- produces nothing but these entries in /var/log/messages -------------------------------------------------------------------------- Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed: Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/") Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP server ldap://ldap.baar.intra.bbcomputing.org/: Connect error Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found -------------------------------------------------------------------------- This looks bad. Actually the LDAP server sould respond that this user does not exist (empty directory at this moment), but instaead, these lines indicate that the entire communication with the server ist broken. Now, this is pretty useless, isn't it? I now have two running LDAP services (dirsrv and diesrv-admin). The first can't be contacted at all and the door to the admin server is also slammed shut, because 389-console can't talk to it any more. I went on a bit more and switched off SSL/TLS for the admin server again, then 389-console logins worked at least again, but once in the console, it's not possible to open any of the directories. Please help! I already wasted 1.5 days with this, reinstalling about 15 times! Sure there must be a way to get this running with TLS *and* the 389-console? Cheers, Raimund -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
Hi there,
thanks for the suggestions for a cleaner removal of previous installations. I tried this at once, but unfortunately, it did not help. After running the setupssl2.sh script, the server behaves exactly the same… :( Is there anything else I should try? Cheers, Raimund Am 07.07.2012 17:52, schrieb Rich Megginson: On 07/07/2012 04:15 AM, Ray wrote: Hi there, here's what I would like to do: Run the 389 directory server on CentOS 6.2 (x86_64). As you guys know, TLS is a must in RHEL 6+ and I do not want to turn it off, switching in sysconfig to RHEL 5 "legacy mode". Instead I would like to use the setupssl2.sh script from the 389-site to set up TLS. This fails completely: I start out switching off & deleteing everything: -------------------------------------------------------------------------- root@ldap:~# service dirsrv stop Shutting down dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin stop Shutting down dirsrv-admin: [ OK ] remove-ds-admin.pl -y root@ldap:~# yum remove 389-ds* yum remove 389* yum remove 389-ds* won't remove 389-console, 389-admin, etc. root@ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv /var/lib/dirsrv /root/.389-console -------------------------------------------------------------------------- Now everything 389-related should be wiped from the box. Please correct me if I'm wrong. Next, I switch off iptables and disable selinux: -------------------------------------------------------------------------- root@ldap:~# service iptables stop root@ldap:~# setenforce 0 -------------------------------------------------------------------------- Now I start from scratch: /etc/hosts: -------------------------------------------------------------------------- root@ldap:~# cat /etc/hosts 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.10.37 ldap.baar.intra.bbcomputing.org -------------------------------------------------------------------------- Installation: -------------------------------------------------------------------------- root@ldap:~# yum install 389-ds ... Running Transaction Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9 Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9 Installing : 389-admin-1.1.29-1.el6.x86_64 3/9 Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9 Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9 Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9 Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9 Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9 Installing : 389-ds-1.2.2-1.el6.noarch 9/9 Installed: 389-ds.noarch 0:1.2.2-1.el6 ... -------------------------------------------------------------------------- Looks ok to me. (Again: Please correct m if I'm wrong) Setup: -------------------------------------------------------------------------- root@ldap:~# setup-ds-admin.pl My answers here: Would you like to continue with set up? [yes]: y Would you like to continue? [yes]: y Choose a setup type [2]: 2 Computer name [ldap.baar.intra.bbcomputing.org]: ldap.baar.intra.bbcomputing.org System User [nobody]: nobody System Group [nobody]: nobody Do you want to register this software with an existing configuration directory server? [no]: n administrator ID [admin]: admin Password: <pw1> Password (confirm): <pw1> Administration Domain [baar.intra.bbcomputing.org]: intra.bbcomputing.org Directory server network port [389]: 389 Directory server identifier [ldap]: bb_auth Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]: dc=bbcomputing,dc=org Directory Manager DN [cn=Directory Manager]: cn=Directory Manager Password: <pw2> Password (confirm): <pw2> Administration port [9830]: 9830 Are you ready to set up your servers? [yes]: y -------------------------------------------------------------------------- Here's the following output: -------------------------------------------------------------------------- Creating directory server . . . Your new DS instance 'bb_auth' was successfully created. Creating the configuration directory server . . . Beginning Admin Server creation . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Starting admin server . . . output: Starting dirsrv-admin: output: [ OK ] The admin server was successfully started. Admin server was successfully created, configured, and started. Exiting . . . Log file is '/tmp/setup1dRGLl.log' -------------------------------------------------------------------------- Again, looks all ok to me. Especially the processes looks good: -------------------------------------------------------------------------- root@ldap:~# ps -ef |grep dirsrv nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w /var/run/dirsrv/slapd-bb_auth.startpid root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv -------------------------------------------------------------------------- And netstat also looks just sweet: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker ... tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd ... -------------------------------------------------------------------------- In fact, I can run 389-console at this point and successfully log into the management console: -------------------------------------------------------------------------- root@ldap:~# 389-console Using: User ID: cn=Directory Manager Password: <pw2> Administration URL: http://localhost:9830 -------------------------------------------------------------------------- So far so good without TLS. Now the pain pain starts: To set up TLS I foung this script in the 389 Howto:SSL docs: http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true So I naively ran this thing: -------------------------------------------------------------------------- root@ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/ Using /etc/dirsrv/slapd-bb_auth/ as sec directory No CA certificate found - will create new one No Server Cert found - will create new one No Admin Server Cert found - will create new one Creating password file for security token Creating noise file Creating new key and cert db Creating encryption key for CA Generating key. This may take a few moments... Creating self-signed CA certificate Generating key. This may take a few moments... Is this a CA certificate [y/N]? Enter the path length constraint, enter to skip [<0 for unlimited path]: > Is this a critical extension [y/N]? Exporting the CA certificate to cacert.asc Generating server certificate for 389 Directory Server on host ldap.baar.intra.bbcomputing.org Using fully qualified hostname ldap.baar.intra.bbcomputing.org for the server name in the server cert subject DN Note: If you do not want to use this hostname, edit this script to change myhost to the real hostname you want to use Generating key. This may take a few moments... Creating the admin server certificate Generating key. This may take a few moments... Exporting the admin server certificate pk12 file pk12util: PKCS12 EXPORT SUCCESSFUL Creating pin file for directory server Importing the admin server key and cert (created above) pk12util: PKCS12 IMPORT SUCCESSFUL Importing the CA certificate from cacert.asc Creating the admin server password file Enabling the use of a password file in admin server Turning on NSSEngine Use ldaps for config ds connections Enabling SSL in the directory server when prompted, provide the directory manager password Password:modifying entry "cn=encryption,cn=config" modifying entry "cn=config" adding new entry "cn=RSA,cn=encryption,cn=config" Enabling SSL in the admin server modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389 Administration Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" Done. You must restart the directory server and the admin server for the changes to take effect. -------------------------------------------------------------------------- Again everything appears good to me, I can even restart the services without any hickups: -------------------------------------------------------------------------- root@ldap:~# service dirsrv restart Shutting down dirsrv: bb_auth... [ OK ] Starting dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin restart Shutting down dirsrv-admin: [ OK ] Starting dirsrv-admin: [ OK ] -------------------------------------------------------------------------- Now I try again to run 389-console with the same credentials and everything as above, and it fails: In the login window it simply hangs saying 'Authenticating User ID "cn=Directory Manager"...' and after some seconds an error messages appears that reads: "Cannot login because of an incorrect User ID, incorrect password or Directory problem. java.io.InterruptedIOException: HTTP response timeout.". netstat now looks like this: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker ... tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd ... -------------------------------------------------------------------------- Honestly, I don't even want an SSL listener on port 636, I really only want a listener on port 389 that requires clients to use start_tls. But I don't care for the moment. Here's more pain: -------------------------------------------------------------------------- root@ldap:~# cat /etc/openldap/ldap.conf URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts -------------------------------------------------------------------------- To my understanding, this should tell CentOS to query the LDAP box mentioned in the URI part, using TLS, for users, but: -------------------------------------------------------------------------- root@ldap:~# id raimund -------------------------------------------------------------------------- produces nothing but these entries in /var/log/messages -------------------------------------------------------------------------- Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed: Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/") Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP server ldap://ldap.baar.intra.bbcomputing.org/: Connect error Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found -------------------------------------------------------------------------- This looks bad. Actually the LDAP server sould respond that this user does not exist (empty directory at this moment), but instaead, these lines indicate that the entire communication with the server ist broken. Now, this is pretty useless, isn't it? I now have two running LDAP services (dirsrv and diesrv-admin). The first can't be contacted at all and the door to the admin server is also slammed shut, because 389-console can't talk to it any more. I went on a bit more and switched off SSL/TLS for the admin server again, then 389-console logins worked at least again, but once in the console, it's not possible to open any of the directories. Please help! I already wasted 1.5 days with this, reinstalling about 15 times! Sure there must be a way to get this running with TLS *and* the 389-console? Cheers, Raimund -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
Hello
On Sat, Jul 7, 2012 at 10:55 PM, Ray <ray@renegade.zapto.org> wrote: Hi there, thanks for the suggestions for a cleaner removal of previous installations. I tried this at once, but unfortunately, it did not help. After running the setupssl2.sh script, the server behaves exactly the same… :( Is there anything else I should try? Can you try steps given here. http://lists.fedoraproject.org/pipermail/389-users/2012-March/014200.html These commands works nicely in my test environments & please start using bottom posting. Regards Arpit Tolani Â* -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
I Alberto,
I got it working, logical, actually: When you start out the way I did, i.e. fresh installation, then running setup-ds-admin.pl, then setupssl2.sh both services (dirsrv and dirsrv-admin) will be restarable cleanly, i.e. they do actually run (see details below in my initial posting). When you then run 389-console, all you need to make sure is 1) use the fqdn you configured in /etc/hosts and setup-ds-admin.pl in the URI. 2) change from http to https in the URI string. Please try that out. It works now for me. You should be able to log into 389-console and populate you directory at this point. The next confusing thing (for the client side) that noone tells you (because it's sooo obvious?! - I don't think so…) is that there are two ldap.conf files to take care of: 1) /etc/openldap/ldap.conf (this one is for the openldap-clients [ldapsearch et al.] 2) /etc/pam_ldap.conf (this one takes care of the actual OS user/group resolution Here are mine: /etc/openldap/ldap.conf: URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=busy-byte,dc=org TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow /etc/pam_ldap.conf: base dc=bbcomputing,dc=org uri ldaps://ldap.baar.intra.bbcomputing.org/ ssl start_tls tls_cacertdir /etc/openldap/cacerts pam_password md5 Now, in both configs you see the tls_cacertdir parameter. 1) Make sure you have that directory. 2) After you ran setupssl.sh, you should find a certificate in /etc/dirsrv/slapd-<server identifier you chose in setup-ds-admin.pl>/cacert.asc. Copy this certificate: cp /etc/dirsrv/slapd-<server identifier you chose in setup-ds-admin.pl>/cacert.asc /etc/openldap/cacerts/cacert_389_ldap.pem This is not enough. The clients will only pick up certs with hashed filenames, so (not very prominent information in the docs also): 3) cd /etc/openldap/cacerts/ 4) ln -s cacert_389_ldap.pem `openssl x509 -in cacert_389_ldap.pem -noout -hash`.0 You'll need to repeat that on each and every client you plan to use. After all this things should work. You can try id <username from your directory> And see whta comes back. Alternatively you can try "getent passwd" to see all users you configures in your directory, or "getent group" for the groups ldapsearch -x -ZZ -h <fqdn of your ldap machine> should also work and return all entries as ldifs. Let me know how the things are going -- Cheers, Raimund Eimann Am 09.07.2012 11:15, schrieb Alberto Suárez: Hi Ray, I am trying to achieve exactly then same as you and I ended in a dead street too. For some reason the configuration of ssl with the script does not work as expected on Centos 6.2. I am trying again, this time avoiding that script. Unfortunately, there is no much documentation on setting up 389 on Centos 6.2. (or at least I have not found it!) and it is the small details that mess everything up. If you want, get in touch with me so we could exchange experiences and suggestions. Cheers, Alberto Ray wrote: Hi there, thanks for the suggestions for a cleaner removal of previous installations. I tried this at once, but unfortunately, it did not help. After running the setupssl2.sh script, the server behaves exactly the same… :( Is there anything else I should try? Cheers, Raimund Am 07.07.2012 17:52, schrieb Rich Megginson: On 07/07/2012 04:15 AM, Ray wrote: Hi there, here's what I would like to do: Run the 389 directory server on CentOS 6.2 (x86_64). As you guys know, TLS is a must in RHEL 6+ and I do not want to turn it off, switching in sysconfig to RHEL 5 "legacy mode". Instead I would like to use the setupssl2.sh script from the 389-site to set up TLS. This fails completely: I start out switching off & deleteing everything: -------------------------------------------------------------------------- root@ldap:~# service dirsrv stop Shutting down dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin stop Shutting down dirsrv-admin: [ OK ] remove-ds-admin.pl -y root@ldap:~# yum remove 389-ds* yum remove 389* yum remove 389-ds* won't remove 389-console, 389-admin, etc. root@ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv /var/lib/dirsrv /root/.389-console -------------------------------------------------------------------------- Now everything 389-related should be wiped from the box. Please correct me if I'm wrong. Next, I switch off iptables and disable selinux: -------------------------------------------------------------------------- root@ldap:~# service iptables stop root@ldap:~# setenforce 0 -------------------------------------------------------------------------- Now I start from scratch: /etc/hosts: -------------------------------------------------------------------------- root@ldap:~# cat /etc/hosts 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.10.37 ldap.baar.intra.bbcomputing.org -------------------------------------------------------------------------- Installation: -------------------------------------------------------------------------- root@ldap:~# yum install 389-ds ... Running Transaction Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9 Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9 Installing : 389-admin-1.1.29-1.el6.x86_64 3/9 Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9 Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9 Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9 Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9 Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9 Installing : 389-ds-1.2.2-1.el6.noarch 9/9 Installed: 389-ds.noarch 0:1.2.2-1.el6 ... -------------------------------------------------------------------------- Looks ok to me. (Again: Please correct m if I'm wrong) Setup: -------------------------------------------------------------------------- root@ldap:~# setup-ds-admin.pl My answers here: Would you like to continue with set up? [yes]: y Would you like to continue? [yes]: y Choose a setup type [2]: 2 Computer name [ldap.baar.intra.bbcomputing.org]: ldap.baar.intra.bbcomputing.org System User [nobody]: nobody System Group [nobody]: nobody Do you want to register this software with an existing configuration directory server? [no]: n administrator ID [admin]: admin Password: <pw1> Password (confirm): <pw1> Administration Domain [baar.intra.bbcomputing.org]: intra.bbcomputing.org Directory server network port [389]: 389 Directory server identifier [ldap]: bb_auth Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]: dc=bbcomputing,dc=org Directory Manager DN [cn=Directory Manager]: cn=Directory Manager Password: <pw2> Password (confirm): <pw2> Administration port [9830]: 9830 Are you ready to set up your servers? [yes]: y -------------------------------------------------------------------------- Here's the following output: -------------------------------------------------------------------------- Creating directory server . . . Your new DS instance 'bb_auth' was successfully created. Creating the configuration directory server . . . Beginning Admin Server creation . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Starting admin server . . . output: Starting dirsrv-admin: output: [ OK ] The admin server was successfully started. Admin server was successfully created, configured, and started. Exiting . . . Log file is '/tmp/setup1dRGLl.log' -------------------------------------------------------------------------- Again, looks all ok to me. Especially the processes looks good: -------------------------------------------------------------------------- root@ldap:~# ps -ef |grep dirsrv nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w /var/run/dirsrv/slapd-bb_auth.startpid root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv -------------------------------------------------------------------------- And netstat also looks just sweet: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker ... tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd ... -------------------------------------------------------------------------- In fact, I can run 389-console at this point and successfully log into the management console: -------------------------------------------------------------------------- root@ldap:~# 389-console Using: User ID: cn=Directory Manager Password: <pw2> Administration URL: http://localhost:9830 -------------------------------------------------------------------------- So far so good without TLS. Now the pain pain starts: To set up TLS I foung this script in the 389 Howto:SSL docs: http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true So I naively ran this thing: -------------------------------------------------------------------------- root@ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/ Using /etc/dirsrv/slapd-bb_auth/ as sec directory No CA certificate found - will create new one No Server Cert found - will create new one No Admin Server Cert found - will create new one Creating password file for security token Creating noise file Creating new key and cert db Creating encryption key for CA Generating key. This may take a few moments... Creating self-signed CA certificate Generating key. This may take a few moments... Is this a CA certificate [y/N]? Enter the path length constraint, enter to skip [<0 for unlimited path]: > Is this a critical extension [y/N]? Exporting the CA certificate to cacert.asc Generating server certificate for 389 Directory Server on host ldap.baar.intra.bbcomputing.org Using fully qualified hostname ldap.baar.intra.bbcomputing.org for the server name in the server cert subject DN Note: If you do not want to use this hostname, edit this script to change myhost to the real hostname you want to use Generating key. This may take a few moments... Creating the admin server certificate Generating key. This may take a few moments... Exporting the admin server certificate pk12 file pk12util: PKCS12 EXPORT SUCCESSFUL Creating pin file for directory server Importing the admin server key and cert (created above) pk12util: PKCS12 IMPORT SUCCESSFUL Importing the CA certificate from cacert.asc Creating the admin server password file Enabling the use of a password file in admin server Turning on NSSEngine Use ldaps for config ds connections Enabling SSL in the directory server when prompted, provide the directory manager password Password:modifying entry "cn=encryption,cn=config" modifying entry "cn=config" adding new entry "cn=RSA,cn=encryption,cn=config" Enabling SSL in the admin server modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389 Administration Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" Done. You must restart the directory server and the admin server for the changes to take effect. -------------------------------------------------------------------------- Again everything appears good to me, I can even restart the services without any hickups: -------------------------------------------------------------------------- root@ldap:~# service dirsrv restart Shutting down dirsrv: bb_auth... [ OK ] Starting dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin restart Shutting down dirsrv-admin: [ OK ] Starting dirsrv-admin: [ OK ] -------------------------------------------------------------------------- Now I try again to run 389-console with the same credentials and everything as above, and it fails: In the login window it simply hangs saying 'Authenticating User ID "cn=Directory Manager"...' and after some seconds an error messages appears that reads: "Cannot login because of an incorrect User ID, incorrect password or Directory problem. java.io.InterruptedIOException: HTTP response timeout.". netstat now looks like this: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker ... tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd ... -------------------------------------------------------------------------- Honestly, I don't even want an SSL listener on port 636, I really only want a listener on port 389 that requires clients to use start_tls. But I don't care for the moment. Here's more pain: -------------------------------------------------------------------------- root@ldap:~# cat /etc/openldap/ldap.conf URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts -------------------------------------------------------------------------- To my understanding, this should tell CentOS to query the LDAP box mentioned in the URI part, using TLS, for users, but: -------------------------------------------------------------------------- root@ldap:~# id raimund -------------------------------------------------------------------------- produces nothing but these entries in /var/log/messages -------------------------------------------------------------------------- Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed: Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/") Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP server ldap://ldap.baar.intra.bbcomputing.org/: Connect error Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found -------------------------------------------------------------------------- This looks bad. Actually the LDAP server sould respond that this user does not exist (empty directory at this moment), but instaead, these lines indicate that the entire communication with the server ist broken. Now, this is pretty useless, isn't it? I now have two running LDAP services (dirsrv and diesrv-admin). The first can't be contacted at all and the door to the admin server is also slammed shut, because 389-console can't talk to it any more. I went on a bit more and switched off SSL/TLS for the admin server again, then 389-console logins worked at least again, but once in the console, it's not possible to open any of the directories. Please help! I already wasted 1.5 days with this, reinstalling about 15 times! Sure there must be a way to get this running with TLS *and* the 389-console? Cheers, Raimund -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
Hi Alberto,
there is a little mistake in my previous posting: /etc/openldap/ldap.conf: URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow The BASE parameter was wrong. Cheers, Raimund Eimann Am 09.07.2012 13:27, schrieb Ray: Hi Alberto, I got it working, logical, actually: When you start out the way I did, i.e. fresh installation, then running setup-ds-admin.pl, then setupssl2.sh both services (dirsrv and dirsrv-admin) will be restarable cleanly, i.e. they do actually run (see details below in my initial posting). When you then run 389-console, all you need to make sure is 1) use the fqdn you configured in /etc/hosts and setup-ds-admin.pl in the URI. 2) change from http to https in the URI string. Please try that out. It works now for me. You should be able to log into 389-console and populate you directory at this point. The next confusing thing (for the client side) that noone tells you (because it's sooo obvious?! - I don't think so…) is that there are two ldap.conf files to take care of: 1) /etc/openldap/ldap.conf (this one is for the openldap-clients [ldapsearch et al.] 2) /etc/pam_ldap.conf (this one takes care of the actual OS user/group resolution Here are mine: /etc/openldap/ldap.conf: URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow /etc/pam_ldap.conf: base dc=bbcomputing,dc=org uri ldaps://ldap.baar.intra.bbcomputing.org/ ssl start_tls tls_cacertdir /etc/openldap/cacerts pam_password md5 Now, in both configs you see the tls_cacertdir parameter. 1) Make sure you have that directory. 2) After you ran setupssl.sh, you should find a certificate in /etc/dirsrv/slapd-<server identifier you chose in setup-ds-admin.pl>/cacert.asc. Copy this certificate: cp /etc/dirsrv/slapd-<server identifier you chose in setup-ds-admin.pl>/cacert.asc /etc/openldap/cacerts/cacert_389_ldap.pem This is not enough. The clients will only pick up certs with hashed filenames, so (not very prominent information in the docs also): 3) cd /etc/openldap/cacerts/ 4) ln -s cacert_389_ldap.pem `openssl x509 -in cacert_389_ldap.pem -noout -hash`.0 You'll need to repeat that on each and every client you plan to use. After all this things should work. You can try id <username from your directory> And see whta comes back. Alternatively you can try "getent passwd" to see all users you configures in your directory, or "getent group" for the groups ldapsearch -x -ZZ -h <fqdn of your ldap machine> should also work and return all entries as ldifs. Let me know how the things are going -- Cheers, Raimund Eimann Am 09.07.2012 11:15, schrieb Alberto Suárez: Hi Ray, I am trying to achieve exactly then same as you and I ended in a dead street too. For some reason the configuration of ssl with the script does not work as expected on Centos 6.2. I am trying again, this time avoiding that script. Unfortunately, there is no much documentation on setting up 389 on Centos 6.2. (or at least I have not found it!) and it is the small details that mess everything up. If you want, get in touch with me so we could exchange experiences and suggestions. Cheers, Alberto Ray wrote: Hi there, thanks for the suggestions for a cleaner removal of previous installations. I tried this at once, but unfortunately, it did not help. After running the setupssl2.sh script, the server behaves exactly the same… :( Is there anything else I should try? Cheers, Raimund Am 07.07.2012 17:52, schrieb Rich Megginson: On 07/07/2012 04:15 AM, Ray wrote: Hi there, here's what I would like to do: Run the 389 directory server on CentOS 6.2 (x86_64). As you guys know, TLS is a must in RHEL 6+ and I do not want to turn it off, switching in sysconfig to RHEL 5 "legacy mode". Instead I would like to use the setupssl2.sh script from the 389-site to set up TLS. This fails completely: I start out switching off & deleteing everything: -------------------------------------------------------------------------- root@ldap:~# service dirsrv stop Shutting down dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin stop Shutting down dirsrv-admin: [ OK ] remove-ds-admin.pl -y root@ldap:~# yum remove 389-ds* yum remove 389* yum remove 389-ds* won't remove 389-console, 389-admin, etc. root@ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv /var/lib/dirsrv /root/.389-console -------------------------------------------------------------------------- Now everything 389-related should be wiped from the box. Please correct me if I'm wrong. Next, I switch off iptables and disable selinux: -------------------------------------------------------------------------- root@ldap:~# service iptables stop root@ldap:~# setenforce 0 -------------------------------------------------------------------------- Now I start from scratch: /etc/hosts: -------------------------------------------------------------------------- root@ldap:~# cat /etc/hosts 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.10.37 ldap.baar.intra.bbcomputing.org -------------------------------------------------------------------------- Installation: -------------------------------------------------------------------------- root@ldap:~# yum install 389-ds ... Running Transaction Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9 Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9 Installing : 389-admin-1.1.29-1.el6.x86_64 3/9 Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9 Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9 Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9 Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9 Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9 Installing : 389-ds-1.2.2-1.el6.noarch 9/9 Installed: 389-ds.noarch 0:1.2.2-1.el6 ... -------------------------------------------------------------------------- Looks ok to me. (Again: Please correct m if I'm wrong) Setup: -------------------------------------------------------------------------- root@ldap:~# setup-ds-admin.pl My answers here: Would you like to continue with set up? [yes]: y Would you like to continue? [yes]: y Choose a setup type [2]: 2 Computer name [ldap.baar.intra.bbcomputing.org]: ldap.baar.intra.bbcomputing.org System User [nobody]: nobody System Group [nobody]: nobody Do you want to register this software with an existing configuration directory server? [no]: n administrator ID [admin]: admin Password: <pw1> Password (confirm): <pw1> Administration Domain [baar.intra.bbcomputing.org]: intra.bbcomputing.org Directory server network port [389]: 389 Directory server identifier [ldap]: bb_auth Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]: dc=bbcomputing,dc=org Directory Manager DN [cn=Directory Manager]: cn=Directory Manager Password: <pw2> Password (confirm): <pw2> Administration port [9830]: 9830 Are you ready to set up your servers? [yes]: y -------------------------------------------------------------------------- Here's the following output: -------------------------------------------------------------------------- Creating directory server . . . Your new DS instance 'bb_auth' was successfully created. Creating the configuration directory server . . . Beginning Admin Server creation . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Starting admin server . . . output: Starting dirsrv-admin: output: [ OK ] The admin server was successfully started. Admin server was successfully created, configured, and started. Exiting . . . Log file is '/tmp/setup1dRGLl.log' -------------------------------------------------------------------------- Again, looks all ok to me. Especially the processes looks good: -------------------------------------------------------------------------- root@ldap:~# ps -ef |grep dirsrv nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w /var/run/dirsrv/slapd-bb_auth.startpid root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv -------------------------------------------------------------------------- And netstat also looks just sweet: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker ... tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd ... -------------------------------------------------------------------------- In fact, I can run 389-console at this point and successfully log into the management console: -------------------------------------------------------------------------- root@ldap:~# 389-console Using: User ID: cn=Directory Manager Password: <pw2> Administration URL: http://localhost:9830 -------------------------------------------------------------------------- So far so good without TLS. Now the pain pain starts: To set up TLS I foung this script in the 389 Howto:SSL docs: http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true So I naively ran this thing: -------------------------------------------------------------------------- root@ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/ Using /etc/dirsrv/slapd-bb_auth/ as sec directory No CA certificate found - will create new one No Server Cert found - will create new one No Admin Server Cert found - will create new one Creating password file for security token Creating noise file Creating new key and cert db Creating encryption key for CA Generating key. This may take a few moments... Creating self-signed CA certificate Generating key. This may take a few moments... Is this a CA certificate [y/N]? Enter the path length constraint, enter to skip [<0 for unlimited path]: > Is this a critical extension [y/N]? Exporting the CA certificate to cacert.asc Generating server certificate for 389 Directory Server on host ldap.baar.intra.bbcomputing.org Using fully qualified hostname ldap.baar.intra.bbcomputing.org for the server name in the server cert subject DN Note: If you do not want to use this hostname, edit this script to change myhost to the real hostname you want to use Generating key. This may take a few moments... Creating the admin server certificate Generating key. This may take a few moments... Exporting the admin server certificate pk12 file pk12util: PKCS12 EXPORT SUCCESSFUL Creating pin file for directory server Importing the admin server key and cert (created above) pk12util: PKCS12 IMPORT SUCCESSFUL Importing the CA certificate from cacert.asc Creating the admin server password file Enabling the use of a password file in admin server Turning on NSSEngine Use ldaps for config ds connections Enabling SSL in the directory server when prompted, provide the directory manager password Password:modifying entry "cn=encryption,cn=config" modifying entry "cn=config" adding new entry "cn=RSA,cn=encryption,cn=config" Enabling SSL in the admin server modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389 Administration Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra. bbcomputing.org,o=NetscapeRoot" Done. You must restart the directory server and the admin server for the changes to take effect. -------------------------------------------------------------------------- Again everything appears good to me, I can even restart the services without any hickups: -------------------------------------------------------------------------- root@ldap:~# service dirsrv restart Shutting down dirsrv: bb_auth... [ OK ] Starting dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin restart Shutting down dirsrv-admin: [ OK ] Starting dirsrv-admin: [ OK ] -------------------------------------------------------------------------- Now I try again to run 389-console with the same credentials and everything as above, and it fails: In the login window it simply hangs saying 'Authenticating User ID "cn=Directory Manager"...' and after some seconds an error messages appears that reads: "Cannot login because of an incorrect User ID, incorrect password or Directory problem. java.io.InterruptedIOException: HTTP response timeout.". netstat now looks like this: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker ... tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd ... -------------------------------------------------------------------------- Honestly, I don't even want an SSL listener on port 636, I really only want a listener on port 389 that requires clients to use start_tls. But I don't care for the moment. Here's more pain: -------------------------------------------------------------------------- root@ldap:~# cat /etc/openldap/ldap.conf URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts -------------------------------------------------------------------------- To my understanding, this should tell CentOS to query the LDAP box mentioned in the URI part, using TLS, for users, but: -------------------------------------------------------------------------- root@ldap:~# id raimund -------------------------------------------------------------------------- produces nothing but these entries in /var/log/messages -------------------------------------------------------------------------- Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed: Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/") Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP server ldap://ldap.baar.intra.bbcomputing.org/: Connect error Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found -------------------------------------------------------------------------- This looks bad. Actually the LDAP server sould respond that this user does not exist (empty directory at this moment), but instaead, these lines indicate that the entire communication with the server ist broken. Now, this is pretty useless, isn't it? I now have two running LDAP services (dirsrv and diesrv-admin). The first can't be contacted at all and the door to the admin server is also slammed shut, because 389-console can't talk to it any more. I went on a bit more and switched off SSL/TLS for the admin server again, then 389-console logins worked at least again, but once in the console, it's not possible to open any of the directories. Please help! I already wasted 1.5 days with this, reinstalling about 15 times! Sure there must be a way to get this running with TLS *and* the 389-console? Cheers, Raimund -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
Hi Raimund Eimann,
Am 09.07.2012 13:27, schrieb Ray: > Hi Alberto, > > I got it working, logical, actually: > > When you start out the way I did, i.e. fresh installation, then > running setup-ds-admin.pl, then setupssl2.sh both services (dirsrv > and > dirsrv-admin) will be restarable cleanly, i.e. they do actually run > (see details below in my initial posting). > > When you then run 389-console, all you need to make sure is > > 1) use the fqdn you configured in /etc/hosts and setup-ds-admin.pl > in the URI. > 2) change from http to https in the URI string. > > Please try that out. It works now for me. You should be able to log > into 389-console and populate you directory at this point. > > The next confusing thing (for the client side) that noone tells you > (because it's sooo obvious?! - I don't think so…) is that there are > two ldap.conf files to take care of: > > 1) /etc/openldap/ldap.conf (this one is for the openldap-clients > [ldapsearch et al.] > 2) /etc/pam_ldap.conf (this one takes care of the actual OS > user/group resolution > > Here are mine: > > /etc/openldap/ldap.conf: > > URI ldap://ldap.baar.intra.bbcomputing.org/ > BASE dc=bbcomputing,dc=org > TLS_CACERTDIR /etc/openldap/cacerts > TLS_REQCERT allow > > > > > /etc/pam_ldap.conf: > > base dc=bbcomputing,dc=org > uri ldaps://ldap.baar.intra.bbcomputing.org/ > ssl start_tls > tls_cacertdir /etc/openldap/cacerts > pam_password md5 > > > Now, in both configs you see the tls_cacertdir parameter. > > 1) Make sure you have that directory. > 2) After you ran setupssl.sh, you should find a certificate in > /etc/dirsrv/slapd-<server identifier you chose in > setup-ds-admin.pl>/cacert.asc. Copy this certificate: cp > /etc/dirsrv/slapd-<server identifier you chose in > setup-ds-admin.pl>/cacert.asc > /etc/openldap/cacerts/cacert_389_ldap.pem > > This is not enough. The clients will only pick up certs with > hashed filenames, so (not very prominent information in the docs > also): > > 3) cd /etc/openldap/cacerts/ > 4) ln -s cacert_389_ldap.pem `openssl x509 -in > cacert_389_ldap.pem -noout -hash`.0 > > You'll need to repeat that on each and every client you plan to use. > > After all this things should work. You can try > > id <username from your directory> > > And see whta comes back. Alternatively you can try > > "getent passwd" to see all users you configures in your directory, or > "getent group" for the groups > > ldapsearch -x -ZZ -h <fqdn of your ldap machine> should also work and > return all entries as ldifs. > > Let me know how the things are going I recently had same trouble with setupssl2.sh on RHEL 5.8 box with 389-console. Your post has been really useful to me. Everything you have mentioned in the last two posts in this topic have worked successfully for me. Thanks so much! 389-ds rocks as well as 389-console too :) Aero -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
| All times are GMT. The time now is 12:13 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.