[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
Mon Jul 9 11:27:35 UTC 2012
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 at ldap:~# service dirsrv stop
>>>> Shutting down dirsrv:
>>>> bb_auth... [ OK ]
>>>> root at ldap:~# service dirsrv-admin stop
>>>> Shutting down dirsrv-admin:
>>>> [ OK ]
>>> remove-ds-admin.pl -y
>>>
>>>> root at ldap:~# yum remove 389-ds*
>>>
>>> yum remove 389*
>>>
>>> yum remove 389-ds* won't remove 389-console, 389-admin, etc.
>>>
>>>>
>>>> root at ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv
>>>> /var/lib/dirsrv /root/.389-console
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Now everything 389-related should be wiped from the box. Please
>>>> correct me if I'm wrong.
>>>>
>>>> Next, I switch off iptables and disable selinux:
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# service iptables stop
>>>> root at ldap:~# setenforce 0
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Now I start from scratch:
>>>>
>>>> /etc/hosts:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# cat /etc/hosts
>>>> 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost
>>>> localhost.localdomain localhost4 localhost4.localdomain4
>>>> ::1 ldap.baar.intra.bbcomputing.org localhost
>>>> localhost.localdomain
>>>> localhost6 localhost6.localdomain6
>>>>
>>>> 192.168.10.37 ldap.baar.intra.bbcomputing.org
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Installation:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# yum install 389-ds
>>>> ...
>>>> Running Transaction
>>>> Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9
>>>> Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9
>>>> Installing : 389-admin-1.1.29-1.el6.x86_64 3/9
>>>> Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9
>>>> Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9
>>>> Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9
>>>> Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9
>>>> Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9
>>>> Installing : 389-ds-1.2.2-1.el6.noarch 9/9
>>>>
>>>> Installed:
>>>> 389-ds.noarch 0:1.2.2-1.el6
>>>> ...
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Looks ok to me. (Again: Please correct m if I'm wrong)
>>>>
>>>>
>>>> Setup:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# setup-ds-admin.pl
>>>>
>>>> My answers here:
>>>> Would you like to continue with set up? [yes]: y
>>>> Would you like to continue? [yes]: y
>>>> Choose a setup type [2]: 2
>>>> Computer name [ldap.baar.intra.bbcomputing.org]:
>>>> ldap.baar.intra.bbcomputing.org
>>>> System User [nobody]: nobody
>>>> System Group [nobody]: nobody
>>>> Do you want to register this software with an existing
>>>> configuration directory server? [no]: n
>>>> administrator ID [admin]: admin
>>>> Password: <pw1>
>>>> Password (confirm): <pw1>
>>>> Administration Domain [baar.intra.bbcomputing.org]:
>>>> intra.bbcomputing.org
>>>> Directory server network port [389]: 389
>>>> Directory server identifier [ldap]: bb_auth
>>>> Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]:
>>>> dc=bbcomputing,dc=org
>>>> Directory Manager DN [cn=Directory Manager]: cn=Directory Manager
>>>> Password: <pw2>
>>>> Password (confirm): <pw2>
>>>> Administration port [9830]: 9830
>>>> Are you ready to set up your servers? [yes]: y
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Here's the following output:
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> Creating directory server . . .
>>>> Your new DS instance 'bb_auth' was successfully created.
>>>> Creating the configuration directory server . . .
>>>> Beginning Admin Server creation . . .
>>>> Creating Admin Server files and directories . . .
>>>> Updating adm.conf . . .
>>>> Updating admpw . . .
>>>> Registering admin server with the configuration directory server .
>>>> . .
>>>> Updating adm.conf with information from configuration directory
>>>> server . . .
>>>> Updating the configuration for the httpd engine . . .
>>>> Starting admin server . . .
>>>> output: Starting dirsrv-admin:
>>>> output: [ OK ]
>>>> The admin server was successfully started.
>>>> Admin server was successfully created, configured, and started.
>>>> Exiting . . .
>>>> Log file is '/tmp/setup1dRGLl.log'
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Again, looks all ok to me.
>>>>
>>>> Especially the processes looks good:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# ps -ef |grep dirsrv
>>>> nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D
>>>> /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w
>>>> /var/run/dirsrv/slapd-bb_auth.startpid
>>>> root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f
>>>> /etc/dirsrv/admin-serv/httpd.conf
>>>> root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start
>>>> -f
>>>> /etc/dirsrv/admin-serv/httpd.conf
>>>> nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k
>>>> start
>>>> -f /etc/dirsrv/admin-serv/httpd.conf
>>>> root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> And netstat also looks just sweet:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# netstat -lntp
>>>> Active Internet connections (only servers)
>>>> Proto Recv-Q Send-Q Local Address Foreign Address State
>>>> PID/Program name
>>>> ...
>>>> tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker
>>>> ...
>>>> tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd
>>>> ...
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> In fact, I can run 389-console at this point and successfully log
>>>> into the management console:
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# 389-console
>>>>
>>>> Using:
>>>> User ID: cn=Directory Manager
>>>> Password: <pw2>
>>>> Administration URL: http://localhost:9830
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> So far so good without TLS.
>>>>
>>>>
>>>>
>>>>
>>>> Now the pain pain starts:
>>>>
>>>> To set up TLS I foung this script in the 389 Howto:SSL docs:
>>>>
>>>> http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true
>>>>
>>>> So I naively ran this thing:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/
>>>> Using /etc/dirsrv/slapd-bb_auth/ as sec directory
>>>> No CA certificate found - will create new one
>>>> No Server Cert found - will create new one
>>>> No Admin Server Cert found - will create new one
>>>> Creating password file for security token
>>>> Creating noise file
>>>> Creating new key and cert db
>>>> Creating encryption key for CA
>>>>
>>>>
>>>> Generating key. This may take a few moments...
>>>>
>>>> Creating self-signed CA certificate
>>>>
>>>>
>>>> Generating key. This may take a few moments...
>>>>
>>>> Is this a CA certificate [y/N]?
>>>> Enter the path length constraint, enter to skip [<0 for unlimited
>>>> path]: > Is this a critical extension [y/N]?
>>>> Exporting the CA certificate to cacert.asc
>>>> Generating server certificate for 389 Directory Server on host
>>>> ldap.baar.intra.bbcomputing.org
>>>> Using fully qualified hostname ldap.baar.intra.bbcomputing.org for
>>>> the server name in the server cert subject DN
>>>> Note: If you do not want to use this hostname, edit this script to
>>>> change myhost to the
>>>> real hostname you want to use
>>>>
>>>>
>>>> Generating key. This may take a few moments...
>>>>
>>>> Creating the admin server certificate
>>>>
>>>>
>>>> Generating key. This may take a few moments...
>>>>
>>>> Exporting the admin server certificate pk12 file
>>>> pk12util: PKCS12 EXPORT SUCCESSFUL
>>>> Creating pin file for directory server
>>>> Importing the admin server key and cert (created above)
>>>> pk12util: PKCS12 IMPORT SUCCESSFUL
>>>> Importing the CA certificate from cacert.asc
>>>> Creating the admin server password file
>>>> Enabling the use of a password file in admin server
>>>> Turning on NSSEngine
>>>> Use ldaps for config ds connections
>>>> Enabling SSL in the directory server
>>>> when prompted, provide the directory manager password
>>>> Password:modifying entry "cn=encryption,cn=config"
>>>>
>>>> modifying entry "cn=config"
>>>>
>>>> adding new entry "cn=RSA,cn=encryption,cn=config"
>>>>
>>>> Enabling SSL in the admin server
>>>> modifying entry "cn=slapd-bb_auth,cn=389 Directory
>>>> Server,cn=Server
>>>>
>>>> Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra.bbcomputing.org,o=NetscapeRoot"
>>>>
>>>>
>>>> modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389
>>>> Administration Server,cn=Server
>>>>
>>>> Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra.bbcomputing.org,o=NetscapeRoot"
>>>>
>>>>
>>>> Done. You must restart the directory server and the admin server
>>>> for
>>>> the changes to take effect.
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Again everything appears good to me, I can even restart the
>>>> services
>>>> without any hickups:
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# service dirsrv restart
>>>> Shutting down dirsrv:
>>>> bb_auth... [ OK ]
>>>> Starting dirsrv:
>>>> bb_auth... [ OK ]
>>>> root at ldap:~# service dirsrv-admin restart
>>>> Shutting down dirsrv-admin:
>>>> [ OK ]
>>>> Starting dirsrv-admin:
>>>> [ OK ]
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Now I try again to run 389-console with the same credentials and
>>>> everything as above, and it fails:
>>>>
>>>> In the login window it simply hangs saying 'Authenticating User ID
>>>> "cn=Directory Manager"...' and after some seconds an error
>>>> messages
>>>> appears that reads: "Cannot login because of an incorrect User ID,
>>>> incorrect password or Directory problem.
>>>> java.io.InterruptedIOException: HTTP response timeout.".
>>>>
>>>> netstat now looks like this:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# netstat -lntp
>>>> Active Internet connections (only servers)
>>>> Proto Recv-Q Send-Q Local Address Foreign Address State
>>>> PID/Program name
>>>> ...
>>>> tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker
>>>> ...
>>>> tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd
>>>> tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd
>>>> ...
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Honestly, I don't even want an SSL listener on port 636, I really
>>>> only want a listener on port 389 that requires clients to use
>>>> start_tls. But I don't care for the moment.
>>>>
>>>> Here's more pain:
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# cat /etc/openldap/ldap.conf
>>>> URI ldap://ldap.baar.intra.bbcomputing.org/
>>>> BASE dc=bbcomputing,dc=org
>>>> TLS_CACERTDIR /etc/openldap/cacerts
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> To my understanding, this should tell CentOS to query the LDAP box
>>>> mentioned in the URI part, using TLS, for users, but:
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> root at ldap:~# id raimund
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> produces nothing but these entries in /var/log/messages
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>> Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s()
>>>> failed:
>>>> Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/")
>>>> Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP
>>>> server ldap://ldap.baar.intra.bbcomputing.org/: Connect error
>>>> Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server
>>>> found
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> This looks bad. Actually the LDAP server sould respond that this
>>>> user
>>>> does not exist (empty directory at this moment), but instaead,
>>>> these
>>>> lines indicate that the entire communication with the server ist
>>>> broken.
>>>>
>>>>
>>>>
>>>> Now, this is pretty useless, isn't it? I now have two running LDAP
>>>> services (dirsrv and diesrv-admin). The first can't be contacted
>>>> at
>>>> all and the door to the admin server is also slammed shut, because
>>>> 389-console can't talk to it any more.
>>>>
>>>>
>>>> I went on a bit more and switched off SSL/TLS for the admin server
>>>> again, then 389-console logins worked at least again, but once in
>>>> the
>>>> console, it's not possible to open any of the directories.
>>>>
>>>>
>>>> Please help! I already wasted 1.5 days with this, reinstalling
>>>> about
>>>> 15 times! Sure there must be a way to get this running with TLS
>>>> *and*
>>>> the 389-console?
>>>>
>>>> Cheers,
>>>> Raimund
>>>>
>>>> -- 389 users mailing list
>>>> 389-users at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
More information about the 389-users
mailing list