[Date Prev][Date Next] [Chronological] [Thread] [Top]


--On Thursday, June 26, 2003 1:34 PM -0700 Quanah Gibson-Mount <quanah@stanford.edu> wrote:

Yes, but I'm on vacation the rest of this week, so it'll be on Monday.

Actually, I got a minute, so here goes...

We basically have 3 types of principles getting access from the directory:

Users (user@stanford.edu)
WebAuthentication (webauth/FQDN@stanford.edu)
Services (service/<servicename>@stanford.edu)

Users are stored by uid in the Accounts tree (cn=accounts,dc=stanford,dc=edu)
WebAuth is stored in our Applications tree, in the webauth subtree (cn=webauth,cn=applications,dc=stanford,dc=edu)
Service is stored in our Applications tree, in the Service subtree (cn=service,cn=applications,dc=stanford,dc=edu)

In our slapd.conf file, we have the following regexp's:

sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldaps:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalNa

sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldaps:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalNa

sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth ldaps:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active

You'll notice that for users, we check against suSeasStatus=active, rather than their krb5PrincipalName. That is because we have users who are not qualified to query the openldap servers, but have Kerberos principles (we call them base accounts).

For doing dynamic acl's, we use the group concept inside openldap. For example, we have a group called webauthgeneral (cn=webauthgeneral,cn=applications,dc=stanford,dc=edu).

It has various members, like:

member: cn=www,cn=webauth,cn=applications,dc=stanford,dc=edu

Each member is an "application process", for which we created the "suApplication" objectclass.

An example entry is:

dn: cn=www,cn=Webauth,cn=applications,dc=stanford,dc=edu
objectClass: applicationProcess
objectClass: suApplication
objectClass: krb5Principal
cn: www
description: webauth access for www.stanford.edu
krb5PrincipalName: webauth/www.stanford.edu@stanford.edu
owner: <owner DN>
suAdministrator: <UID of owner>

In our slapd.acl file, we have things like:

access to attrs=uid,uidNumber,description
by group.base="cn=webauthgeneral,cn=applications,dc=stanford,dc=edu" read
by * break

We can now dynamically update another webauth application to have that access level by simply creating an entry for them in the ldap server, and adding them as a member of the webauthgeneral group. No stops/starts of the server are required.

Basically, if you have a well defined set attributes you want to give access to groups of individuals/applications, this makes it extremely trivial to do.


Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html