Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Trust Relationships

The trust relationship between domains in Windows forests provides many benefits. It also creates new headaches. On the one hand, single sign-on across multiple domains makes administration of resources easier; on the other, the tight coupling between domains makes it easier for an administrator of one domain to mount an elevated privilege attack against another domain in the forest. To take advantage of the benefits and minimize the problems, you must understand the following:

The benefits of trust

Forest functional level

Group scope

Function of the Global Catalog

Benefits of Forest Trust

Trust relationships with the forest offer many benefits to users and administrators. Three major benefits are as follows:

Single sign-on

Ease of resource sharing

Forest-wide administration

Single Sign-On

No matter how many domains exist in the forest, every user needs only a single account to access any resources that she is authorized to access. A user needs to log on only one time, and wherever resources are, she needs only that account, and she doesn't need to provide credentials at any time to access the resources she is authorized to access throughout the forest. This concept extends to local logon access to desktop computer systems, no matter to which domain they are officially joined. If a user has physical access to the machine and has not otherwise been restricted, the user can log on to her assigned domain. There is no need to provide a workstation that is joined in the user's domain.

For performance, and to reduce logon over the WAN, a domain controller from different domains may be added to each site. How many DCs to add and which domain should be represented at each site will depend on the number of users who may travel to sites other than their home sites, in addition to network connectivity speeds and issues.

Single sign-on is a benefit; however, there is another side to consider. Where single sign-on does not exist, users must manage multiple accounts. Each account is necessary to provide them access to some resource. Although this is annoying and makes it more likely that passwords will be forgotten or written down where they may be observed, there is a benefit. If a user's password is cracked or discovered, an attacker only has access to the resources that can be accessed by the use of that password. All other resources remain safe. Where single sign-on is available, the account, once compromised, provides the attacker with access to every resource the user is authorized for.

While the default partitioning that exists via multiple accounts and passwords is useful, a far better system can be used to mitigate the effect of single sign-on. You can partition access to privileges and resources into normal and sensitive and assign the user additional accounts where necessary. For example, system and network administrators have extraordinary access to system- and network-wide resources and extensive privileges. These individuals also do ordinary things such as read email, compose reports, browse the Internet, and even play games. They should not do these mundane things while logged on as administrators. Instead, provide these users with two accounts: one with their full administrative privileges, and the other for less sensitive activities. To avoid the excess activity necessary to log off and on, these users can use the Secondary Logon service. While logged on as an ordinary user, they can run administrative programs under the authority of their administrative account. The Secondary Logon service is better known as Run as.

Using Runas to Mitigate the Impact of Single Sign-On

The run as command is available from the command prompt, but many programs can be run under a different identity using the Run as command from the context menu, as shown in Figure 8-6. To obtain a context menu that includes the Run as command, hold down the Shift key while right-clicking the program on the menu.

A dialog box, as shown in Figure 8-7, will prompt you to enter the alternative ID and password.

Creating Shortcuts That Use Run as

Alternatively, if you create a shortcut for the program, you can use the shortcut property pages to invoke the Run as command. When the shortcut is clicked, you will be prompted to enter a different account and its password. To create and use such a shortcut, follow these steps:

Using Run as from the command prompt is equally simple. You must provide the user domain or computer name, account, and the name of the program. After entering the command, you will be prompted to enter the account password.

User credentials follow this format:

/user:computername\account name
/user:accountname@computername
/user:domainname\accountname
/user:accountname@domainname

Program commands follow this format:

"mmc %windir%\system32\snapinname.msc" "programname parameters"

Examples:

To open the Monday.txt file in Notepad using the Companion domain and the Jsmith account, enter the following:

Runas /user:Jsmith@Companion "notepad Monday.txt"

To open Active Directory Users and Computers as Administrator, enter the following:

Runas /user:Companion\Administrator "mmc %windir%\system32\dsa.msc"

Some programs and administrative tasks cannot be run using the Run as command. For example, upgrading the operating system and configuring system parameters is not supported.

Resource Sharing

Many of the reasons for trusts include the ease of assigning resource access across domains. Because each domain has its own list of users and its own bevy of computers and resources such as database servers, file servers, print servers, and the like, a way to grant access to users from one domain to resources in another domain is useful.

Within the forest, this capability exists across all domains. Figure 8-9 illustrates this concept. Users in domain 1 can be given access to resources in domain 2, domain 3, domain 4, and in fact any domain in the forest. Conversely, all other users from any of these domains can be given access to any resources in any of the other domains. The double arrows extending back and forth between all domains symbolize this trust. The users do not gain access to these resources by default, but domain administrators within these domains can grant them that access. The ability to provide this access is determined by the permissions on the object, by membership in domain and forest administrative groups, and possibly by delegation of administrative authority. The arrangement of access is usually granted via inclusion in groups that have actually been assigned the access or privilege. The types of accounts that can be group members and where different types of groups can be granted access are covered later in the "Group Scope" section.

