Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Using Groups to Manage Active Directory Objects

It is nearly always a good practice to aggregate users into groups based on common business functions or operational roles. Not only are groups easier to manage, but you also get a distinct performance improvement by using groups rather than individual users to control object security. It takes much longer to examine an access control list (ACL) with 3000 users on it than it does to check for a single SID that represents a group with 3000 members.

Properly creating and managing groups, then, is a critical task in Windows Server 2003. This section contains a description of each group type and guidelines of when to use each one. It also has step-by-step scenarios describing how the system uses group membership to evaluate Active Directory permissions. Understanding this process helps you architect your permissions and troubleshoot any problems.

Group Types

Here are the basic group types in Windows Server 2003:

• Machine Local.
  Defined in the Security Account Manager (SAM) of a non-domain controller. These group types exist for backward compatibility with NT and should not be used in Windows Server 2003.




• Domain Local.
  Defines a group that can have members from anywhere in the forest but can only be applied to ACLs in the local domain.




• Global.
  Defines a group that can have members only from the local domain but can be applied to ACLs anywhere in the forest.




• Universal.
  Defines a group that can have members from anywhere in the forest and can be applied to ACLs anywhere in the forest. This group type only exists in Native domains.




• Builtin.
  This is a special classification of Domain Local groups that exist for backward compatibility with NT. Local instances of these groups are contained in the SAM, similar to the way each system has a local Administrator and Guest account.

The purpose of having all these different group types is not to make system administrators turn to self-medication, although they sometimes have that effect. They exist for compatibility, flexibility, and to minimize replication traffic. Here is how they differ.

Builtin

In classic NT and in Windows Server 2003, certain groups have inherent system privileges. For example, the Backup Operators group has the necessary system permissions to transfer files to and from backup tape regardless of the file's ownership or access permissions. These groups exist in a key inside the SAM called Builtin. Figure 13.10 shows an example.

Whenever you install Windows Server 2003 (or XP, for that matter), these groups are put in place. If you upgrade Windows Server 2003 to a domain controller, the existing SAM is deleted and a new SAM is put in its place that has the default Built-In groups.

Most of the system privileges granted to these groups are located in the Secedit database, but some are buried in the operating system deeper than the Batcave under Wayne Manor. You cannot delete or rename the Built-In groups. You should only assign administrators to these groups when they need highly privileged access to a local machine. The Built-In groups in Active Directory control access to domain controllers and Active Directory components.

Machine Local Groups (SAM-Based)

Distributed management of member servers and workstations in classic NT required a two-tier solution:

• The administrator responsible for the server was placed in the Builtin group called Server Operators at the local machine. This gave the administrator the ability to manage the contents of the local SAM without granting domain privileges.




• The designated server operator would then create machine local groups and place them on the ACL of local resources such as NTFS files and folders, Registry keys, and printers. The server operator would populate these machine local groups by plucking individual users and Global groups from the domain.

Using this server management method, each server ended up with a unique set of SAM entries that had to be backed up and preserved. If the operating system disk crashed and could not be recovered from tape, the data on the other disks survived but the ACLs were invalid.

Also, enforcing a uniform management policy on a diverse set of servers often taxed inter-collegiate affability. (Try explaining to highly independent and often cantankerous administrators that it is a bad thing to have eccentric sets of local groups. Go ahead. Try it.)

Windows Server 2003 attempts to resolve this problem by doing away with the need to have Machine Local groups. In Native, any of the three domain-based group types can be placed on the ACL of a local resource. Local server operators can be delegated permission to create groups in Active Directory. It is much easier to manage a central set of groups, and you don't need to worry as much about losing access rights on local data drives.

Domain Local Groups

Domain Local groups provide an ideal vehicle for delegating permissions in Active Directory because they can only be placed on the ACL of security objects in the local domain. This permits administrators in a domain to create the groups they need without worrying that the groups will be used inappropriately by administrators in another domain in the forest.

Domain Local groups can accept members from anywhere in the forest. This permits you to delegate permissions to administrators and users in other domains. For instance, you might have a central Help Desk that you want to give permission to reset passwords throughout your enterprise. Let's say you have five domains, one for each major continent. Here's what you do:

