[ejabberd] LDAPS and TLS/STARTTLS failing

Richard Clark richard at fohnet.co.uk
Wed Nov 27 19:10:37 MSK 2013

Running ejabberd 2.1.13 on CentOS 6.4

Trying to get LDAPS or LDAP/STARTTLS working, but ejabberd is not
playing ball.

1) LDAP/TLS support

My preferred solution, but a non starter apparently. When attempting
LDAPS, ejabberd refuses to start (it initates a tcp connection to the
LDAP server at the other end and then bails with a fairly generic SSL

** {{{badmatch,
                 {'Type not compatible with table constraint',

I can see in the LDAP server logs that we're getting a TCP connection from
ejabberd that is then abruptly closed as the server terminates.

2) STARTTLS support

When running in STARTTLS mode, ejabberd actually starts, _but_ it does not
actually attempt STARTTLS connection

=INFO REPORT==== 2013-11-27 14:18:13 ===
I(<0.358.0>:ejabberd_listener:281) : (#Port<0.4142>) Accepted connection {{},57224} -> {{10,32,123,123},5222}

=INFO REPORT==== 2013-11-27 14:18:13 ===
I(<0.400.0>:ejabberd_c2s:659) : ({socket_state,tls,{tlssock,#Port<0.4142>,#Port<0.4144>},<0.399.0>}) Failed authentication for rclark at xmpp-test-001.eu-west-1.aws.compute.example.net@xmpp-test-001.eu-west-1.aws.compute.example.net from IP ({{},57224})

From ejabberd logging perspective it looks like we have a secure TLS connection
and the entered password is incorrect.

..But the LDAP server tells another story. With a bit of log digging and
tcpdump we can see what actually happens is ejabberd skips the STARTTLS part,
just connects to the server over 389, does a bind request, dutifully sending
it's bind username/password in plain-text then says 'is this user a member of
these groups?', to which the LDAP server responds 'you need to run over an
encrypted connection to see that' (i.e minimum SSF not met, enforced by
schema). A few miliseconds later it retries with exactly the same request, and
receives the same response from the LDAP server.

What it _should_ be doing is first initiating a STARTTLS request, getting a
secure channel setup, then attempting a bind against it's configured
username/password through that secure channel, and only then checking group

Relevant parts of LDAP config from ejabberd.cfg (I've tried with and without
and various combinations of ldap_tls_cacertfile, ldap_tls_depth, and

{auth_method, ldap}.
%% List of LDAP servers:
{ldap_servers, ["auth-fipa-prod-001.prod.example.net"]}.
%% Encryption of connection to LDAP servers:
{ldap_encrypt, starttls}.
{ldap_tls_verify, false}.
{ldap_tls_cacertfile, "/etc/pki/tls/certs/prod.example.net_CA.crt"}.
{ldap_tls_depth, 3}.
%% Port to connect to on LDAP servers:
{ldap_port, 389}.
%% LDAP manager:
{ldap_rootdn, "uid=svc_ejabberd_bind,cn=sysaccounts,cn=etc,dc=prod,dc=example,dc=net"}.
%% Password of LDAP manager:
{ldap_password, "Decs2wroackkatladepEijacunJebkoy"}.
%% Search base of LDAP directory:
{ldap_base, "dc=prod,dc=example,dc=net"}.
%% LDAP attribute that holds user ID:
{ldap_uids, [{"uid"}]}.
%% LDAP filter:
{ldap_filter, "(memberOf=cn=example_chat_users,cn=groups,cn=accounts,dc=prod,dc=example,dc=net)"}.

Any help or light that anyone could shine on this would be mightily appreciated.

Passwords/IP addresses/domains changed to protect the innocent

Richard Clark
richard at fohnet.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: Digital signature
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20131127/a344020a/attachment.sig>

More information about the ejabberd mailing list