[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 10:15:43 UTC 2012
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 ]
root at ldap:~# yum remove 389-ds*
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
More information about the 389-users
mailing list