Home > Articles > Certification > Microsoft Certification

  • Print
  • + Share This
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).

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

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

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

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

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

  1. Open User Manager for Domains in the trusted domain (in this case, DOMZ).

  2. From the Policies menu, choose Trust Relationships (see Figure 4.24).

  3. Figure 4.24. Choose Trust Relationships from the Policies menu.

  4. In the Trust Relationships dialog box, click the Add button next to the Trusting Domains field.

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

  6. Figure 4.25. Add a trusting domain.

  7. In the Trust Relationships dialog box, click the Close button.

  8. Open User Manager for Domains in the trusting domain (in this case, DOMY).

  9. From the Policies menu, choose Trust Relationships.

  10. In the Trust Relationships dialog box, click the Add button next to the Trusted Domains field.

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

  12. Figure 4.26. Add a trusted Domain.

  13. In the Trust Relationships dialog box, click the Close button.

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

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:

  1. Create user accounts for the accountants in the trusted domain. (This should already be the case.)

  2. Create a global group called DomZAccountants in the trusted domain and place the accountants' user accounts into it.

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

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

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

  1. Open User Manager for Domains in the trusting domain (in this case, DOMY).

  2. In the Groups list, locate the local Administrators group and double-click it to open the group membership list.

  3. In the Local group Properties dialog box, click the Add button.

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

  5. Figure 4.29. Choose users and groups from the local domain or any trusted domain.

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

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
  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020