$ sudo ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
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.
Without access to the running config, you'll have to stop slapd and edit the configuration offline.
stop slapd: service slapd stop
dump the config database to a text file: slapcat -F /etc/ldap/slapd.d -b cn=config -l config.ldif
move the existing config database out of the way: mv /etc/ldap/slapd.d{,.old}
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
edit the dumped config.ldif to remove your olcSecurity setting (or add olcRootDN and olcRootPW to cn=config, or any other changes you like)
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.
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.
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?
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:
