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
BASE dc=busy-byte,dc=org
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
/etc/pam_ldap.conf:
base dc=bbcomputing,dc=org
uri
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(a)lists.fedoraproject.org
>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users