Recently I’ve been working on moving a common web application hosted in a LAMP stack from an Ubuntu box I’d like to retire to CentOS box. The outgoing server has Apache 2.2 configured for LDAP authentication with an LDAP filter to limit access to a particular group in Active Directory. That configuration amounted to only a few lines in an Apache configuration file. Moving it over to the new server should have been simple, but I ran into a few snags along the way. These details may be an interesting point of clarification an element of the documentation.
First, while trying to configure the same authentication and authorization pieces on the new server, I was running into issues with the LDAP authorization phase not working when using the DN for the root of the domain. Next, I was having challenges with the authorization phase for anything more than “Require valid-user” once the authentication phase issue was resolved.
The Search Base
For starters, our AD users who need access to the application are in different OUs that don’t share a common parent object other than the root of the domain. For reasons that I don’t understand yet, when I use the DN for the root of the domain in the AuthLDAPURL I would have problems in the authentication phase. I could see this changing my LDAP URL to ldap:// instead of ldaps:// so I could watch the traffic with WireShark on the domain controller.
After the initial ldap bind with the credentials used in AuthLDAPBindDN and AuthLDAPBindPassword there’s a ‘searchResEntry’ for the DN of the user logging in. Next are three successful bind requests followed by ‘wholeSubtree’ search requests for ‘CN=Configuration’, ‘DC=DomainDnsZones’, ‘DC=ForestDnsZones’ DNs. Three operationErrors with a comment of, ‘In order to perform this operation a successful bind must be completed on the connection’ follow the search requests. Finally, I get a 500 error from Apache on the browser.
Again, I’m not sure why this is a problem on the CentOS 6 box this application is being migrated to, and it wasn’t a problem on the Ubuntu box the application is being moved away from. I have seen similar behavior to this before when using LDAP for authentication on Dovecot. A simple work around is to change the AuthLDAPURL to use the DN of the OU containing the users needing access instead of the DN for the root of the domain, which leads me to the learning experience I’d like to share.
The Apache mod_authn_alias was the work around I chose to address using different AuthLDAPURL values for users in different OUs. This module allows Apache to check multiple sources to authenticate users against. First, I verified Apache is configured to load the authn_alias_module. Next, I added a few AuthnProviderAlias blocks to an auth_ldap.conf file I added to the /etc/httpd/conf.d directory. Each block contained a different AuthLDAPURL for the DN of each OU that contain the users I need to accommodate.
Additionally, this directive will not work inside a VirtualHost definition. There is an indicator for this in the comment section of the module documentation, and Apache will complain about it if you put an AuthnProviderAlias block in a VirtualHost definition.
<AuthnProviderAlias ldap ldap-Company>
authn vs. authz
With the issue of using multiple LDAP search bases in my directory taken care of for the authentication phase, I was then running into an issue with the authorization phase not working. Neither a ‘require ldap-group’ or ‘require ldap-filter’ directives would work. However, a ‘require valid-user’ directive did work.
First I turned up the LogLevel in Apache to debug so I could watch for ldap errors. With debug turned on I was seeing the following in the Apache error log:
[error] [client 10.10.67.6] access to / failed, reason: require directives present and no Authoritative handler.
Next, I went back to WireShark to watch the ldap traffic on the domain controller. In WireShark I wouldn’t see any sort of comparison query in the ldap traffic when using either of the ‘require ldap-*’ directives set in Apache. Yet, if I used the ‘require valid-user’ directive, I would see a comparison query for the DN of the user being authenticated.
They key point here is in the difference between authn and authz elements of Apache modules. The documentation for the mod_authn_alias modules says, “This directive has no affect on authorization, even for modules that provide both authentication and authorization.” Essentially, Apache didn’t have any information for making an authorization comparison via ldap when using either of the ‘require ldap-*’ directives with the AuthnProverAlias blocks added to the configuration and only specifying those aliases in the AuthBasicProvider directive for the directory block.
The problem was solved by adding AuthLDAPURL, AuthLDAPBindDN, and AuthLDAPBindPassword directives to the directory block to specify how the ldap module should make an ldap comparison for the authorization phase (authz).
AuthName "Enter Company Domain User Name: (first.last)"
# AuthnProverAlias for different OUs
AuthBasicProvider ldap-Company ldap-OtherCompany ldap-ServiceAccounts
# Values needed for authz component of mod_authnz_ldap module
# Otherwise, authorization phase will fail if these are missing
Require ldap-group CN=Nagios_Web_Access,OU=ServiceAccounts,DC=corp,DC=example,DC=com
# Require valid-user
Some other potentially helpful links: