Indirect or alternate criteria for list membership

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


As discussed in Defining membership of large lists, the MTA's normal interpretation of the uniqueMember LDAP attribute (more precisely, the attribute named by the ldap_group_dn MTA option) involves expanding the value of the uniqueMember attribute via the URL template set by the group_dn_template MTA option, which by default is


ldap:///$A??sub?(mail=*) 

(meaning that the $A substitution inserts the uniqueMember value), so that by default, uniqueMember values are interpreted as specifying a DN location in the DIT: all e-mail addresses under that location are considered to have been specified (be members).

This sort of indirect, additional-step, expansion of an LDAP attribute value turns out to be potentially useful for alternate approaches for membership definition. In order not to interfere with the "normal" handling of uniqueMember DN values for list membership, in Messaging Server 7.0.5 the MTA option ldap_group_dn2 and the mapping table GROUP_TEMPLATES were introduced. ldap_group_dn2 can be used to specify the name of an LDAP attribute which will then be processed similarly to the ldap_group_dn (uniqueMember) attribute---in particular, by default values of the LDAP attribute named by ldap_group_dn2 are expanded via the group_dn_template URL template just like ldap_group_dn values. But the real usefulness of ldap_group_dn2 tends to be when its use is combined with use of the GROUP_TEMPLATES mapping table.

The GROUP_TEMPLATES mapping table provides a way to specify different URL expansion templates for differently named LDAP attributes (such as different templates for the attribute named by ldap_group_dn vs. the attributes named by ldap_group_dn2), or even for different values of such LDAP attributes. When a GROUP_TEMPLATES mapping table exists, it will be probed each time a group has an LDAP attribute named by either of the ldap_group_dn or ldap_group_dn2 MTA options. The probe form is:

object-classes|attribute-name|attribute-value

where object-classes is a plus-separated list of the object classes associated with the current LDAP entry, (see the ldap_group_object_classes MTA option), attribute-name is the name of the group "DN" attribute being expanded (i.e., the LDAP attribute name specified for either ldap_group_dn or ldap_group_dn2), and attribute-value is that attribute's current value.

If the mapping sets the $Y output flag, then the mapping output string will be used as the template for this attribute's expansion in place of using the value of group_dn_template as the template. If the mapping sets the $N output flag, then the attribute will be silently ignored.

So now that the facilities have been explained, how could they actually be used? Well, one sort of usage might be where groups/lists are defined not so much by the group/list entry pointing to (that is, listing) the members, but rather where each user entry specifies the groups/lists of which the user is a member, referring to some group/list ID. For instance, suppose group/list entries have an LDAP attribute listID whose value is some string unique to that group/list. Then suppose further that user entries mark which groups/lists the user belongs to by having a memberOf attribute that contains a valid listID value. Defining group/list membership in this new way, while still allowing "traditional" uniqueMember membership definitions, can be achieved by configuring the MTA with an option:


msconfig> set mta.ldap_groupdn listID

and mapping table:


GROUP_TEMPLATES 
 
! Normal use of ldap_group_dn attribute uniqueMember 
  *|uniqueMember|*  $Yldap:///$$A?mail?sub?(mail=*) 
! Find users who have a memberOf attribute set to the value of the group's 
! listID attribute 
  *|listID|*      $Yldap:///$$B??sub?(memberOf=$$A) 
 

where here note $B is the substitution sequence meaning to substitute in the base of the user/group portion of the DIT (the ldap_user_root MTA option's value), and where the $A "Address" substitution means, in this context, the value of the currently used LDAP attribute (so the value of, respectively, the uniqueMember or listID attribute in the respective mapping table entries matching those attribute names). Then to make use of this type of group/list definition, provision groups and users in the directory along the lines of:

group1-entry
listID: group123 
 
... 
 
group2-entry
listID: groupXYZ 
 
... 
 
user1-entry
memberOf: group123 
memberOf: groupXYZ 
... 

See also: