This chapter is from the book
This chapter is from the book
This chapter is from the book
Maintaining Trust Relationships
Configure and troubleshoot trust relationships. Considerations include cross-domain resource access and one-way trusts versus two-way trusts.
In the ideal world, all Windows NT implementations are simple, single-domain environments. However, a variety of factors cause this to not be universally true. First, in very large enterprise organizations, it might not be possible, or practical, to store all the user, group, and computer accounts in a single SAM database. Because all the domain controllers in a Windows NT domain share a single SAM, there is no way to split the domain into parts. As a result, both practical as well as absolute upper limits apply to accounts. In absolute terms, a SAM database can contain about 40,000 accounts (which counts/includes both user and computer accounts). In practical terms, a single domain should not be expected to handle many more than 10,000 accounts before it will begin to experience serious performance problems associated with the overhead necessary to maintain such a large database.
Second, a single organization may be separated into multiple domains because of political reasons. If a single parent company runs a number of smaller, independent companies, it may be desirable, or required, to maintain a set of interconnected domains, instead of trying to put them all together under one umbrella.
Third, a single organization may be separated into multiple domains because of bad planning. Many organizations evolve into Windows NT implementations as grassroots movements. If no strong central IT department holds all the departments together, each may end up implementing Windows NT for its own purposes without knowing or caring about other implementations. Often these implementations mature very quickly, and soon it is discovered that a significant amount of work would be required to merge multiple domains. Therefore, they remain separate.
Regardless of the reason, situations might arise in a Windows NT implementation where accounts from on domain may need to access resources from another. In a single-domain environment, allowing access to resources is a simple matter because all the servers in the domain have access to the same SAM and, therefore, have easy access to a source of authentication. In a multiple-domain scenario, however, this is not the case. In this scenario, a formal relationship between domains must be established to ensure that accounts from one domain can be authenticated in another domain to allow access to resources. This relationship is referred to as a trust.
In a Windows NT environment, a trust relationship defines a formal (and secure) way for DCs from different Windows NT domains to communicate with each other for the purpose of authenticating accounts. As in human relationships, a trust requires the consent of two parties, the trusted party (the one that desires access to some resource) and the trusting party (the one with resources to share). In a trust relationship, the trusting party is said to "trust" the trusted party.
Trust provides for three important features in a multidomain environment. First, it ensures that a single logon account can be used, regardless of where, across the domains, a user is logging on. This is important because it means that users do not need one account in one domain and another is another. Second, it provides users with universal resource access. This concept means that a user from one domain can access resources from another by providing the credentials established from her home domain. Third, trusts provide for centralized administration of account information by ensuring that all authentication is kept in a central place and not spread out over multiple SAM databases.
Before showing the mechanics of creating a trust, note two important points. First, trust relationships between Windows NT servers are all one-way. That is, just because one domain trusts another does not necessarily mean that it also is trusted by the other. To establish reciprocal trusts, two one-way trusts must be established.
Second, trust relationships between Windows NT servers are nontransitive. This means that if DomainA (DOMA) trusts DomainB (DOMB) and DOMB trusts DomainC (DOMC), it does not follow that DOMA trusts DOMC (see Figure 4.19).
){kind=link}
Figure 4.19. Trusts are not transitive; DOMA does not trust DOMC in this example.
These notes are important, not only for their own sake (and that of the exam) but because they are in marked contrast from the way that trusts work in a Windows 2000 forest, which are marked by two-way transitive trusts. It is also important because trusts can be established between a Windows NT domain and a Windows 2000 domain; however, the interaction between these follows the trust rules pertaining to pure Windows NT domains and not to Windows 2000 domains.
TIP
Exam Tip. Understand Trust Terminology It is very important that you understand the terminology of trusts for the exam. You may be asked to establish trusts between two domains with only the information about Trusted and Trusting to guide you. In addition, you might be asked questions in which you are told "DomainX (DOMX) trusts DomainY (DOMY)"; remember, that means that DOMX is the trusting domain and DOMY is the trusted domain. Finally, you might be given diagrams where all you have is an arrow to show the trust relationships. If that is the case, the arrow head will always point to the trusted (account) domain and away from the trusting (resource) domain (see Figure 4.20).
){kind=link}
Figure 4.20. Understanding the terminology in this diagram is essential.
The Domain Models
Although this is not a book (or an exam) that deals in depth with enterprise computing and multidomain models, you are expected to know a little of the theory behind multiple domain environments (in which trust relationships are built) because this exam is a hybrid between the old Windows NT Server and NT Enterprise exams. Microsoft identifies four different domain models. These models are not all equal in their value or desirability, but they all may be found in one form or another in enterprise environments. The models are as follows: single domain, single master domain, multiple master domain, and complete trust. In terms of desirability and simplicity, the order that they are listed is the order of desirability and simplicity. All domain environments should strive to be single domain. If that is not possible, the next best scenario is the single master, and so on.
The Single Domain Model
This model is characterized by a single domain and a lack of requirement for trust relationships. All resources are in the same domain, as are all the user, group, and computer accounts. A PDC and one or more backup domain controllers (BDCs) are present in this domain.
The Single Master Domain Model
This model is characterized by a single account domain and one or more resource domains (see Figure 4.21).
){kind=link}
Figure 4.21. The single master domain model.
In this model, all the user and group accounts are held in a single master domain. On the other hand, all the resources (printers, folders, and so forth) are in resource domains. Because the resource domains do not have user accounts, there is a need for only one-way trusts, from the resource domains to the master domain. There are no trust relationships between the resource domains because there are no user accounts in them to be trusted. In such a model, it is possible to have the computer accounts (technically a resource) be held in one or more of the resource domains. If this is done, it will reduce the size of the SAM in the master domain by one account per computer. Doing this might make it practical to have only one master domain even in a large enterprise.
The Multiple Master Domain Model
This model is characterized by two or more account domains and one or more resource domains (see Figure 4.22).
){kind=link}
Figure 4.22. The multiple master domain model.
This model is created when the number of user and group accounts is too large to be practically held in a single master domain. Note that this model adds an extra level of complexity because many more trusts are required in this model than in the single master domain model. In this model, trust relationships must be established between the resource domains and each of the account domains. In addition, one-way trusts must be established between the master domains. Because the resource domains do not have user or group accounts, there is no reason that any domain should trust them. In this model the number of trusts required can be calculated using the formulas M * (M – 1) + (R * M), where M is the number of master (account) domains and R is the number of resource domains. As you can see, as the number of domains increases, the number of trusts required increases exponentially. It is a general rule of thumb that the model with the fewest trusts is the best both for network communication and maintainability.
The Complete Trust Model
This model is characterized by multiple domains, each with both resources as well as user and group accounts (see Figure 4.23).
){kind=link}
Figure 4.23. The complete trust model.
In this model, each domain must trust every other domain. These domains arise from grassroots implementations of Windows NT domains without a unifying architecture to guide them. As a result, they are haphazard and complicated to maintain. The number of trusts in this model can be calculated using the formula N * (N – 1), where N is the number of domains in the model.
Creating Trust Relationships
To create a trust relationship between two domains, you must first decide which domain is the trusted domain (contains users) and which is the trusting domain (contains resources). Then you configure the appropriate settings on a domain controller for each of the domains. Once both are configured, the trust is established. Step by Step 4.16 configured a one-way trust between a resource domain, DOMY, and a master domain, DOMZ.
STEP BY STEP
4.16 Configuring a One-Way Trust Relationship
-
Open User Manager for Domains in the trusted domain (in this case, DOMZ).
-
From the Policies menu, choose Trust Relationships (see Figure 4.24).
-
In the Trust Relationships dialog box, click the Add button next to the Trusting Domains field.
-
In the Add Trusting Domain dialog box, type the name of the domain that trusts this domain and, if desired, configure a password to ensure that the trust is not completed by an unauthorized person; the password will have to be entered again when the other side of the trust is complete (see Figure 4.25). Click OK when this is complete.
-
In the Trust Relationships dialog box, click the Close button.
-
Open User Manager for Domains in the trusting domain (in this case, DOMY).
-
From the Policies menu, choose Trust Relationships.
-
In the Trust Relationships dialog box, click the Add button next to the Trusted Domains field.
-
In the Add Trusted Domain dialog box, type the name of the domain that this domain trusts and, if required, enter the password to complete the trust (see Figure 4.26). Click OK when this is complete.
-
In the Trust Relationships dialog box, click the Close button.
){kind=link}
Figure 4.24. Choose Trust Relationships from the Policies menu.
){kind=link}
Figure 4.25. Add a trusting domain.
){kind=link}
Figure 4.26. Add a trusted Domain.
In Step by Step 4.16, note that the trusted domain was configured first, followed by the trusting domain. You do not have to set up the trust up in this order. If you do not, however, you will not get confirmation of the trust being established. Instead, when you configure the entry for the trusted domain in the trusting domain, you will receive a message indicating that the trust could not be verified.
Maintaining Trust Relationships
Trust relationships must be maintained to continue to function. Fortunately, this maintenance is done automatically by the DCs in the respective domains. If a trust is broken, however, it will need to be reestablished to continue functioning. To be maintained, the DCs from each domain need to be able to talk to each other. Should this not be the case, the trust will be placed on hold until communication is reestablished. In two cases, however, trusts must be removed and reestablished:
-
If the name of either domain in the trust relationship is changed
-
If the trust is manually removed from either or both domains
If a trust relationship is broken because of either of these reasons, the trust must be removed from both sides and reestablished. To do this, just open User Manager for Domains, select the entry you want to remove, and click the Remove button. You will be warned that the trust is being removed.
Logon, Groups, and Resource Access in Trust Relationships
In an environment of trust, the global accounts in the trusted domain are available in the trusting domain as though they belong to that domain. In all areas where account selection is available, pull-down lists are available to choose the domain that the account you want to use. When logging on from a computer in the trusting domain, a user can choose the domain by which he wants to be authenticated. When creating groups, in the trusting domain, users or global groups from the trusted domain are available to add to global or local groups in the trusting domain. Finally, when defining resource access, global groups or global users are available to add directly to local (trusting) ACLs for file, folder, and printer access as well as the assignment of rights in the trusting domain.
Logon in a Trust Environment
In a trust environment, logon is always authenticated by a DC in the user's home domain. However, a DC from that domain does not have to be physically present in the LAN environment for this to happen. Instead, a DC from the trusting domain uses its NetLogon service to communicate over a secure channel to a DC in the trusted domain to verify authentication. This is referred to a passthrough authentication.
To log on to a trusted domain from a computer in a trusting domain, just select the trusted domain from the pull-down list at time of logon (see Figure 4.27).
){kind=link}
Figure 4.27. You can choose to log on to the local domain or a trusted domain.
Groups in a Trust Environment
Chapter 3 introduced groups as a mechanism for ensuring that resource access could be maintained in an efficient manner. Across domains, this is no different. However, it is important that global groups be created and maintained in the trusted domains for them to be available to the trusting domains. The basic methodology for granting access can be summarized in the abbreviation AGLP: Accounts are placed into Global groups, which are placed into Local groups, which are granted Permissions on local resources. In a single-domain environment, this often seems like more work than it is worth and often the creation of global groups is just bypassed. In a trust environment, however, global groups are an essential part of the process. In a trust environment, the "AG" part of the process is done in the trusted domain, whereas the "LP" part of the process is done in the trusting domain. If you want to give accountants from the trusted domain access to an accounting share on a machine in the trusting domain, for instance, you could follow a procedure like this:
-
Create user accounts for the accountants in the trusted domain. (This should already be the case.)
-
Create a global group called DomZAccountants in the trusted domain and place the accountants' user accounts into it.
-
Create a local group called Accountants on the computer in the trusting domain that the resource share is hosted on and make the DomZAccountants global group a part of that group.
-
Give the local group, Accountants, access to the share on the local computer.
To make the global group in this procedure available to the local group, you must choose the trusted domain from the pull-down list when adding members to the local group. This is demonstrated in Figure 4.28.
){kind=link}
Figure 4.28. Choose users and groups from the local domain or any trusted domain.
Permissions in a Trust Environment
As mentioned previously, once a trust relationship has been established, all the global accounts and groups from the trusted domain are available to most utilities in the trusting domain that accesses groups and accounts. (The one exception to this is the maintenance of global groups, which can contain only accounts on their local domain.) This would apply to the assignment of privileges as well as resource access through ACLs. This means that you could assign share-level as well local NTFS permissions to trusted accounts as well as assign these accounts access to printers. In addition, trusted accounts and groups can be added to built-in groups (such as Administrators) to aid in the administration of the trusting domain. In a single master domain, for instance, you would add the Domain Admins group from the trusted (account) domain to the Administrators groups in all the SAMs in the Trusting (resource) domains. This would effectively make members of the Domain Admins group from the trusted domain the administrators of every server in the trusting domains.
Step by Step 4.17 walks you through the process of making the domain administrators of a trusted domain members of the Administrators group of a trusting domain.
STEP BY STEP
4.17 Adding the Domain Administrators from Trusted Domain to a Trusting Domain
-
Open User Manager for Domains in the trusting domain (in this case, DOMY).
-
In the Groups list, locate the local Administrators group and double-click it to open the group membership list.
-
In the Local group Properties dialog box, click the Add button.
-
In the Add Users and Groups dialog box, choose DOMZ (the trusted domain) in the field labeled List Names From (see Figure 4.29). A slight pause will occur as a DC from DOMZ is contacted to verify the trust and to generate a list of users and global groups. When the list of users and groups appears, double-click the Domain Admins group and click OK to exit the dialog box.
-
In the Local Group Properties dialog box, click the OK button to exit. Notice that the Domain Admins group from DOMZ is distinguished form the Domain Admins group from DOMY (the local domain) by the prepended domain name to the trusted global group.
){kind=link}
Figure 4.29. Choose users and groups from the local domain or any trusted domain.
Case Study: Herb's Herbs
Essence of the Case
Here are the essential elements in this case:
There are three groups of machines: DCs, servers, and workstations.
All groups require both audit and configuration.
All groups allow for ongoing auditing and maintenance, which is to be scheduled if possible.
Scenario
Herb's Herbs is a small, but thriving hydroponics company. In their national company, they have 5 domain controllers, 10 member servers, and 50 Windows NT Workstations. Herb Herbalson, the president, is becoming increasingly nervous about the idea of people hacking into his machines. In addition to firewall security, which will be provided by another consultant, he wants you to audit his machines for security configuration and to devise an easy way to apply and maintain standard configurations for each of his machines.
Herb needs you to provide a solution that will allow ongoing auditing and maintenance to happen, perhaps on a schedule.
Analysis
The best way to perform this task is to use the Security Configuration Editor. You should first create security configuration templates for each of the three groups of Windows NT machines you want to configure and audit. This may be based on the built-in templates provided by Microsoft, but should be tailored to fit the specific needs of Herb's.
Each configuration (DC, server, and workstation) should have a configuration database created for it. This can be done by installing the GUI SCE on a single machine. All other machines can be audited and configured using the command-line SCE and do not require the GUI.
Because the auditing and configuration can be done using a command-line application, it can easily be scheduled using a remote product such SMS or any other application that will enable you to run applications on a schedule. By running the audit and configuration periodically, you can ensure that all machines are up to specification and stay that way. As the requirements change, the security databases will need to be modified; but these changes will immediately be implemented when the audit/configuration schedule runs.
Chapter Summary
This chapter dealt with basic security options. This included policies to control password changes (account policy) as well as user and computer configuration settings (system policy). It also included a discussion of auditing, something that should be done periodically (if not continuously) in a secure environment. This chapter also covered the Security Configuration Manager, a new feature for Service Pack 4 that enables an administrator to create configuration files (templates and databases), which will allow for the analysis and configuration of Windows NT machines to predefine specifications (and security levels). Finally, the chapter dealt with the relationship between Windows NT domains in the form of trusts. It talked about the various trust models as well as establishing trusts and securing resources in a trust environment.
KEY TERMS
- Account policy
- NTCONFIG.POL
- Trusted domain
- Trusting domain
- Trust
- System policy
- System Policy Editor
- Audit policy
- Security log
- Security Configuration Manager
- Security configuration template
- Security configuration database