We still need some way to differentiate between roles and tenants,
otherwise subtree searches will cause problems.
In nova we handled this by assigning the owner attribute on tenants,
but no owner on roles. This allowed tenants to be found via a search
like this:
(&(objectclass=groupofnames)(owner=*))
Roles are then discovered by a search like this, using the tenant as
a base:
(objectclass=groupofnames)
Alternatively, we could add schema for roles and projects. It seems a
little overkill to add schema just to differentiate these for subtree
searches, though.
I don't love this solution, as it is not really very self documenting,
and it would be easy enough for someone to mess it up.
objectClasses: ( 2.5.6.9 NAME 'groupOfNames'
SUP top
STRUCTURAL
MUST ( cn )
MAY ( member $
businessCategory $
seeAlso $
owner $
ou $
o $
description )
Seems like what we really want is organizationalRole from
http://www.ietf.org/rfc/rfc4519.txt
3.10. 'organizationalRole'
The 'organizationalRole' object class is the basis of an entry that
represents a job, function, or position in an organization.
(Source: X.521 [X.521])
( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
With the users going in the roleOccupant field. This is in
core.ldif in the schema