Forest-Wide Administration

Most domain-centric access and privilege is managed and controlled by domain administrative groups. However, forest-wide groups also exist. In addition to enterprise admins and schema admins, several computer groups exist. Cross-domain or forest-wide administration plays a role in preventing Windows 2000 and Windows Server 2003 domains from being security boundaries. Forest-wide administration and the unintended issue of unauthorized access by domain administrators into another domain are discussed in the section "Piercing Security BoundariesThe Ultimate Forest Design Issue."

Forest-wide administration, however, is important when centralized control is desired, or when it is necessary to regain control over resources.

Forest and Domain Functional Level

Functional level is a Windows Server 2003 concept that extends the Windows 2000 native and mixed mode domain concept. A Windows 2000 domain is by default in mixed mode and cannot be changed to native mode if it includes Windows NT 4.0 BDCs. If the domain contains only Windows 2000 domain controllers, it can be changed to native mode and cannot be changed back to mixed mode. The key concept to remember is that mixed mode means it is possible to have Windows NT 4.0 BDCs. Windows NT 4.0 member workstations and servers may be part of a Windows 2000 native mode forest. Windows Server 2003 domains have more choices for domain controller membership; therefore, some definition other than mixed and native mode is necessary. Windows Server 2003 changes the name "mode" to functional level.

NOTE: Why Bother to Change Mode or Functional Level?

Windows 2000 and Windows Server 2003 domains will continue to operate just fine if left in the default mode or functional level. Why change it? Mode- and functional-level changes make sense because they offer additional functionality.

Windows Server 2003 forests can contain Windows 2000 domains. In addition, Windows Server 2003 domains can contain Windows NT 4.0, Windows 2000, and Windows Server 2003 domain controllers. However, some advanced features of Windows Server 2003 require a domain to consist of only Windows Server 2003 domains. Other features require the entire forest to be Windows NT 4.0 and Windows 2000 domain controller-free. (Windows 2000 and Windows NT 4.0 member servers may exist in these domains.) The absence or presence of Windows Server 2003 purity is referred to as forest functional level.

New and wonderful functionality is available when Windows Server 2003 domains can be raised to an advanced functional level. However, you should note that even before this occurs, many Windows Server 2003 advantages are available. For example, Universal Group Caching, replica from media, No GC full synchronization, application partitions, DNS in an application partition, administrative tool improvement, reset Restore Mode Password online, reduce storage requirements, and object quotas do not require Windows Server 2003 functional level.

Functional Levels

Each domain or forest functional level has specific qualifications that must be met before it can be assigned, and each level delivers different advantages. Domain levels are assigned domain-by-domain. Domain levels and the types of domain controllers they support are as follows:

Windows 2000 Mixed
Windows NT 4.0, Windows 2000, and Windows Server 2003 domain controllers.

Windows 2000 Native
Windows 2000 and Windows Server 2003 DCs only.

Windows Server 2003 Interim
Windows NT 4.0 and Windows Server 2003 DCs only.

Windows Server 2003
Windows Server 2003 DCs only.

Forest functional levels map to the entire forest and are as follows:

Windows 2000
Windows NT 4.0, Windows 2000, and Windows Server 2003 DCs.

Windows Server 2003 Interim
Windows NT 4.0 and Windows Server 2003 DCs only.

Windows Server 2003
Windows Server 2003 DCs only.

NOTE: A Reminder

Operating system requirements for domain or forest functional level apply only to domain controllers. No matter the domain or forest functional level, the operating system of member servers and workstations is unimportant to functional level.

Functionality

Many of the new functions available at a higher functional level offer increased security functionality. Table 8-1 lists domain features and identifies the domain functional level necessary. Table 8-2 lists forest-wide features and the forest functionality required.

Raising Functional Level

Administrators can manually change domain and forest functional levels when the operating system conditions are met. Windows will not make the change automatically. Once a level has been changed, you cannot return the domain or the forest to a previous level. By default, when a Windows Server 2003 domain controller is deployed, it operates at the lowest functional level: Windows 2000 mixed. If there are no Windows NT 4.0 or Windows 2000 DCs, and there will never be a need to add them, the functional levels can be changed to Windows Server 2003. If a Windows NT 4.0 DC is upgraded to Windows Server 2003, then the Windows Server 2003 Interim can be set for the domain and the forest.

Before attempting to change domain or forest functional level, you should review your current domains and document the operating system of all domain controllers in each domain. You should also review the additional functionality that you will achieve and determine how important that functionality is to your organization. Remember: There is no need to immediately change a functional level just because the current domain controller operating system will enable it. You cannot reduce the functional level of your domain or forest should you want to do so in the future.

