[389-users] 389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
Ray
ray at renegade.zapto.org
Sat Jul 7 17:25:32 UTC 2012
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 at ldap:~# service dirsrv stop
>> Shutting down dirsrv:
>> bb_auth... [ OK ]
>> root at ldap:~# service dirsrv-admin stop
>> Shutting down dirsrv-admin:
>> [ OK ]
> remove-ds-admin.pl -y
>
>> root at ldap:~# yum remove 389-ds*
>
> yum remove 389*
>
> yum remove 389-ds* won't remove 389-console, 389-admin, etc.
>
>>
>> root at 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 at ldap:~# service iptables stop
>> root at ldap:~# setenforce 0
>>
>> --------------------------------------------------------------------------
>>
>>
>>
>>
>> Now I start from scratch:
>>
>> /etc/hosts:
>>
>> --------------------------------------------------------------------------
>>
>> root at 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 at 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 at 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 at 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 at 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 at 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 at 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 at ldap:~# service dirsrv restart
>> Shutting down dirsrv:
>> bb_auth... [ OK ]
>> Starting dirsrv:
>> bb_auth... [ OK ]
>> root at 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 at 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 at 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 at 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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
More information about the 389-users
mailing list