Re: "Roles" in OpenLDAP?

[charlie derr <cderr@simons-rock.edu>]

Nikos Voutsinas wrote:
> > ......then it need only retrieve the user's entry to determine all of 
> > the groups that
> > contain the user.
>
>
> Thanks Howard for your answer.
>
> Could you please provide me with more information on how someone could 
> get all of the groups that contain the user by just retrieving the 
> user's entry? If this functionality has already been explained 
> elsewhere, I would be gradefull if you could just point me where i can 
> find this kind of infomation.
>
> Nikos Voutsinas


I'm nowhere near as smart as Howard, but I'm going to give this one a 
shot.  We use a custom schema, two stanzas of which are excerpted here:
#
# value to be used to pigeonhole user in particular groups
# i.e.  faculty, staff, student

attributetype ( 1.3.6.1.4.1.10536.2.1.2
        NAME 'groupSR'
        DESC 'Value used to associate this user with different groups'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch )

#


objectclass ( 1.3.6.1.4.1.10536.2.1.3
        NAME 'personSR'
        SUP ( top )
        AUXILIARY
        MUST ( uinSR )
        MAY ( groupSR $ bldg $ currentCourse $ completedCourse $
        uidNumber $ gidNumber $ homeDirectory $ loginShell $
        gecos $ description $ shadowLastChange $ shadowMin $
        shadowMax $ shadowWarning $ shadowInactive $
        shadowExpire $ shadowFlag $ origPassword $ genderSR $
        mailSR $ mailAliasSR $ mailMessageStoreSR $ mailQuotaSR $
        mailOrigSR $ mailAltSR $ gn  $ loginSh0 $ loginSh1) )




Now, every entry that is objectclass personSR (one account per person is 
our rule) has a potential groupSR attribute to check for group 
membership.  We've written web applications (with php) to allow specific 
access to various components based on this.  However groupSR isn't 
mentioned in any slapd ACL (though I suppose it could be if we wanted to 
restrict access to the information in LDAP based on groupSR).  The 
attribute groupSR may be empty or it may have one or more values.  This 
allows a person to be a member or one group or many or none.  I think 
it's a specific example of what was being discussed (dynamic groups).

Because we've done this in sort of a "non-standard" fashion (I just made 
up this schema a couple years ago), we're considering moving back to a 
more "standardized" organizationalRole or memberOf solution.  I'd be 
interested in the thoughts of people who feel strongly about how groups 
should "best" be implemented.

	~c




oh, and the specific example (from a simple ldapsearch) is:

cderr@box:~$ ldapsearch -x "(uid=cderr)" groupSR
version: 2

#
# filter: (uid=cderr)
# requesting: groupSR
#

# cderr, People, simons-rock, edu
dn: uid=cderr,ou=People,dc=some,dc=domain
groupSR: cms
groupSR: staff
groupSR: cax

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
cderr@box:~$