Raising Domain Functional Level

When the first Windows Server 2003 domain controller is introduced into a Windows 2000 or Windows NT 4.0 domain, the domain functional level is automatically set at Windows 2000 mixed. In a mixed domain with both Windows NT 4.0 and Windows Server 2003 domain controllers, the domain functional level can be changed to Windows Server 2003 Interim level. If all domain controllers in the domain are Windows 2000 or Windows Server 2003, the domain functionality can be changed to Windows 2000 native. When all domain controllers are Windows Server 2003, the domain functional level can be changed to Windows Server 2003. To change domain functional level, you must be a member of the Domain Administrators group.

Changing domain or forest functional level is irreversible. Once the level is raised, you cannot go back. Note that an attempt to raise the forest level while Windows NT 4.0 DCs are present will not be blocked; however, replication to all Windows NT 4.0 domain controllers will stop. Best practices include identification of the functional level of all DCs prior to changing the level. You should also ensure that replication is occurring properly throughout the forest (use Repadmin and Replmon to verify) and make a system state backup of at least two DCs from each domain in the forest.

Strategies for Raising Forest Functional Level

You can approach the raising of forest functional level in different ways. Possibilities are as follows:

Raise domains to Windows 2000 native level one at a time; then raise forest to Windows Server 2003. (When the forest is raised to Windows Server 2003 level, Windows 2000 native level domains will be automatically moved to Windows Server 2003 level.)

Increase domains to Windows Server 2003 level one at a time; then increase the forest level to Windows Server 2003.

Either strategy will work, and each has advantages and disadvantages. In the first example, you avoid revisiting each domain because the movement to Windows Server 2003 domain level is automatic. In the second option, however, you may be able to reap some benefits by having a domain at Windows Server 2003 level, even though the entire forest is not. Review Tables 8-1 and 8-2 for some ideas as to what those benefits are.

The main advantages to Windows Server 2003 functional level are Schema redefine, cross-forest trusts, and more replication improvements.

Raising the Functional Level to Windows Server 2003 Interim

Raising the functional level to Windows Server 2003 Interim improves replication and allows groups to contain more than 5,000 members per group. You can raise the functional level during an upgrade of the Windows NT 4.0 PDC to be the first DC in a Windows Server 2003 forest. You can also configure the forest functional level prior to the upgrade or afterward by using an LDAP tool.

NOTE: Other Methods for Changing Domain Functional Level

You can also use ldp.exe and adsiedit.msc to view and raise the domain and forest functional level. To learn how, see Knowledge Base article 322692 "HOW TO: Raise Domain and Forest Functional Levels in Windows Server 2003"at http://support.microsoft.com/default.aspx?scid=kb;en-us;322692.

Raising the Domain Level to Windows 2000 Native or Windows Server 2003

You cannot have Windows NT 4.0 DCs in either of these domain functional levels. Before raising the domain functional level, you should make sure you have no Windows NT 4.0 DCs in the domain. In a large domain, especially one with a remote site, this may not be an easy chore. To determine if any Windows NT 4.0 domain controllers exist in a domain, you can use an LDAP query.

(&(objectClass=computer)(operatingSystemVersion=4*) (userAccountControl:1.2.840.113.556.1
.4.803:=8192))

If no NT 4.0 domain controllers are located, then it is okay to proceed with raising the domain functional level.

To raise the domain functional level to Windows Server 2000 or Windows Server 2003, follow these steps:

Raising Forest Functional Level

Raising the forest functional level is also a matter of ensuring that conditions are met for forest member domains, and then following a simple procedure. Once the forest level has been changed, it cannot be returned to its previous status. To change the forest functional level, follow these steps:

Group Scope

Changing the forest functional level to Windows 2000 or Windows Server 2003 adds the Universal group type and changes the meaning of group scope. Group scope defines which groups and users can be a group member and where groups can be used to grant rights and access to resources. Group scopes are defined in Table 8-3.

The meaning of group scope changes with the functional level. Table 8-4 provides examples.

Group Types

Two types of groups exist: security groups and distribution groups. Security groups are groups that can be granted access to objects by adding their SID to the discretional access control list (DACL). Distribution groups are used solely for creating email lists for use by Exchange Server but could be utilized by other server applications. Distribution groups cannot be used as security groups. However, security groups can also be used as email lists. Best practices indicate that distribution groups should only be created if a security group that matches its requirements does not exist.

Enterprise Groups

