[solved] Re: 389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.

[Ray <ray@xxxxxxxxxxxxxxxxxx>]

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

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users