My head hurts from banging it on the desk and I could use a couple of suggestions.

I'm trying to configure ldap authentication within apache but it doesn't look like I can reach the ldap server for some reason. I did a bit of research and most of the problems people have when it comes to this error revolve around SSL & certificates which I am not using.

Here is a scrubbed version of the apache config:

<LocationMatch "^/+$">
AuthType Basic
Require valid-user
AuthzLDAPAuthoritative Off
AuthBasicProvider ldap
AuthName "my domain"
AuthLDAPBindDN "CN=Me,DC=mydomain,DC=com"
AuthLDAPBindPassword "secret"
AuthLDAPURL "ldap://host:3268/dc=mydomain,dc=com?sAMAccountName?sub?(objectClass=*)" NONE
</LocationMatch>

Here is an excerpt from the error log:

[debug] mod_authnz_ldap.c(403): [client 127.0.0.1] [16430] auth_ldap authenticate: using URL ldap://host:3268/dc=mydomain,dc=com?sAMAccountName
[info] [client 127.0.0.1] [16430] auth_ldap authenticate: user Me authentication failed; URI / [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]

I can successfully use ldapsearch from the host apache is running on using that same bind name/pword combination so I don't think it's a problem with iptables or a firewall. I can also hit the ldap server using Apache Directory Studio from the apache box so it really is just httpd that's giving me grief.

I'm running Apache 2.2.21 on Fedora 16. I'm trying to hit an Active Directory server running elsewhere on the network but I'm not sure of the details for that host to be honest.

It's probably some stoopid configuration issue but does anyone have any ideas on what I should look into next?

what do the server logs say?

Sorry, which server log(s) are you interested in specifically? The excerpt I posted was from /var/log/httpd/error_log. There is nothing of interest in the co-located access_log. I don't have access to the ldap server so I can't check it's logs but I don't think the request is getting that far because...

I ran tcpdump to monitor network traffic and I don't see any requests forwarded to the ldap host when I try to authenticate via the web page (httpd). However, I see a lot of bidirectional communication between the two hosts (apache & ldap) when I use ldapsearch or Directory Studio. In other words, I'm pretty confident httpd is choking and reporting an error before the request ever goes out on the wire (I modified the URL to use an IP address to avoid a DNS lookup). FWIW, the web page is a generic Internal Server Error 500 page. I'm using ldap_module and authnz_ldap_module on the httpd side. Is there some other module I may need? I see there is something called 'mod_auth_ldap' I can take for a test drive.

This is a new install of apache so the configuration options are pretty much what you get right out of the box save for the ldap-related configuration changes I made and provided in my original post. Are there any other apache config parameters you're aware of that may be of benefit?

Two items of interest in /var/log/messages:

Dec 28 12:17:42 myhost httpd[25376]: httpd: Could not reliably determine the server's fully qualified domain name, using myhost.mydomain.com for ServerName
Dec 28 12:17:42 myhost systemd[1]: Failed to read PID file /var/run/httpd/httpd.pid after start. The service might be broken.

The pid file exists and is owned by root so I suspect I just need to tweak a config setting. I doubt that has any bearing on this problem though.

The former error is probably indicative of the root cause and I suspect I need to tweak my /etc/hosts file or something to the like. Other suggestions welcome but I'll be googling in the meantime.

Fixed the above two issues and now I'm left with this:

Dec 28 12:58:53 myhost kernel: [98404.310603] type=1400 audit(1325105933.615:6103): avc: denied { name_connect } for pid=26664 comm="httpd" dest=3268 scontext=system_u:system_r:httpd_t:s0 tcontext=system_ubject_r:ldap_port_t:s0 tclass=tcp_socket

I was actually getting the above error in the /var/log/messages log earlier but the other errors caught my attention first so technically I guess I'm not making progress.

SELinux related perhaps?

Too early to start drinking?

It was a SELinux issue.

# getsebool -a | grep ldap
authlogin_nsswitch_use_ldap --> off
httpd_can_connect_ldap --> off

# setsebool httpd_can_connect_ldap 1

# getsebool -a | grep ldap
authlogin_nsswitch_use_ldap --> off
httpd_can_connect_ldap --> on

And now it magically works. Another Festivus miracle!

I just wanted to add a little more info because there were a couple of other gotchas once I moved to using SSL.

Our SSL certificates are self-signed so I needed to add the following to my apache conf file for the site:

LDAPTrustedMode SSL
LDAPVerifyServerCert Off

The other requisite change was to the AuthLDAPURL parameter: changed the protocol to 'ldaps', switched the port to 3269 and changed the trailing 'NONE' to 'SSL'.

I couldn't login once again with the same error as before and I could see that it was SELinux blocking communication.

# semanage port -l | grep 3268
ldap_port_t tcp 389, 636, 3268
# semanage port -l | grep 3269

From the above it's evident that my target port, 3269, isn't registered with the correct port type.

# semanage port -a -t ldap_port_t -p tcp 3269

# semanage port -l | grep 3269
ldap_port_t tcp 3269, 389, 636, 3268

The reason we're using ports 3268 and 3269 is because those are the standard Global Catalog ports. I would guess the omission of 3269 is a bug.

And now it works again (and without broadcasting unencrypted passwords all over the network).