Two groups that have extended administrative rights throughout the forest are Enterprise Admins and Schema Admins. These groups are created in the forest root domain. In a Windows Server 2000 Mixed Functional Level domain, these groups are Global Groups. By default, the Administrator account of the root forest domain is a member of both of these groups. Because these groups have administrative roles throughout the entire forest, their membership should be carefully considered. The Enterprise Admins group, by default, is given membership in the Domain Admins group of every domain and thus has far-reaching administrative privileges. Membership in Schema Admins is necessary to modify the schema. Because changing the schema should not be undertaken unless absolutely necessary and typically must be reviewed extensively before application, best practices indicate that the membership of the Schema Admins group should be empty. If a Schema Admin is necessary, an administrative account can be temporarily added.

Global Catalog Function

Domain-specific object information is replicated among all domain controllers in a domain. Only some of the characteristics of a domain object are replicated to other domains. This information is only stored on domain controllers that have been designated as Global Catalog servers (GCs). Global Catalog servers maintain a partial replica of domain information from every domain in the forest. Where multiple global catalog servers are present in a domain, the information is maintained on all GCs. The GC provides the following functionality:

Enables user searches across all domains in the forest, such as using the Start, Search, Other Search Options, Find People or Printers functionality.

Supplies Universal Group membership information in multiple domain environments. This information is necessary during logon in Windows 2000 native and Windows Server 2003 domains.

Provides user principal name authentication. If Jeff Smith, a user in the east.newyork.nomoore.com domain, logs on from a workstation in the west.newyork.nomore.com domain using the UPN Jsmith@east.newyork.nomore.com, the DCs in the west.newyork.nomore.com domain will not be able to find the account and will contact the GC to complete the process.

Validates object references. A cross-domain object reference is a reference from an object in one domain to an object in another. If, for example, a reference to an OU in the west.newyork.nomoore. com domain is made by some activity on the east.newyork. nomoore.com domain, it can be checked to see if such an OU exists.

The GC data is not unique; it represents partial information from each domain. The information is stored in the GC because specific attributes are identified in the object class in the Active Directory Schema. Some attributes are marked by default, and a member of the Schema Admins group can add additional attributes by modifying the Schema properties of the attribute.

WARNING: Modify Schema Attributes with Caution

This feature should be used with caution. If the forest functional level is not Windows Server 2003, modifying an attribute will cause the entire global catalog attribute set (not just the new attributes you have selected) to replicate, which can cause a temporary performance issue.

In addition to providing forest-wide information, the GC plays a unique role in relationship to Universal Groups and User logon. During logon, the Local Security Authority must create a security token. This token includes the security identifiers (SIDs) of the user and groups she is a member of. The token is used when the user attempts to access resources. Starting with Windows 2000, a new type of group, the Universal group, can be used to grant permissions through the forest and can contain as members users and groups from the forest. Membership in Universal groups must also be included in the security token. However, because the membership information may include users and groups from all over the forest, instead of visiting each domain in the forest, the logon process obtains the information from the GC. To do so, the DC authenticating the user connects to the GC. In a single domain forest, all DCs contain the same information, and there is no need to access the GC. If the functional level of the Windows Server 2003 domain is Windows 2000 mixed, no Universal groups can be created, and there is no reason to contact the GC. However, in a multidomain, Windows 2000 native mode, or Windows Server 2003 forest, if the GC is not accessible, the account is not the built-in Administrator account, and cached credentials are not available, the user will be denied logon. Universal group enumeration is also necessary for computer accounts and occurs during computer startup.

The problem of GC access across the WAN is often resolved in Windows 2000 domains by adding a DC and GC in every physical location. Likewise, to improve performance, additional GCs can be created. However, in both cases, adding GCs increases the replication traffic.

Configure Additional GCs

By default, the first domain controller in a Windows Server 2003 domain is automatically made a GC. If additional GCs are necessary, they can be created. To do so, follow these steps:

Use Global Catalog Caching

Because the global catalog is used to enumerate membership in Universal groups during user logon, it is often good practice to include a GC in each site. This way, it is not necessary to use a WAN connection to authenticate a user. In many cases, a local DC from the user's domain is already present at the site and can also be used for this purpose. (If no DC is present, users are already using the WAN connection for authentication.) However, adding the GC role to a local DC increases replication traffic across the WAN and could necessitate a hardware upgrade. This may not be acceptable if replication is already heavy or if the connection speed is slow.

Some GC Communications Cannot Use Universal Group Caching

Universal Group Caching will not help if applications are querying the GC for information on port 3268. These queries will still need to access a GC directly. If a site requires this type of GC communications, placing a GC in the site is still the best solution.

Windows Server 2003 solves this dilemma by providing the option to locally cache Universal group membership on the DC. Once membership information is cached, user logon does not require a WAN connection to a GC or the existence of a local GC. The Universal group membership information will be periodically refreshed (by default every 8 hours). Caching refresh is limited to 500 Universal group memberships at one time. After Universal group membership caching is enabled, users should experience faster logon times.

Enabling Universal Group Membership Caching

Universal group membership caching must be enabled at all DCs in the site: