How to authenticate users in nested groups in Apache LDAP?

Solution 1:

Besides AuthLDAPSubGroupDepth, that is available only in apache 2.4, it is possible, when using Microsoft AD LDAP, to do authorization using nested groups by using LDAP_MATCHING_RULE_IN_CHAIN matching rule. This is much faster than searching subgroups on the client, because it is done on the DC server with less queries over network.

Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=Access to Apache,OU=My Organization Unit,DC=company,DC=com

The string 1.2.840.113556.1.4.1941 is an OID called LDAP_MATCHING_RULE_IN_CHAIN. This OID is assigned by Microsoft to be used with its LDAP implementation (part of Active Directory). You can not use it with other LDAP servers. The human redeable format is: iso(1).member_body(2).us(840).microsoft(113556).ad(1).as_schema(4).LDAP_MATCHING_RULE_IN_CHAIN(1941)

From Microsoft documentation:

This rule is limited to filters that apply to the DN. This is a special "extended" match operator that walks the chain of ancestry in objects all the way to the root until it finds a match.

See also:

  • http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%28v=vs.85%29.aspx
  • http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authorphase

Solution 2:

You need to set AuthLDAPSubGroupDepth to make this work. The integer you provide here specifies the maximum sub-group nesting depth that will be evaluated before the user search is discontinued.

Add this to your config:

AuthLDAPSubGroupDepth 1

More Info: here and here.


Solution 3:

It looks like your only option in Apache 2.2 is to list every group that is included by your main authorized group.

Require ldap-group  CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local
Require ldap-group  CN=MyOtherGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local

This should be reasonable if your nested groups aren't too complicated.


Crossing AD Domains(using two LDAP servers)

You can set up OpenLDAP with the slapd_meta overlay running on your web server to proxy your authentication.

/etc/ldap/slapd.conf should look something like:

database meta
suffix   "DC=company,DC=local"
uri      "ldap://a.foo.com/OU=MyBusiness,DC=company,DC=local"
uri      "ldap://b.foo.com/OU=otherdomainsuffix,DC=company,DC=local"

Then, your mod_authnz_ldap stanza would look something like:

AuthName            "whatever"
AuthType            Basic
AuthBasicProvider   ldap
AuthLDAPUrl         "ldapi:///DC=company,DC=local?sAMAccountName?sub?(objectClass=*)"
Require ldap-group  CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local
Require ldap-group  CN=MyOtherGroup,OU=Security Groups,OU=otherdomainsuffix,DC=company,DC=local

This will require some massaging to get it to work, but I think this is the general idea.


Solution 4:

While the solution provided by @Mircea_Vutcovici worked for me, my only criticism is that people may get squeamish when they see bitwise operators in use.

For instance, I'll be handing over an Apache Bloodhound installation, that uses Apache HTTPd as the front end with AD group auth, to a group of fellow developers. They're going to have issues coming to grips with bitwise operators. Admins will not be as squeamish of course...I hope.

That being said, I have a solution that doesn't use the bitwise operator and that doesn't use multiple ldap-group definitions.

The following config works for me:

<Location /protected>
    # Using this to bind
    AuthLDAPURL "ldap://<MY_SERVER>:3268/<MY_SEARCH_BASE>?sAMAccountName?sub?(objectClass=user)"
    AuthLDAPBindDN "<MY_BIND_DN>"
    AuthLDAPBindPassword "<MY_PASSWORD>"
    LDAPReferrals Off

    AuthType Basic
    AuthName "USE YOUR AD ACCOUNT"
    AuthBasicProvider ldap
    Require ldap-group <MY_PARENT_GROUP>
    AuthLDAPMaxSubGroupDepth 1
    AuthLDAPSubgroupAttribute member
    AuthLDAPSubGroupClass group
    AuthLDAPGroupAttribute member
    AuthLDAPGroupAttributeIsDN on
</Location>

The critical part was the following config:

AuthLDAPSubGroupClass group

AuthLDAPMaxSubGroupDepth doesn't work by itself, nor when coupled with AuthLDAPSubgroupAttribute. It was only when I used AuthLDAPSubGroupClass that auth against sub groups started working...at least for me and my situation.