Monthly Archives: November 2011

FreeBSD and OpenLDAP Grief

Finally got my FreeBSD client to authenticate against my OpenLDAP server. 

The configuration is fairly straightforward. What took the time was compilation the dependencies (running it in a VM can do that to it). That and the following issues.

– It seems that Perl is not a requirement for a FreeBSD install. Not a big deal, (thinking about it, it make sense historically), but I needed to get the certs installed – which mean a install of Perl. Fun.

– ca-root no longer exists. Had to use ca-root-nss to build.

– After working with Red Hat for a while, manually setting up pam was pain.

– I couldn’t get pass pam_ldap almost all night and part of the afternoon, until I tailed /var/log/auth.log, which showed me this:

User rfoster not allowed because shell /bin/bash does not exist

Bash is not installed by default. Another compile. But afterwards, I was finally able to login.

From there, it was a matter of using amd to work so that I can automount the directories. Using this as a guideline, I setup the symlinks in /usr/home to the mounts:

ln -sf /host/ .

Then I add my ldap user to wheel group (so that I can become root):

freebsd82# pw groupmod wheel -m rfoster

freebsd82# pw groupshow wheel



And… I am done.

Next, configure SuSE Enterprise Linux 11 with LDAP authentication. 🙂

TLS problems with OpenLDAP Client

I ran into an interesting problem sometime back that I only now resolved.

Originally, I was running Scientific Linux on most of my VM. I have since upgraded most of them to Centos 6.0 – and converted on in particular to Centos CR. 

That “broke” my ldap authentication – when connecting to the server with the ldapuser credentials, sssd returns with the following:

Could not start TLS encryption. TLS error -8172:Unknown code ___f 20

At the time, I thought that there was a bug with the updated sssd package on Centos CR, so I ignored it for while – until I logged into a fairly new Scientific Linux 6.1 VM today – and it gave me the same message.

That was curious. So I dug deep into searching for a solution. 

As it turns out, the problem was my configuration. Apparently I had been connecting with a self-signed certificate, which the following:

[root@localhost ~]# openssl verify cacert.pem 

backup.cacert.pem: C = US, ST = Georgia, O = Monzell Management Systems, OU = IT, CN =, emailAddress =

error 18 at 0 depth lookup:self signed certificate


It seems with the initial version of sssd with 6.0 , it was allowing me to connect without complaining about it being a self-sign cert. With the updated version, it is now refusing to connect without a valid certificate. I can confirm that by running:


ldapsearch -d -1 -vvvvv -w PASSWORD -ZZZ -H ldap:// -D "cn=root,dc=example,dc=com" "(uid=joeuser)"



TLS: certificate [CN=StartCom Certification Authority,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL] is not valid - error -8172:Unknown code ___f 20.

tls_write: want=7, written=7

  0000:  15 03 01 00 02 02 30                               ......0           

TLS: error: connect - force handshake failure: errno 0 - moznss error -8172

TLS: can't connect: TLS error -8172:Unknown code ___f 20.

After I put in the correct certificate, I was able to connect:


tls_read: want=48, got=48 0000: f0 85 60 72 54 c1 3b c8 6f 53 c4 f0 89 82 27 17 ..`rT.;.oS....'. 0010: 3c 3f 99 8f 18 64 22 ae 41 28 d4 a6 0b 0f a4 de <?...d".A(...... 0020: 36 10 3e d4 6c f5 73 fb cb 12 04 af 64 7f 14 69 6.>.l.s.....d..i TLS certificate verification: subject:,, <REDACTED> ldap_sasl_bind ldap_send_initial_request ldap_send_server_request


And openssl returned with no errors:
[root@localhost cacerts]# openssl verify cacert.pem cacert.pem: OK