Directory Services Group Schemas
To retrieve the correct group information when you create queries, you must follow the directory services group schema that your organization has implemented (according to its business or network infrastructure needs). This is an overview of the two most common schemas, illustrating group layout.
Groups by Membership
This schema defines group membership by entries within user records. This schema is very common; it is often used in Active Directory and other common directory service deployments, such as Novell eDirectory. (However, the specific attributes and exact structure of your schema may be different from this example.)
The following is an example of an Active Directory deployment schema.
In this schema, membership is primarily defined by entries in user records. (For
example, the memberOf attribute contains the Distinguished Names
(DN) of the groups to which a user belongs). In Active Directory, a group’s records
also contain cross-references to its members .For example, each
member attribute in a group record contains the DN of a user
who is a member of the group.
memberOf attributes in user records is sufficient to correctly
define group membership.To retrieve the records of all members of a group, the Email Appliance begins queries at the root of the directory
tree (in this case, by setting the base DN to o=Acme). For example,
a query that retrieves the email addresses of members of the Testers group would
retrieve the values of the mail attribute of every user who has a
memberOf attribute with the following value:
dn=cn=Testers,ou=Groups,o=Acme. The returned list of email
addresses can be used to apply group policies on the page.
Groups by Organizational Unit
This schema defines group membership by a user’s location within the directory tree. This schema is less common. (However, it is occasionally used in Lotus Domino and other customizable directory service deployments.)
The following is an example of a Lotus Domino deployment schema.
In this schema, users are categorized by Organizational Units (OUs), corresponding to
regional domains, that is, company branches and cities; user records are located
within more specific OUs. The nested OUs, in turn, contain multiple levels of CNs,
corresponding to groups of users and individual users. Each CN corresponding to a
user should have an attribute that indicates his email address; this is typically
the mail attribute.
In this schema, the Email Appliance must begin its
queries at the location of the OU/group itself, since it is impossible to retrieve
only the users within that OU/group using a query with a base DN set to the root of
the directory. (In this schema, there are no cross-reference attributes such as
memberOf.) Thus, the base DN must be set to the DN of the
group, and the members of the OU/group must be all located within the group.
For example, a query that requests the email address attribute of every user who is a
member of the North America group would have the base DN ou=North
America,o=Acme, and it would retrieve the email addresses of all users
within it (Tim, Bob, Jane and Dodd). However, a query that requests the email
addresses of every user in the Toronto Testers group would have the base DN
cn=Testers,ou=Toronto,ou=North America,o=Acme, and it would
retrieve the email addresses of all users within it (in this case, only Tim
Thompson’s email address).
Similarly to the groups-by-membership schema, the returned list of email addresses can be used to apply group policies on the page.