* Peter Schober <peter.scho...@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-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
