Active Directory Groups

In large organizations, managing the authorization permissions of hundreds or even thousands of users creates a significant problem. One way that Active Directory addresses this issue is through the use of groups that provide a way to classify users according to their roles or activities. These groups can be used as the basis for authorization permissions. In this section we explain how Active Directory groups work and how they relate to authorization in Vintela Single Sign-on for Java.

Group Types

Active Directory defines two types of groups: security groups and distribution groups. Distribution groups are mainly used for activities such as sending bulk E-mail, and do not allow permissions and audit settings to be associated with them. Security groups on the other hand are primarily designed for authorization, so are most interesting for Vintela Single Sign-on for Java. Windows does not use distribution groups internally, although they are available for use by other directory enabled applications.

Group Scopes

Each group has a "scope" which describes both its visibility to other users and applications throughout the enterprise and the types of principals that can be included in the group. Active Directory allows nested groups (groups that contain other groups), which can be nested to arbitrary levels. This is convenient, as it provides a way to hierarchically manage users, for example we can have a group for each type of manager in a department, and then create a group called "Managers" that includes all of these sub-groups. The three group scopes are listed below:

• Domain Local—visible only within a domain, and to sub-domains. Domain local groups can include any other type of group, but cannot be included in any of the other groups. Commonly, Domain local groups are used to define the groups and users allowed to access a given local resource.
  
• Global—visible throughout the enterprise, but can only include other users and groups within the same domain (or a parent domain). Global groups should be used to divide users within a domain up into categories according to their roles or job functions.
  
• Universal—visible throughout the entire enterprise. Universal groups may include both other Universal groups, and global groups from any domain in the enterprise. For reasons described below, Universal groups are expensive to use, so try to limit the number of these groups. You should use a Universal group wherever it is necessary to create a group that spans one or more domains.

Note: If you are using Active Directory in mixed mode (that is, with both Active Directory and Windows NT domains) the rules for scoping are more restrictive, and you cannot use Universal groups. See your Active Directory documentation for more details.

Groups and the Logon Process

When a Windows user logs on to an Active Directory domain, Active Directory builds a token called a Privilege Attribute Certificate (PAC). The PAC contains the list of all the groups the user is a member of, and that are visible in the login domain. This list is the "transitive closure", meaning it includes any groups which the user is a member of due to "nesting" of other groups. For example, supposing we have the following global groups which contain the users "Alice" and "Bob":

• Group1 : contains Alice, Bob
• Group2 : contains Group1
• Group3 : contains Group2

Then the PAC for Alice will contain Group1, Group2 and Group3.

Computing this group membership can take some time and Active Directory may have to query several LDAP servers to determine membership. In addition, Universal groups require a full search of the global catalog, which stores information about every Active Directory object. For this reason, the number of Universal groups should be limited to ensure that logon times do not become too long.

The PAC exists for the lifetime of the initial TGT obtained at logon time (typically 10 hours). For this reason, if a user is added to a new group, the user must log off and then log back on for this group to be used.

Groups and Vintela Single Sign-on for Java

When a user accesses an application protected with Vintela Single Sign-on for Java, Internet Explorer will contact Active Directory to obtain a service ticket for the server which it needs to contact. This service ticket will contain a PAC containing all the Universal and Global groups from the user's existing PAC, plus any Domain Local groups defined in the servers domain. Vintela Single Sign-on for Java will then use the groups defined in the PAC to authorize access to a particular resource. Because the group membership is securely authenticated in PAC, Vintela Single Sign-on for Java can trust this information. Using the PAC also saves time associated with the LDAP lookups needed to recursively resolve group membership, resulting in a much more scalable solution.