httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [users@httpd] mod_authnz_ldap: constructible AuthLDAPBindDN
Date Sat, 19 Jun 2010 11:48:26 GMT
I've searched the mod_authnz documentation and also had already a look 
into mod_authnz's sources to find an existing chance to configure some 
kind of variable "bindDN-Pattern" but after reading both I understand 
mod_authnz the way that it is mandatory to either use anonymous bind or 
some kind of "proxy-user bind" (AuthLDAPBindDN) to search for an user's 
DN (e.g. searching for uid/email) to bind to the LDAP server using the 
found DN and the user provided password.

Have I missed something during my readings or is this an unsupported 

For example apache's tomcat 5.5/6.0 JNDIrealm's configuration already 
does provide a userPattern (please see and 
search for "userPattern").

Please let me explain the background why there is a common demand for 
such a mod_authnz feature:
Anonymous and even proxy-user based search request could harm a 
company's restrictive data privacy policies. Therefore some directory 
information tree (DIT) and LDAP server designs offer advanced but very 
easy (for clients like mod_authnz) to implement/use approaches to offer 
the administrator a chance to get rid of the need for proxy-user based 
search but to be able to make an authorization decission directly in 
each user's context.

As searching the user's branch seems not very harmful in regard to 
privacy concerns searching the groups and their memberships is 
definitively more "interesting". In modern directory 
designs/implementations therefore an user's group membership is also 
stored (as the DNs of the groups a distinct user is member of) directly 
in each user's entry where the directory keeps track of the referential 
integrity (which for example is supported by openldap). Thus there is no 
need to expose the groups and their membership in general to any 
service's proxy-user.

Instead, the authorization decision can be made directly using the 
authenticated user's ldap connection as the user has been successfully 
bind to the LDAP server before. Take for example this shortend LDIF 
based user entry:

dn: uid=userA,dc=example,dc=com
uid: userA
memberOf: cn=groupA,dc=example,dc=com
memberOf: cn=groupB,dc=example,dc=com
memberOf: cn=groupC,dc=example,dc=com

IMHO there's no a need to prior search for "(uid=userA)" using a proxy 
user in case the company's default policy is to just permit the uid for 
login (instead of the eMail address for example) and use the user 
provided uid to construct the bindDN which will be bind against the LDAP 
server using the provided password. If the bind was successful the 
user's connection (in this user's context) can be used to *compare* his 
memberOf attribute against the authorized groupDN. Please note that an 
LDAP server that only allows the "compare" operation on the memberOf 
attribute (which can be enforced by LDAP server internal ACLs) will not 
disclose any others of this user's group membership information to the 
service (compare != search and compare != read) which fulfills most 
restrictive privacy policies.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message