Open Stack

You use the standard Group of Names object class. The member attribute 
contains the DNs of the group members

6.8	Group of Names
The Group Of Names object class is used to define entries representing 
an unordered set of names which represent individual objects or other 
groups of names. The membership of a group is static, i.e., it is 
explicitly modified by administrative action, rather than dynamically 
determined each time the group is referred to.
The membership of a group can be reduced to a set of individual object's 
names by replacing each group with its membership. This process could be 
carried out recursively until all constituent group names have been 
eliminated, and only the names of individual objects remain.

groupOfNames  OBJECT-CLASS  ::=  {
	SUBCLASS OF	{ top }
	MUST CONTAIN	{ commonName | member }
	MAY CONTAIN	{ description |
				organizationName |
				organizationalUnitName |
				owner |
				seeAlso |
				businessCategory }
	ID			id-oc-groupOfNames }

regards

David

On 14/12/2012 18:04, Adam Young wrote:
> We are close to getting Groups done in the SQL back end, but we still
> need a schema for  LDAP, and it is not super apparent how to close the
> gap on it.
>
>
> The schema for role assignment is:
>
>  1.
>     #
>  2.
>     olcObjectClasses: ( 2.5.6.8 NAME 'organizationalRole'
>  3.
>     DESC 'RFC2256: an organizational role'
>  4.
>     SUP top STRUCTURAL
>  5.
>     MUST cn
>  6.
>     MAY ( x121Address $ registeredAddress $ destinationIndicator $
>  7.
>     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
>  8.
>     telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
>  9.
>     ! seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
> 10.
>     postOfficeBox $ postalCode $ postalAddress $
> 11.
>     physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
>
>
> And the users are in the roleOccupant field.
>
> We want to be able to make the roleOccupant included members of groups.
> But I am not sure that having both in a single field is advisable.  I
> would rather have a deliberate fields for group members.  This was what
> we did in FreeIPA, and I think it is the right approach.
>
> We could extend roleOccupant with an other object class, but there is no
> obvious class to use.
>
> We could replace roleOccupant with a different object class.  While that
> would make a painful transition, it might be preferable.  But again,
> there is no obvious replacement.
>
> We could make groups a collection underneath organizationalRoles
>
>
> Feedback is welcome.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>