1. Create a Domain Local group in each domain. Call it Password Operators.

2. Delegate Password Reset permissions to the Password Operators group at the root of the domain.

3. Create a Universal group in the root domain called Help Desk Operators.

4. Nest the Help Desk Operators group from the root domain into the Password Operators group in the local domains.

Universal group membership replicates throughout the forest, so you need to evaluate the need for each Universal group. In this example, the makeup of the Help Desk Operators group would not change very often, so it is acceptable to place individual users in the group. In cases where group membership changes frequently, you should evaluate alternatives that do not involve putting individual users in the Universal group.

When you shift your forest to Functionality Level 2, individual Universal group members are replicated discretely. You do not need to be as concerned with Universal group placement, but you should still ask yourself whether the AsiaPacific domain controllers really need to have a replica of a group used exclusively by the NorthAmerica domain.

Global Groups

Global groups are intended to be repositories of user accounts or computer accounts in a domain. A Global group cannot have members from other domains, but it can be placed on ACLs in any domain in the forest. For Active Directory, the appeal of Global groups is their capability to limit outside membership. You can delegate permissions to a Global group with the assurance that another administrator cannot put an outside user in the group and thereby give the user inappropriate access.

You can nest Global groups into Domain Local groups, Universal groups, and other Global groups. You can use this capability to your advantage in many situations. For example, let's say your company has a group of internal auditors who belong to the same department but log on using accounts for domains on their continent. For instance, the Kyoto auditors log on to the AsiaPacific domain and so forth.

The auditors require Audit permissions on all Active Directory objects on every domain in the forest. Auditing is a highly privileged capability and you do not want unauthorized individuals to get it. You can create an Auditors Global group in each domain and delegate Audit permissions to this group.

However, the auditors tell you they want access to the Configuration and Schema naming contexts, as well. Because these naming contexts are assigned to the root domain in the forest, you can create a Domain Local group in the root domain called Central Auditing. Delegate Audit permission for the Configuration and Schema naming contexts to this group. Making it a Domain Local group assures you that it cannot be used on resources outside the root domain.

Then, nest the Auditors Global groups from each domain into the Central Auditing group. This gives the members permission to set auditing on the objects in the affected containers. Another advantage of using a Domain Local group is that administrators in the local domains cannot see the membership of the Central Auditing group.

Universal Groups

Universal groups can only be created after shifting a domain to Native. The appeal of Universal groups is their wide scope. Universal groups can accept members from any domain in the forest and they can be placed on the ACL of any Active Directory object in any domain in the forest.

You may wonder why you would ever use Global groups when Universal groups seem so much more flexible. The next section details the differences between Global and Universal groups and why two groups are necessary in a well-architected system.

Comparison of Global Groups and Universal Groups

To understand when to use Universal and when to use Global groups, we need to take a look at the way domain controllers use Kerberos to distribute group membership information to member servers and desktops.

Every group object in Active Directory has an attribute called Member. This attribute contains the distinguished name (DN) of each group member. User objects have an attribute called MemberOf that contains a back-link to the Member attribute in the associated group object. This back-link is used solely for referential integrity. It is not used to query for group membership. Group membership is determined by searching groups in Active Directory looking for the user's DN on the membership list.

For example, if user GWBush is a member of the Presidents group, the CmdrInChief group, the Republican group, and the Texans group, then the Local Security Authority (LSA) would assemble a Privilege Access Certificate (PAC) for him containing his SID and the SIDs of all four groups. In addition, LSA would scan Active Directory to determine if each of those four groups is a member of other groups. If so, those SIDs are included in the PAC. The user then gets local access based on the cumulative permissions assigned to each nested group.

Here is where the different types of groups come into play. Domain Local and Global group membership is stored in the local Domain naming context (NC) but not in the Global Catalog (GC). In contrast, Universal group membership

is stored in the Global Catalog. This may seem like a small difference, but it has wide-ranging consequences. Here is a quick synopsis to use as a design guideline:

• Each domain controller hosts a replica of its own Domain naming context. This NC contains the membership for Domain Local groups and Global groups but not Universal groups.

  Therefore, an LDAP (Lightweight Directory Access Protocol) search for group membership directed at a standard domain controller returns only Domain Local and Global groups in the domain controller's own domain.




• A Global Catalog server hosts a full replica of its own Domain NC and a partial replica of every other Domain NC in the forest. The partial NC replicas contain the membership for Universal groups but not Domain Local groups and Global groups.

  Therefore, an LDAP search for group membership directed at a GC server returns Domain Local groups and Global groups in the GC's own domain plus Universal groups in the forest.

Any domain controller that is not itself a GC must query a GC before it can authorize access for a user. If a GC is not available, the LSA refuses to return a Kerberos ticket. Instead, it returns an Authentication Denied error with a code explaining that a Global Catalog server is not available. In Windows Server 2003, a standard DC can be configured cache copies of Universal group memberships. See Chapter 7, "Managing Active Directory Replication," for details.

Keep this difference in group membership storage in mind as you go through the following three scenarios that show how group membership affects user access permissions in Active Directory. Here are the three scenarios:

• Protecting an Active Directory object using a Global group




• Protecting an Active Directory object using a Domain Local group




• Protecting an Active Directory object using a Universal group

Protecting an Active Directory Object Using a Global Group

In the diagram in Figure 13.11, an admin contractor by the name of Eager Temp has an account in the Phoenix OU under the Company.com domain. The contractor is a member of a Global group called PhxContractors.

Because of prior incidents involving admin contractors, the PhxContractors group has been placed on the ACL of the Phoenix OU with Deny Create Child Object permissions.

Eager Temp opens AD Users and Computers, right-clicks the Phoenix OU, and selects N

EW | U

SER from the flyout menu. The system responds with an Access Denied message. The steps in this section explain why this happened.

To summarize, a user in a domain attempts to create an object in an OU in the same domain. The user belongs to a Global group that has been denied permission to create new objects under that OU. Procedure 13.3 shows the sequence of events that block the user when he attempts to create the object.

Procedure 13.3 Functional Description of User and Group Validation Within a Single Domain

1. When Eager Temp logs on to the domain, the LSA on the domain controller handling the logon request first authenticates him and then starts compiling a PAC. To do so, it queries Active Directory to get Eager's SID. (In all these discussions, keep your eye on the PAC. It's like the little girl in the red dress in

   Schindler's List . You know it's important, you just don't know why yet.)

2. LSA then queries Active Directory for any groups that have Eager's distinguished name in their Member attribute. LSA finds one group, PhxContractors. It does a quick AD lookup to getChapter 11, "Understanding Network Access Security and Kerberos," for information about Kerberos tickets and Ticket-Granting Tickets.

3. The network client at Eager's machine caches the TGT and then turns right around and uses it to get a session ticket to the domain controller. It needs this ticket to submit LDAP searches to Active Directory. The resulting ticket has a copy of the PAC from the original TGT.

4. When Eager Temp attempts to create a new user in the Phoenix OU, the AD Users and Computers console sends an Create Object command to the domain controller over a secure Remote Procedure Call (RPC) connection. This transaction contains the LDAP Kerberos ticket with its PAC payload.

5. When the domain controller gets the Create Object command and the accompanying Kerberos ticket, it extracts the PAC from the ticket and uses it to build a local access token for Eager. The LSA at the domain controller attaches this token to a thread representing the user.

6. The user's thread attempts to access Active Directory to create the User object under the Phoenix OU. The Security Reference Monitor compares the access token attached to the thread to the DACL in the security descriptor of the Phoenix OU. It discovers that the SID for user Eager Temp matches the SID associated with a Deny Create Child Object ACE. It prevents the requested action from occurring.

7. This sets a complex series of actions in motion that eventually terminate with an Access Denied message being displayed in the AD Users and Computers console at Eager Temp's workstation.

In short, the ability of a user to access objects in Active Directory depends on the PAC in the Kerberos TGT issued when the user first authenticates in the domain. The PAC contains group SIDs based on a scan of the local Domain naming context and of the Global Catalog.

Now let's expand the scope a bit and see what happens when an administrator accesses an Active Directory object in another domain. This demonstrates how the LSA and KDC in the two domains exchange group information.

Protecting an Active Directory Object Using a Domain Local Group

Figure 13.12 shows two domains, Company.com and Subsidiary.com, that share a Tree Root trust. This means they also share a common Configuration and Schema naming context. (This contrasts to a Forest trust, where two domains have a transitive Kerberos relationship but separate Configuration and Schema naming contexts.)

In this scenario, management in both companies wants the IT staff to start sharing work. To this end, an administrator in the Subsidiary domain creates a Domain Local group called Outside Admins and delegates it a set of permissions at the root of the Subsidiary domain for creating and modifying objects.

The Subsidiary administrator places a Company administrator named Ted Lightly in the Outside Admins group. (The Subsidiary admin could not have done this with a Global group because Global groups cannot accept members from outside their domain.)

Ted tests out her new permissions by attempting to create a user object in Subsidiary. This attempt succeeds. The steps in this section describe why.

To summarize, a user from a trusted domain is placed in a group in another domain. The group has limited administrative permissions in the local domain. The user is able to exercise the permissions delegated to the group. Procedure 13.4 shows the sequence of events that occurs for this to happen.

Procedure 13.4 Functional Description of User and Group Validation Across Domains Using Domain Local Groups

1. When Ted logs on to the Company domain, the LSA on her logon server builds a PAC. It first scans its copy of the Company Domain naming context. It then scans the Global Catalog. Neither scan would find Ted's membership in the Outside Admins group in the Subsidiary domain. (The GC only holds Universal group membership.)

2. Ted opens AD Users and Computers and shifts the focus to the Subsidiary domain to create a user. The network client on her machine must obtain a ticket to the DC in Subsidiary. It attempts to get one from its logon server in the Company domain.

3. The Company DC cannot fulfill the ticket request because it does not have access to the Subsidiary naming context. It accommodates the user by obtaining a TGT to the Subsidiary domain on behalf of the user and returning it to the client.

4. When the Subsidiary DC gets the TGT request, it assembles a PAC for Ted by scanning its Domain naming context and the Global Catalog looking for group memberships. It finds Ted's membership in the Outside Admins Domain Local group. It adds the SID for this group to the original PAC along with any privileges and account restrictions applicable to Ted from the Subsidiary domain.

5. The KDC service on the Subsidiary DC adds the amended PAC to Ted's TGT and delivers it to the Company DC that requested it. The Company DC forwards the TGT to the Kerberos client at Ted's machine.

6. The client submits the Subsidiary TGT to the Subsidiary DC requesting an LDAP session ticket. The LSA on the Subsidiary DC extracts the PAC from the TGT and puts it in the ticket.

7. When Ted attempts to create the new user object, the AD Users and Computers console submits the Kerberos ticket along with the Create Object command. The Subsidiary DC extracts the PAC from the ticket and uses it to build an access token for Ted.

8. The PAC contains the SID of the Outside Admins group, which has been delegated permission to create child objects in the Subsidiary domain, so the Security Reference Monitor gives Ted the green light to create the new user account.

In short, users from one domain in a forest that are members of Domain Local groups in another domain obtain the access permissions delegated to the group because the PAC is amended as part of the cross-domain authentication.

It isn't necessary to go through any of these Kerberos machinations for Global groups because users from one domain cannot be added to Global groups in another domain. Also, Domain Local groups cannot be nested into Global groups because users from trusting domains might be members of the Domain Local group.

So, the stage is set to look at the complex scenario where a user who is a member of a Global group in one domain, a group that is nested into a Universal group in another domain, tries to access an Active Directory object protected by that Universal group. Ready? Here goes.

Protecting an Active Directory Object Using a Universal Groups

In the example shown in Figure 13.13, an administrator in the Company domain took advantage of several group management features to configure permissions on an OU in the Subsidiary domain. She performed the following evolutions:

• Created Global groups in both domains to use for intra-domain administration.
  The Company administrator can create groups in the Subsidiary domain if she belongs to the Enterprise Admins group (or a group nested in the Enterprise Admins group).




