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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
