[389-users] [solved] Re: 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:32:48 UTC 2012
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 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
>
> --
> 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