A mail distribution list (mail DL for short) is a list of identities to which an e-mail message can be sent, such that every member of the list will get a copy of the message. Mail DLs can be represented in most directories, such as LDAP servers or Active Directory.
On some directory systems, a mail DL can include both user objects and SMTP e-mail addresses. Lotus Notes is an example of a system that supports mail DLs with these two types of entries. On other directory systems, mail DLs can only contain a list of objects -- either user objects or contact objects (i.e., objects that contain contact information for a person, such as the person's SMTP address, but which cannot be used as login accounts). Active Directory is an example of this.
IAM systems can be used to manage the membership in mail DLs, just as they can be used to manage membership in security groups. In technical terms, mail DLs are almost indistinguishable from security groups, except that they cannot be used to grant security rights to their member users.
Hitachi ID Identity Manager can manage membership in existing groups and automatically detects new groups, which can subsequently be enabled (manually or automatically) for Hitachi ID Identity Manager management.
Group membership management can be driven by multiple processes, including:
- Calculated membership (typically based on identity attributes);
- Self-service and delegated requests, with or without approval;
- Access certification (event-triggered and scheduled);
- Role based assignment (assign roles, automatically assign/revoke groups in those roles);
- Segregation of duties policy (between groups, roles, accounts);
- Out-of-band change detection (followed by alert or undo);
- Reporting (ad-hoc and scheduled).
Requests for group membership are often difficult for users to articulate. Users want to access a "thing" -- a share, folder, application or screen and they may not understand that this access right is linked to a group, or what group is needed. Hitachi ID Identity Manager addresses this fundamental usability problem with a set of capabilities:
- Groups can be aggregated into roles, with more business-friendly names and descriptions. Users can be assigned roles automatically (for example, based on identity attributes) or may request roles for themselves or others.
- A search mechanism is provided for groups, allowing a requester to find a suitable group by guessing keywords in its name or description.
- A requester may be permitted to compare the group memberships of an intended recipient with the group memberships already held by a model user. The requester can then select some or all of the groups that the model has but which the recipient does not yet have.
- "Access denied" errors on key systems, such as the Windows client (when trying to open share, folders, etc.) or a SharePoint site can be intercepted. An alternate user interface is presented to the user, with a link to the appropriate group-request page.
Group membership changes can also be formulated from the perspective of groups, rather than users. i.e., "add these users to these groups" or "remove this child group from this parent group."