I have a rabbitmq server that I need to hook up to AD.

Configuration is set using puppet rabbitmq module, with some minor manual changes (log level):

% This file managed by Puppet
% Template Path: rabbitmq/templates/rabbitmq.config
  {rabbit, [
    {auth_backends, [rabbit_auth_backend_internal, rabbit_auth_backend_ldap]},
         {packet,        raw},
         {reuseaddr,     true},
         {backlog,       128},
         {nodelay,       true},
         {exit_on_close, false}]
    {default_user, <<"guest">>},
    {default_pass, <<"guest">>}
  {kernel, [

  {rabbitmq_management, [
    {listener, [
      {port, 15672}
% Configure the LDAP authentication plugin
  {rabbitmq_auth_backend_ldap, [
    {other_bind, anon},
    {servers, ["ldap"]},
    {user_dn_pattern, "CN=Rabbitmq LDAP User,OU=Service Accounts,DC=very,DC=chill,DC=domain"},
    {use_ssl, false},
    {port, 389},
    {log, network}

The error log when I try to log in into the web console of management plugin:

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
LDAP CHECK: login for myuser

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
        LDAP filling template "CN=Rabbitmq LDAP User,OU=Service Accounts,DC=very,DC=chill,DC=domain" with

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
        LDAP template result: "CN=Rabbitmq LDAP User,OU=Service Accounts,DC=very,DC=chill,DC=domain"

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
    LDAP connecting to servers: ["ldap.very.chill.domain"]

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
    LDAP network traffic: Connect: "ldap.very.chill.domain" failed {error,

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
    LDAP connect error: {error,"connect failed"}

=INFO REPORT==== 18-Dec-2015::18:01:03 ===
LDAP DECISION: login for myuser: {error,"connect failed"}

=ERROR REPORT==== 18-Dec-2015::18:01:03 ===
webmachine error: path="/api/whoami"

This left no logs at the server side of AD, so I ran a tcpdump:

tcpdump -nnS -i ens160 | grep -vi arp | grep ldap.server.ip
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), capture size 65535 bytes

Which showed that no packets where ever sent to ldap:389 port.

So I did this from rabbit server machine to make sure there are no problems with the network:

ldapsearch -x -h 'ldap.very.chill.domain' -p 389 -w "VerySec*" -D "CN=Rabbitmq LDAP User,OU=Service Accounts,DC=very,DC=chill,DC=domain" -b "DC=very,dc=chill,dc=domain"

The tcp dump during this query showed that there were packets sent to 389 and the query was successful.

So my assumption is that there is something in rabbitmq config that makes it not even try to send any packets in the direction of ldap server.

Would be grateful for any clues.

  • What's the host OS here? How is that configured with respect to SELinux, firewall, etc? – Joel E Salas Dec 18 '15 at 19:21
  • RHEL7.1. Firewalld turned off. It is a fresh install. SELlinux configuration was untouched. Defaults to enforce. Will try with disabled. – user3081519 Dec 18 '15 at 19:57
  • @JoelESalas that was it. Thank you. Please turn into answer and I will accept. – user3081519 Dec 18 '15 at 20:21

SELinux by default will block most daemons from connecting outbound. In RHEL 7 these policies got more specific (and in some cases more restrictive).

Do setenforce 0 to test, then if it works, use sealert to analyze your /var/log/audit/audit.log file to determine what course of action to take. The CentOS wiki page on SELinux is probably the single best SELinux resource on the Internet: https://wiki.centos.org/HowTos/SELinux

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.