[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
error:

** {{{badmatch,
         {error,
             {asn1,
                 {'Type not compatible with table constraint',
                     {{component,'Type'},
                      {value,{5,<<>>}},
                      {unique_name_and_value,id,{1,2,840,113549,1,1,11}}}}}}},
     [{public_key,pkix_decode_cert,2},
      {ssl_certificate,trusted_cert_and_path,3},
      {ssl_handshake,certify,7},
      {ssl_connection,certify,2},
      {ssl_connection,handle_tls_handshake,3},
      {ssl_connection,next_state,3},
      {gen_fsm,handle_msg,7},
      {proc_lib,init_p_do_apply,3}]},
    {gen_fsm,sync_send_all_state_event,[<0.329.0>,start,infinity]}}

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 {{255.255.255.255},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 255.255.255.255 ({{255.255.255.255},57224})
5

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
membership.

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
ldap_tls_verify).

{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


Cheers,
-- 
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