• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    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.

    Figure 13.10. Regedit showing Builtin key inside the SAM hive.

    graphics/13fig10.gif

    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.

    Viewing Differences in Group Membership Lists

    You can see the effect of the differences in membership storage by performing the following little experiment:

    1. Create two different domains in the same forest in your lab. The domain controller in the first domain (the root domain of the forest) is a GC. The domain controller in the second domain is a standard DC.

    2. Shift both domains to Native.

    3. Create a Universal group in each domain.

    4. Place the Administrator account from each domain in the Universal group of the opposite domain.

    5. Open the AD Users and Computers console at the second domain controller while logged on as an administrator in the second domain.

    6. Open the Properties window for the Administrator account and select the Member Of tab. Note that the membership in the Universal group in the root domain is not listed. This is because the domain controller is not a GC and therefore has no replica of the other domain's naming context containing the Member attribute of the Universal group. Without this information, it cannot calculate the MemberOf back-link.

    7. Open the AD Users and Computers console at the first domain controller while logged on as an administrator in the root domain.

    8. Open the Properties window for the Administrator account and select the Member Of tab. Note that the membership in the Universal group of the second domain is listed. This is because the domain controller is also a GC so it can resolve the Universal group membership in the opposite domain and create the back-link.

    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.

    Figure 13.11. Active Directory diagram showing groups and managed objects.

    graphics/13fig11.gif

    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 NEW | USER 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 get the group's SID.

    3. LSA then checks for membership in any Universal groups. It scans both for Eager and for the PhxContractors group. It performs this scan by submitting an LDAP search to a Global Catalog server. If the GC query returns a Universal group membership, the LSA obtains the SID for the group and queries for any groups that contain that Universal group as a member.

    4. In this instance, user Eager Temp does not belong to any Universal groups so LSA finishes building the PAC by adding any privileges assigned to Eager along with applicable account restrictions.

    5. LSA gives the PAC to the Key Distribution Center (KDC) service, which includes it in the Authorization Data field of the Kerberos Ticket-Granting Ticket (TGT) it issues to Eager. See Chapter 11, "Understanding Network Access Security and Kerberos," for information about Kerberos tickets and Ticket-Granting Tickets.

    6. 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.

    7. 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.

    8. 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.

    9. 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.

    10. 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.)

    Figure 13.12. Two-domain forest with an administrator in one domain belonging to a group in the other domain.

    graphics/13fig12.gif

    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.

    Figure 13.13. Diagram showing an OU in one domain being accessed by an administrator from another domain who belongs to a Universal group on the OU's ACL.

    graphics/13fig13.gif

    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.

    Changing the contents of phantom objects is the job of the Infrastructure Master. Under Windows 2000, the Infrastructure Master did his chores very infrequently, so name changes often took several hours. Under Windows Server 2003, you can expect the new name to appear very quickly, depending on the replication intervals you have between sites.

    I'll grant you that this is a small improvement in the wide scope of system operations, but it does eliminate a nagging problem.

      Previous Section Next Section