httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schober <peter.scho...@univie.ac.at>
Subject Re: [users@httpd] apache 2.2 and ldap group authentication
Date Wed, 27 May 2009 11:03:19 GMT
* Peter Schober <peter.schober@univie.ac.at> [2009-05-27 12:33]:
> > I have tried a number of configurations for group authenticaiton, all 
> > without success.  Following is the current iteration of my apache 
> > configuration for the superteam.docs directory:
> > 
> > <Directory /files/superteam.docs>
> >    AuthType basic
> >    AuthName "Super Team Members Only"
> >    AuthBasicProvider ldap
> >    AuthzLDAPAuthoritative on
> >    AuthLDAPBindDN "cn=Manager,dc=my,dc=mydomain,dc=com"
> >    AuthLDAPBindPassword "secret"
> >    AuthLDAPGroupAttribute uniqueMember
> >    AuthLDAPGroupAttributeIsDN off
> >    AuthLDAPURL 
> > "ldap://192.168.0.92:389/ou=groups,dc=my,dc=mydomain,dc=com?cn=SuperTeam?"
> >    Require ldap-group cn=SuperTeam,ou=groups
> >    AllowOverride None
> >    Order allow,deny
> >    Allow from all
> >    Options +Includes
> >    XbitHack on
> >    </Directory>
> 
> First, AuthLDAPGroupAttributeIsDN should be on, since obviously your
> (unique)member values *are* DNs.
> (Btw, unless you require the addtional distinguishing values
> uniqueMember allows for -- and from your example you certainly don't
> --  you can just as well use the 'member' attribute. Both 'member' and
> 'uniquemember' need their values to be unique.)
> 
> Second, your "Require ldap-group" is somehow truncated, it should be
> the full DN of that group (is there some documentation that implies
> you can just leave away the baseDN or something?)

Third, the AuthLDAPURL doesn't seem to be right (see RFC 4516 for the
specs and examples). After the DN (which "identifies the base object
of the LDAP search or the target of a non-search operation.") come the
attributes you request, if you want all you'd still need to supply the
'?' with no parameter, otherwise the only one you're interested here
is (unique)member.
Then comes the scope (limit the search to the base of the object given
as the DN of the URL; to one level below the base object, or to a
subtree search, starting from and including the base object), and only
then comes the filter (which you give as cn=SuperTeam).

And with that filter (which is not interpretefd as a filter, because
it's in the wrong part, which you would see in your slapd.log) you'd
only ever find the group cn=SuperTeam, which is not wrong, but
superfluos, since you're 'require'ing the desired group below anyway
with an apache directive (once the syntax is corrected, see my point
two).

I don't think just leaving all the parts after the DN away (so their
defaults get to be used) will help, since the scope defaults to base,
and you'll need at least 'one' or 'sub', unless you specify the exact
name of the required group in the DN of that AuthLDAPURL (which I
douldn't do, since you'd have to mess with AuthLDAPURL for every
directory; same with the group name in the filter, see above).

So I guess a correct LDAP URL for your setup should be something like this:

AuthLDAPURL ldap://192.168.0.92:389/ou=groups,dc=my,dc=mydomain,dc=com?uniquemember?sub?(objectclass=groupOfUniqueNames)

(The port defaults to 389 so that could be left out as well, I
suppose.)

You could then reuse this AuthLDAPURL for all resources on your
server, adjusting only the "require ldap-group" directive for the
resource at hand.

And two rather generic hints wrt security:

Note that unless your directory server is on the same box or you
consider your network to be secure, you should not connect to your
slapd without securing at least the transport. For that you'd need to
configure your slapd to allow for TLS/SSL connections and supply
STARTTLS at the end of the LDAP URL (seperated by whitespace).
Instead of the STARTTLS parameter you could use ldaps:// for the
scheme, but note that there is no formal specification for LDAPS (in
contrast to LDAP+STARTTLS, see RFC 4513). So this is deprecated and
should not be used.
Also you really should not ever use the rootdn (I guess that is what
your cn=manager object really is) for anything else but directory
administration. Instead create another DN in your DIT and give this DN
the required permission (ACLs) to search and read group objects.
There are no limits to what the rootdn can do, ACLs are not even
evaluated for the rootdn (it's the rootdn, after all ;) so you can't
limit the power of this DN -- and it's password is in your httpd.conf
in the clear!

cheers,
-peter

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message