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. The three group scopes are listed below:
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 you 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.
When a Microsoft 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 a “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”:
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.
When a user accesses an application protected with Single Sign-on for Java, the browser contacts Active Directory to obtain a service ticket for the server which it needs to contact, or retrieves it from the cache if it is available there.
This service ticket contains a PAC containing all the Universal and Global groups from the user's existing PAC, plus any Domain Local groups defined in the server’s domain.
Single Sign-on for Java can then use the groups defined in the PAC to authorize access to a particular resource. Because the group membership is securely authenticated in the PAC, 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 more scalable solution.
Sites represent the physical topology of your Active Directory infrastructure based on sub-nets of TCP/IP addresses. They allow for replication, redundancy and load balancing across your Active Directory deployment.
By defining sites in Active Directory, you effectively tell it what your underlying physical network looks like. This allows domain controllers to utilize the underlying network in the most efficient manner possible. It allows Active Directory to conserve bandwidth that is required for other applications within your organization.
However, sites are not related to the structure of the domain, nor do they have to maintain the same namespace — a site may span multiple domains and, conversely, a domain may span multiple sites. While no formal relationship exists between a site and a domain, a site may be given the same boundaries as a domain.
To ensure rapid and reliable network communication, Active Directory offers methods of regulating inter-sub-net, or inter-site, traffic.
The Active Directory physical structure governs when and how replication takes place. As users log on to the network, they are able to reach the closest domain controller site through the previous assignment of sub-net information. The system administrator uses the Active Directory Sites and Services snap-in to manage the topology of replication services.
Single Sign-on for Java supports replication and failover using Active Directory sites.
© ALL RIGHTS RESERVED. Feedback Conditions d’utilisation Confidentialité Cookie Preference Center
