Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Directory (http://www.linux-archive.org/fedora-directory/)
-   -   389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help. (http://www.linux-archive.org/fedora-directory/680971-389-ds-centos-6-2-tls-self-signed-setupssl2-sh-script-389-console-complete-fail-would-appreciate-help.html)

Ray 07-07-2012 10:15 AM

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

Rich Megginson 07-07-2012 03:52 PM

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

Ray 07-07-2012 05:25 PM

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

Arpit Tolani 07-08-2012 05:30 PM

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

Ray 07-09-2012 11:27 AM

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

Ray 07-09-2012 11:32 AM

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

upen 09-28-2012 03:27 AM

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 09:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.