Previous PDF

swipe to navigate


This document introduces business challenges associated with managing groups on directories such as Active Directory or LDAP. It lays out group management strategies and describes how Hitachi ID Group Manager can help organizations to more effectively and securely manage groups.

Security groups and mail distribution lists

Most organizations rely on directories, such as Active Directory or other LDAP implementation, to identify and authenticate users, to assign users access rights and to manage e-mail distribution lists.

Groups are central to user management:

  • They are used to simplify the assignment of access rights. It is a best practice to assign privileges to groups and not to users directly. Users gain access rights through group membership.

  • Groups are also used to send e-mails to pre-defined sets of users.

  • Groups may represent organizational structure, user roles or temporary relationships, such as project assignment.

In most directories, groups can be nested, to simplify management. This means that groups can contain, among their members, other groups.

Terminology: groups versus roles

It is important to differentiate between two concepts: roles and groups. Hitachi ID Systems uses these terms as follows:

  1. Groups are objects on target systems to which users are attached and which are assigned application-specific access rights.
  2. Roles are objects that exist strictly within an IAM system. They are named collections of accounts, groups and other roles (i.e., they can be nested).
  3. Users are representations of people on the IAM system and may be linked to multiple accounts on multiple target systems.

Groups are assigned to accounts while roles are assigned to users. Groups can be assigned directly to accounts or indirectly, when a user is assigned a role that includes a group. Roles can be assigned directly to users or indirectly, when a parent role is assigned to a user.

Confusingly, within some systems and applications, groups are referred to as roles or by other names, such as privileges. For consistency, all such constructs, which exist on target systems and are assigned to accounts on those systems will be referred to as groups here.

Group management challenges

Over time, the number of groups and in some cases may surpass the number of users. As groups proliferate, they can become difficult to manage. This leads to problems, including:

  1. Stale groups or group memberships, no longer clearly linked to a business function.
  2. Empty or very small groups.
  3. Redundant groups (i.e., with identical or very similar membership).
  4. Groups with obscure descriptions.
  5. Groups with missing, invalid or inappropriate owners.
  6. Difficult access request processes, as users are unsure what to request and administrators are unsure of whether to approve or fulfill requests.

Complexity in managing large numbers of changes in group membership leads to real business problems:

  • Staffing cost associated with managing groups, often in an access administration team.

  • Long turnaround and lost productivity when users wait hours or days for required access rights.

  • Users with inappropriate access rights, as a result of process deficiencies.

Managing group objects

Groups are created, should be managed and may be deleted, like any other object in a directory. Also like other objects in a directory, they should be subject to policies and standards:

  1. Groups should always be assigned owners.
  2. Naming conventions should be used for cn, sAMAccountName or description.
  3. Groups should be placed in appropriate containers (OU).
  4. Attributes, such as group type (security versus mail distribution list) and scope (Universal, Global or Domain Local) on AD should be set appropriately.
  5. Groups may contain child groups and (conversely) be members of parent groups. These relationships must not form loops.

These are basic, technical constraints. Businesses usually have additional requirements, such as restricting who can request the creation of new groups or modification to existing groups, what kinds of groups users can request, who must approve changes to groups, who should review the configuration and membership of groups and when, etc.

Previous Next PDF