5

I used the following LDIF file to activate the TLS support for the LDAP server:

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL 
-
add: olcTLSCRLCheck
olcTLSCRLCheck: none
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/CA.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/key.pem

and force the TLS usage for the client connections with the following LDIF:

dn: cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

After this I can't use the "-Y EXTERNAL" any more to read or modify the configuration schema. For example I get SASL error if I run:

$ sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
    additional info: SASL(-4): no mechanism available:

and if I check for supported SASL mechanisms:

$ sudo ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

I really can't see the EXTERNAL included in the list. What am I missing here?

This is on Ubuntu-12.04 and slapd-2.4.31.

kasperd
  • 30,455
  • 17
  • 76
  • 124
user202
  • 53
  • 1
  • 1
  • 3

4 Answers4

4

Without access to the running config, you'll have to stop slapd and edit the configuration offline.

  1. stop slapd: service slapd stop
  2. dump the config database to a text file: slapcat -F /etc/ldap/slapd.d -b cn=config -l config.ldif
  3. move the existing config database out of the way: mv /etc/ldap/slapd.d{,.old}

  4. make a new, empty config database:

    mkdir /etc/ldap/slapd.d chown --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d chmod --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d

  5. edit the dumped config.ldif to remove your olcSecurity setting (or add olcRootDN and olcRootPW to cn=config, or any other changes you like)
  6. load the edited LDIF into the new empty database: slapadd -F /etc/ldap/slapd.d -b cn=config -l config.ldif

(The above assumes your configuration lives at /etc/ldap/slapd.d, which is the default in Debian and Ubuntu.)

Note that slapadd of a complete LDIF should always be done into an empty database; so if you make a mistake and slapadd fails, make sure to clear out the partial database before trying again.

You can find more information in the OpenLDAP Admin Guide as well as the relevant man pages.

rtandy
  • 346
  • 1
  • 5
2

Looking into the code: on the server side, in servers/slapd/daemon.c, the authid for EXTERNAL is set up using the uid and gid shortly after the incoming connection is accept()ed. Later on, in servers/slapd/connection.c, if TLS is active, it overwrites that with the name from the client's certificate. Since you aren't providing a client certificate, at this point the authid gets overwritten with NULL, making EXTERNAL not available.

In short, if TLS is active then the uid+gid authid is not used. Depending on your perspective, this could be considered a bug; ideally it would fall back to the peercred ID.

That said, TLS on ldapi is really not necessary as the local socket already provides total privacy; so you could set olcSecurity just on your own database, leaving it not set for the frontend and cn=config (see e.g. this post), or you could use ssf= instead of tls= and set olcLocalSSF appropriately. Or you could use a different DN as the manager for cn=config, in order to not depend on the peercred feature.

rtandy
  • 346
  • 1
  • 5
0

Using ldappi:/// instead of ldap:// solved the issue for me after activating starttls on my system

sudo ldapmodify -Y EXTERNAL -H ldapi://  -f pwd2.ldif

works whereas 

sudo ldapmodify -Y EXTERNAL -f pwd2.ldif

reported

SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available:

mneiger
  • 1
0

Thanks rtandy. I really didn't want to set it on ldapi but was not aware of the fact it is going to be affected too.

The problem is the EXTERNAL was the only way I could modify the cn=config so since I've lost that access and haven't created another cn=config admin as suggested, is there any other way I can solve this?

user202
  • 1