-   Linux - Security (
-   -   OpenLDAP Commands Over TLS/SSL Behaves Differently? (

peridian 02-20-2011 08:30 AM

OpenLDAP Commands Over TLS/SSL Behaves Differently?
Endless fun with OpenLDAP...

Two related problems, if anybody can help me out it would save me from the headache this is giving me, conf files at the bottom of the post.


a) Does ldappasswd behave differently over a TLS connection than a non-TLS connection?

The reason I ask is that when I had a non-TLS connection, I could do the following:

Given I have an administrator setup in slapd.conf, the following command would work:

ldapsearch -x -D "cn=admin,dc=intbus,dc=net" -W -s sub "objectclass=*"

Given I have a user:


dn: uid=testuser,ou=Users,dc=intbus,dc=net
objectClass: posixAccount
objectClass: person
uid: testuser
cn: testuser
sn: testuser
uidNumber: 9999
gidNumber: 9998
homeDirectory: /home/testuser
loginShell: /bin/bash

I could do:

ldappasswd -x -D "cn=admin,dc=intbus,dc=net" -W -S "uid=testuser,ou=Users,dc=intbus,dc=net"

Followed by:

ldapsearch -x -D "uid=testuser,ou=Users,dc=intbus,dc=net" -W -s sub "objectclass=*"

And this would work. However, since I switched to TLS/SSL, I go through the same motions, and I now get Invalid Credentials. Using -d255 shows the last parts of the debug as:


ber_scanf fmt ({iaa) ber:
ber_dump: buf=0xc9992f0 ptr=0xc9992f3 end=0xc9992fc len=9
  0000:  61 07 0a 01 31 04 00 04  00                        a...1....
ber_scanf fmt (}) ber:
ber_dump: buf=0xc9992f0 ptr=0xc9992fc end=0xc9992fc len=0

ldap_bind: Invalid credentials (49)

Note that the administrator account continues to work:

ldapsearch -x -D "cn=admin,dc=intbus,dc=net" -W -s sub "objectclass=*"

I'm wondering if the password in the slapd.conf is resolved correctly, but the passwords I enter using ldappasswd are being stored in a different format, so the request cannot match them up....

The other possibility is my ACLs are getting in the way somehow....



b) I assumed that by setting the server/client TLS options to 'demand' enforced use of TLS connections. By this assumption, I thought the below two commands would be the same:

ldapsearch -x -D "cn=admin,dc=intbus,dc=net" -W -s sub "objectclass=*"
ldapsearch -x -D "cn=admin,dc=intbus,dc=net" -W -s sub "objectclass=*" -ZZ

However, the first one works fine, the second throws the usual SSL error:


ldap_start_tls: Connect error (-11)
        additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Does this actually mean that my commands have not been using TLS in the first place? I thought TLS demand was supposed to cause the request to fail if it could not use TLS (and was therefore like adding -ZZ to the command)?


.conf files



include        /etc/openldap/schema/core.schema
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema
include        /etc/openldap/schema/samba.schema

allow bind_v2

pidfile        /var/run/openldap/
argsfile        /var/run/openldap/slapd.args

TLSCACertificateFile /etc/ssl/cacert.pem
TLSCertificateFile /etc/ssl/servercrt.pem
TLSCertificateKeyFile /etc/ssl/serverkey.pem
TLSVerifyClient demand

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by * none

access to attrs=uid,uidNumber,gidNumber
        by self read
        by * none

access to *
        by self write
        by users read
        by anonymous auth
        by * none

database        bdb
suffix          "dc=intbus,dc=net"
rootdn          "cn=admin,dc=intbus,dc=net"
rootpw          <crypto removed>
directory      /var/lib/ldap

index objectClass                      eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                    eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub



URI ldap://
PORT 389
BASE dc=intbus,dc=net
TLS_CACERT /etc/openldap/cacerts/cacert.pem
TLS_CERT /etc/openldap/cacerts/
TLS_KEY /etc/openldap/cacerts/



base dc=intbus,dc=net
uri ldap://
port 389
timelimit 5
bind_timelimit 5
bind_policy soft
pam_filter objectclass=posixAccount
nss_base_passwd        ou=Users,dc=intbus,dc=net?one
nss_base_shadow        ou=Users,dc=intbus,dc=net?one
nss_base_group          ou=Groups,dc=intbus,dc=net?one
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
ssl start_tls
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_cert /etc/openldap/cacerts/
tls_key /etc/openldap/cacerts/
pam_password md5

peridian 02-20-2011 01:31 PM


After trial and error, found the answer to problem a)

The issue was with the ACL:


access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by * none

Should have been:


access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by anonymous auth
        by * none

Apparently the LDAP tools require this line in there to work. Not sure as to why though.

Now I just need to figure out whether or not the system really is using TLS or not....


All times are GMT -5. The time now is 05:00 AM.