Mail Distribution List
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 is designed to manage membership in existing groups and will automatically detect new groups, which can subsequently be enabled (manually or automatically) for Identity Manager management.
Group membership management can be driven by multiple processes, including:
- Automation (e.g., driven by a system of record such as HR);
- Self-service requests;
- Delegated requests;
- Access certification (event-triggered and scheduled);
- Role based access control (assign roles, automatically assign/revoke groups);
- Segregation of duties policy (between groups, roles, accounts);
- Out-of-band change detection (followed by alert or undo);
- Reporting (ad-hoc and scheduled) and more.
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. 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.