• Created a Universal group in the Subsidiary domain.
  Universal groups can be created in any domain that is running in Native.




• Delegated Create Child Objects permission on the

  OU to the Universal group.
  Universal groups can be used as security principals on any object anywhere in the forest.




• Nested the Global groups from both domains into the Universal group in Subsidiary.
  A domain running in Native has extensive capabilities to nest groups.

The example in Procedure 13.5 traces the sequence of events that validates an admin from the Company domain who tries to access the Subsidiary OU. The admin belongs to the Global group in Company that is nested in the Universal group in Subsidiary.

Procedure 13.5 Functional Description of User and Group Validation Across Domains Using Universal Group

1. When the admin logs on to the Company domain, the LSA on the Company domain controller scans for group membership in the local Domain naming context and the Global Catalog. It finds the Global group membership in the local Domain naming context. It discovers that the Global group is a member of the Universal group during the GC scan.

2. LSA bundles the SIDs for these groups into the PAC that it sends to the KDC service. The KDC puts the PAC into the TGT it sends to the client.

3. When the admin opens AD Users and Computers and sets the focus to the Subsidiary domain, the network client requests a ticket to the Subsidiary domain controller from its logon server in Company.

4. The Company DC cannot fulfill the ticket request so it obtains a TGT from Subsidiary on behalf of the user.

5. The LSA on the Subsidiary DC generates a PAC for the admin by scanning its own Domain Naming Context (NC) and the contents of the Global Catalog (GC). It does not find the Global group membership in either of these locations; therefore it does not discover the Universal group that is a member of the Global group. This doesn't matter, though, because it retains the SIDs in the original PAC. It adds any local privileges and account restrictions and gives the PAC result to the KDC service.

6. The KDC returns the TGT to the client and the client uses it to get an LDAP session ticket to the Subsidiary domain controller. The LSA on the Subsidiary DC builds a local access token using the contents of the PAC. The Security Reference Monitor finds a match for the Universal group SID in the access token and the ACE on the DACL for the OU and grants access.

In short, if a user is a member of a Universal group in any domain, or a member of a group that is nested in a Universal group in any domain, the user gets the permissions assigned to that Universal group in any domain in the forest.

Summary of Group Functions

Windows Server 2003 can play Three Card Monte with Domain Local, Global, and Universal groups in ways that make W.C. Fields look like a Baptist preacher. Let's draw together the previous examples into a few general design principles:

• Protect AD objects accessed exclusively by users within a domain with Domain Local or Global groups from that domain.




• Protect AD objects accessed by users from other domains with Universal groups or with Domain Local groups that have Universal groups as members.




• Ensure that users have access to a Global Catalog server when logging on. This permits their Universal group membership to be fully evaluated. If a GC server is not available in a site, configure the standard domain controllers in the site as Universal group caching servers.




• Minimize group membership changes for Universal groups to limit forest-wide replication. This is less of a concern if you have shifted the forest to Functionality Level 2 to get discrete replication of group members.




• Don't expect to see cross-domain group membership in user properties. Expect different results when querying a GC compared to a DC.

If Thoreau were a systems administrator, he would urge us to simplify, simplify. It may seem that "simple information systems management" is an oxymoron, and you're probably right, but we can at least strive for elegance and economy. (We can also take lessons from Thoreau on burying the real costs of projects in budget reports.) Try to manage the Active Directory with as few groups as possible. Avoid using the Enterprise Admins group because its permissions are too wide sweeping. Create local OU admin groups and delegate only those permissions that the administrators require.

One final note:
When adding users or groups from one domain into a group in another domain, the system maintains referential integrity by creating a

phantom object in the local Domain naming context. This phantom object contains just a few attributes (SID, GUID, DN) from the outside security principal. Phantom objects appear in the AD Users and Computers console as entries in the Foreign Security Principals container.

If you change the distinguished name of the security principal (this happens if you move the object as well as rename it), the system must change the phantom object in the other domain to reflect the new distinguished name. Until this happens, the Member window for the group continues to show the old name. The icon is changed to one that has "gray hair" to indicate that the name is no longer valid