by Don Benage
You were introduced to domains in Chapter 4, "Enterprise Planning and Implementation," but the details of the directory services provided by Windows NT Server have not yet been presented. This chapter introduces you to the concept of a directory service and the functionality it provides. The specific characteristics of the Windows NT directory services are discussed, along with the different domain models you can implement to best address the needs of your organization. Several ways to configure your organization's servers are presented. These methods all involve the use of multiple domains, and provide different features in terms of security and control.
After a thorough exploration of the current Windows NT Server directory services and the use of domains, this chapter outlines the future development of Active Directory and the Open Directory Services Interface (ODSI). Microsoft has joined with other industry partners and the Internet community in developing solutions to the limitations in current directory services. The current state of that effort and specific product plans are discussed.
In a large computer network with many shared resources and users, one of the biggest challenges is finding the resources (printers, shared data, applications, an so on) that you need. It can also be a challenge to find a particular user you would like to communicate with using e-mail or another tool, such as an online chat utility. In the real world, you have many directories to help you find things. The yellow pages and white pages published by telephone companies are probably the most widely used directories, but there are many others. Similar services are provided on computer networks, but as you will learn in this chapter, they are still evolving. The services available today provide the most important features required, but fall short of an ideal solution in a number of ways.
The domain architecture of Windows NT Server provides the basis for the current directory services on a Windows NT network. The basics of using a single domain have already been outlined in Chapter 4, "Enterprise Planning and Implementation." In that chapter you learned the difference between a workgroup and a domain, and how domains provided the capability to use a single user ID and password to access resources anywhere in the domain. In addition, you learned how to create a trust relationship between two domains.
By using trust relationships, you can implement a variety of domain models that enable you to manage even very large networks effectively. There is not a single correct way to set up a large enterprise. The best choices for you will depend on the nature of your organization, its culture, and the type of work environment you want to create. Windows NT Server enables you to configure your domains so that a very rigid structure with tight security controls is present, or you can set up your domains so that a relativity open environment with a few loose controls is provided. You can have a single centrally located group in control, or delegate a great deal of control to individual departments or locations.
There are a number of features that are provided by a directory service. Some of the features are geared toward the user community and others are targeted at the administrators of the network. The features of a directory service are usually accessed through a variety of applications. Administrators can use specialized tools to add users or other resources to a directory. In addition to logging on to the network (which accesses a directory of valid user IDs and passwords) network users need simple tools that have been directory enabled. In other words, the user community should not have to be concerned about the details of a directory service that may be important to administrators.
The users of a large network must be authenticated. It is critical to restrict access to network resources to a limited population: only those users who are authorized by the organization that owns and operates the network. Ideally, a single user ID and password provides the credentials needed to access all the resources that the user needs. In the past, it was common for users to need several user IDs and passwords for different systems and, in fact, there are many networks currently in operation for which this is still the case. Older network operating systems (e.g., NetWare 3.x) generally required a separate login for each server that a user accessed. Applications, such as e-mail or databases, can also have separate passwords.
Besides antagonizing users, this can actually lead to reduced security. Because the user community is frustrated with remembering too many passwords, especially if they must regularly be changed, users tend to write them down and leave them in places that are accessible to hackers or other unauthorized users. A centralized directory service that provides single-logon access to a wide range of resources is, therefore, an important component of network security. This feature is provided by Windows NT Server and is one of the strengths of the BackOffice family. The way this is implemented is explored in the next section.
A directory service can sometimes provide authentication for a collection of heterogeneous resources in addition to its own native facilities. This kind of integration among products from different vendors was extremely rare in the past, but it is a feature that is becoming more common in response to the demands of network buyers and users.
Network users also need assistance locating resources. In a large network, it can be difficult to find the printer down the hall or the shareware utilities directory. Some means of quickly and easily locating this type of resource is needed. It is also desirable to facilitate the process of finding a particular user on an e-mail system or other form of electronic communication. Even if you know a person's name, company, street address, and phone number, you cannot to send that person e-mail without an e-mail address. The converse situation is also true: An e-mail address is of no use in sending a letter or package via conventional mail or in making a phone call.
A directory service is ideally suited to capture this type of information and provide users with an easily accessible means of looking it up. It can also facilitate sharing this information with coworkers. A sophisticated directory service might even provide a specific subset of its information to the general public. As you will see in the next section, Windows NT Server provides some of this functionality, but benefits from some improvements that are being designed into the next generation of tools and services.
A complete directory service also makes its data available to application developers, both as a repository for application specific information (if appropriate) and as a source for information on people, computers, and other network resources. This use of directory services is an area that everyone agrees is important, but causes the most difficulties in its implementation. To be useful, the information stored by the directory service must have some limitations. It can't become a dumping ground for every piece of ad hoc information that arises. On the other hand, it should store information of a generic nature pertaining to a broad range of users. Good judgment is required in deciding what should be added to the directory database.
Now that you have a feel for the sort of information and features that might be implemented in a directory service, the specific features of Windows NT Server and the other members of the BackOffice family are explored.
The security in a Windows NT Server environment begins with a user logon. This can be done from a desktop computer running a variety of operating systems, as follows:
NOTE: The functionality provided for Microsoft's own operating systems is more complete than that which is provided for competitive operating systems. For example, Macintosh clients cannot execute logon scripts stored on a Windows NT server.
When a user logs on, the user ID and password is checked against the user account database. A sophisticated protocol is used so that an attacker with the capability to capture the network traffic associated with logging on will not be able to use this information to gain access. If the user ID and password are valid, and if any restrictions regarding time of day, day of the week, or workstations that may be used have been met, the user is authenticated and the logon process is completed. If the ID/password combination are not valid, another opportunity to log on is typically provided. It is possible to disable the account if a set number of invalid logon attempts are made.
Once connected to the network, a user can optionally connect to other shared resources. In this situation an access control list (ACL) for the resource is checked to see if the user has been granted any permissions. Different access levels can be set for different users and groups of users. In fact, it is desirable to use groups wherever possible, and avoid assigning permissions to individual users. This is discussed more fully in the next section.
The basic capability to authenticate users and to regulate access to network resources is the foundation upon which all of the more sophisticated security features are based. This capability is critical in light of the increasing amount of sensitive information that is stored on desktop computers. The next section addresses the use of domains to create a centralized user account database and the use of trust relationships for creating security architectures capable of supporting networks with tens of thousands of users.
It is possible to set up each Windows NT Server as a stand-alone entity with a completely separate user account database. This creates some obvious problemsóespecially in a large network environmentóand so it is rarely done in practice. Most often, the servers are set up to create a domain.
Each domain has a single primary domain controller (PDC). There may also be one or more backup domain controllers (BDCs). In addition, there is a role in the domain known simply as server. Each computer running Windows NT Server must take on one of these roles if it is to be included in the domain. The role is determined during installation of the operating system. It is possible to promote a BDC to become the PDC, which automatically demotes the current PDC if it is operational and connected to the network. A BDC can also be promoted if the currently designated PDC has experienced a failure. A repaired PDC that is reconnected to a network with another PDC in operation can be demoted to a BDC. A server cannot be converted to a domain controller without reinstalling the operating system.
PDCs and BDCs cannot be added to, or removed from, a domain without reinstalling the operating system. In other words, a domain controller in domain A cannot be moved to domain B. Nor can you take several domain controllers from domain A and re-name their domain name to form a new domain. It is, however, possible to rename an entire domain. The domain name can be changed on every server in the domain, although this can be a difficult task to accomplish and almost always leads to trouble if the domain is larger than a two or three servers. For example, when this operation is performed, it usually takes some time before network browsing and searching for network resources function quickly and properly, and some maintenance may need to be done on the Windows Internet Name Service (WINS) database if you are using WINS for name resolution. There is no other scenario in which a domain controller can be moved to a different domain.
A server, on the other hand, can be moved from one domain to another with relative ease simply by adding it to the new domain using Server Manager, and changing its domain affiliation in its network properties dialog box. Of course, you should also remove its name from the old domain to avoid confusion. This capability makes the server role ideal for SQL Server database servers and other BackOffice family servers that may need to be moved.
The PDC is the repository of the main copy of the user account database. All changes to the database must be applied to this master copy. Backup copies of the account database are kept on each BDC. As changes are applied to the PDC, they are automatically replicated to the BDCs. This is done for two main reasons: to provide a level of fault tolerance (online backup) and to spread the load of authenticating users among multiple servers. Both PDCs and BDCs validate user logons. Computers that are set up as servers do not validate logons, but any shared resources on these computers can be assigned permissions for the users and groups in the domain.
A single domain (set up on appropriate computer hardware) is capable of managing up to 40,000 accounts. These accounts can be individual users, groups, or machine accounts. (See the following Note.) Table 8.1 summarizes Microsoft's recommendations for the required number of BDCs (Intel 486 class machines running at 66 MHz) based on the number of network accounts on the network.
| Number of Accounts | Number of BDCs |
| 1ñ9 | 0 or 1 |
| 10ñ2,000 | 1 |
| 4,000 | 2 |
| 6,000 | 3 |
| 10,000 | 5 |
| 20,000 | 10 |
| 30,000 | 15 |
NOTE: Computers running Windows NT Server or Windows NT Workstation each require a unique machine account in the domain in order to participate in domain security. These must be added to the user and group accounts when calculating the size of the account database.
These numbers should be used only as a guideline. The numbers are based on the following rule of thumb:
When the number of accounts is below 2,000, you should use your judgment and attempt to gauge the activity level and load that will be placed on the servers. For example, do all the users on the network begin work at the same time, or are there groups of users (corresponding to work shifts perhaps) that spread the load more evenly? Are the users on your network power users with a demanding appetite for network resources, or are they occasional users of network resources?
In general, validating logons is an activity that benefits from network bandwidth and domain controllers with fast network adapters, plenty of RAM, and fast processors. Disk space and speed are not very important for this activity.
Security policies are established for an entire domain. Password restrictions (e.g., minimum length, aging, and history) and account lockout settings (e.g., the number of bad logons are tolerated before an account is locked) are created and maintained with User Manager for Domains. This security policy information and the user account database are stored on the PDC.
At regular intervals the user account database and the security policy settings are replicated to the BDCs. The replication occurs automatically without any setup required on the part of network administrators. The design of the replication process attempts to strike a balance between timeliness of information and keeping the network traffic associated with this process to a minimum. In a network with many BDCs, the replication process targets a configurable number of BDCs rather than all of them at once. Only 2K is required to set up the transmission session, and a maximum of 1K per account is sent during the actual transmission.
Each update transmission is serialized. If a particular BDC is out of service for some time and misses more than 2,000 updates, the entire database will be sent in bulk to the BDC when it is once again on the network. As long as the BDCs are active, only the changes to the database are sent. An administrator can manually initiate a synchronization of the entire domain if necessary using either the Server Manager or by entering the following command from the command line:
NET ACCOUNTS /SYNC
To use the Server Manager, highlight the PDC and choose Computer,
Synchronize Entire Domain.
For the replication process to work effectively, it is important that the system clocks on all servers have the same time. They must be within at least ten minutes of one another, or the process will not function properly. You can cause a BDC to synchronize its clock with the PDC by executing the following command:
NET TIME /DOMAIN
This command can be run on a regularly scheduled basis using the AT service provided with Windows NT so that the domain controllers are kept on the same time even if there are slight variations in their operation. In order to use this facility, the schedule service must be running on the BDCs. The following command, for example, would cause the NET TIME command to be run every Monday one minute after midnight:
AT 00:01 /EVERY:MONDAY "NET TIME /DOMAIN"
There are reasons that a single domain may not be sufficient for an organization's needs. Some are large enough that 40,000 accounts will not accommodate their entire account database, but there are other reasons as well. By dividing the enterprise into multiple domains, you can delegate the control of account creation and resource management to the people and locations you want to have this control.
Multiple domain environments are created by establishing trust relationships. A trust relationship allows the accounts from one domain to be assigned access permissions for resources in another domain. For example, if domain B trusts domain A, permissions can be assigned allowing users in domain A to use shared data on a server in domain B (see Figure 8.1).
A simple one-way trust relationship between two domains allows accounts from one domain to be assigned access permissions in the other.
Through the use of trust relationships, a variety of domain models can be implemented. The different domain models provide capabilities that match various organizational goals and cultures. For example, you can decide whether control over network user accounts should be in the hands of a single, centralized group or distributed to a number of autonomous groups, each with its own span of control. The primary domain models that are in use are described in the next section.
As you review the different domain models and consider the architecture that would best meet the needs of your organization, it is important to remember a few key points about trust relationships, as follows:
To establish a trust relationship between two domains, you must first decide which is to be the trusting domain and which the trusted domain. In general, accounts are created in the trusted domain and resources are located in the trusting domain. Review the preceding material if you are still not sure. You must be a Domain Admin of both domains, or have the cooperation of a Domain Admin for any domains for which you do not have such privileges. If another person is involved, agree beforehand on the password that will be used, and a time by which the first part of the following process (permitting to trust) will have been completed. Then, follow this procedure:
Now the complimentary procedure must be carried out for the other domain. You
must log off and log on using a different workstation that is a member of the new
domain, because a single workstation can't simultaneously participate in two domains
without a trust relationship. Alternatively, you can use a simple method to establish
credentials in the second domain. Using the Explorer, you can map a network drive
to an administrative share (e.g., C$) on the PDC in the other domain and use the
Connect As text box to enter a Domain Admin user ID from the other
domain in the form <domain>/<account>. You will be prompted for the password
that corresponds to this account and then a connection will be made establishing
you as a Domain Admin for the second domain. You should now be able to choose User,
Select Domain from the menu in User Manager for Domains to complete
the process.
There are several different domain models from which you can choose. Each has its strengths, and there are particular environments and situations that are best addressed with a certain model. The following are the primary domain models that are often used:
The single master domain has the obvious attraction of being simple to understand and implement. As previously mentioned, a single domain is capable of handling up to 40,000 accounts. Unless you need to provide multiple areas of account control or need more accounts than a single domain can accommodate, you should keep things simple and implement a single domain.
A single master domain allows for centralized control of accounts and resources. If you would like to delegate some level of administrative capability, you can use the operator groups to divide responsibilities. There are four main operator groups, as follows:
These groups enable you to designate who can help people who have forgotten their passwords, create tape backups, resolve problems with print queues, or reconfigure servers. The exact capabilities of these various groups goes much further than this simple list suggests, but the basic idea is that you divide responsibility by function rather than by geographical area or a physical group of machines.
NOTE: You should designate at least two Domain Admins, even on a very small network, to allow for backup in the event of catastrophe. In small organizations, you may have only one active network administrator, but you should still make sure that another person (such as the owner or accountant) has a user ID and password that are in the Domain Admin group. This should not be the account they use every day for normal activity.On a large network, the number of Domain Admins should be limited to those people who absolutely need to have such privileges. It is a mistake to hand out this capability willy-nilly when a combination of operator roles would generally suffice.
You still need to do some planning if you are implementing on a wide area network (WAN) to make sure that logon validations are handled promptly, and can be accommodated if a WAN link is down. These issues are discussed in the next section, "Domain Planning Considerations."
The single master domain model enables you to further delegate control. The most common implementation uses the one master domain as the repository for all user accounts. Other domains establish a one-way trust relationship with this domain. This provides central control over the creation of user accounts, while allowing the control of resource permissions to be delegated to the area in which those resources are located. These domains are generally referred to as resource domains. This model is explored in more detail in the section "The Single Master Domain Model" later in this chapter.
An implementation of the multiple master domain model enables you to establish multiple account domains. For example, in a large manufacturing organization you might have three main operating units of people: Administration, Engineering, and Production. Although you could establish a single master domain and have it managed by a central Information Systems (IS) staff, you might want to separate them. If these operating units are relatively autonomous, it may make sense to have each manage its own user accounts. A master domain can be established for this purpose with one or more resource domains trusting the master. See the section "The Multiple Master Domain Model" later in this chapter for more information.
You should now have a basic understanding of why you might want to create multiple domains, and some of the advantages provided by using different domain models. There are some additional planning issues that should be considered no matter which model is selected. These are outlined in the next section before the master domain models are explored in more detail.
When you implement a domain model in the real world, you must make sure that what looked good on paper works in reality. In most diagrams of domain models, the details of WAN links are suppressed. They tend to be logical diagrams rather than physical diagrams, which correspond to actual components. This section outlines some of the details that must be considered to make sure your plans are successful.
If you are setting up all your servers on a single high-speed local area network (LAN), then your job is much simpler: The primary planning consideration is ensuring that you select the appropriate number of servers, and they are sized properly (i.e. they have the correct components with sufficient speed and capacity to do the job). Sizing issues are discussed in a number of places in this book, and some specifics are offered for different BackOffice family components that make unusual demands on specific hardware elements where this is appropriate. For more information about server sizing, see Chapter 3, "Planning for BackOffice."
Implementations that must span a large geographic area and employ WAN technology require some additional planning. The crux of the matter is a balance of fault tolerance, speed, and expense. Consider for a moment an imaginary company, Fake Corporation, with its headquarters in New York and a branch office in St. Louis. For simplicity, this organization has chosen the single master domain model. A master domain has been established and named FAKE. A resource domain for each office has been established. Their names are NY and STL respectively. Both of these domains trust FAKE (one-way trust). A logical diagram of this scenario is shown in Figure 8.4.
This logical diagram depicts the relationship of the master domain and resource domains for Fake Corporation.
The link between Fake Corporation's New York and St. Louis offices is an ISDN line. It should be reasonably reliable, but may be subject to occasional outages (as is any service). The network traffic between the two offices is anticipated to be only moderate. Most network-based services will be provided by servers located in the same geographic vicinity as the person using them. The WAN link will be used to transfer e-mail from one site to another, perform occasional file transfers, and other ad hoc usage.
When it comes time to actually purchase servers and set up the domain structure, some important decisions must be made. It is obvious that at least one server must be established as the PDC for each of the three domains. The PDC for the FAKE domain will only be used to validate logons, so a machine with a fast processor (or two) will be selected, and a high-speed network adapter will be used. Now, how many BDCs for FAKE should be created?
Of course, there is no single right answer to this question. It depends on many factors, including some that have not been provided yet in this sample scenario. For example, are there 10 or 10,000 employees in Fake Corporation? Is the organization wildly profitable, or just barely avoiding bankruptcy? Is the organization a cutting-edge-technology firm, or a traditional company using many older and more conservative methods to reach the same ends. Judgment must be used when making these decisions.
Regardless of the answer to these questions, some broad assessments can be made. It is certainly desirable for network operation to be able to continue if the WAN link is temporarily unserviceable. Although the e-mail delivery from one office to another may be interrupted, it would be a more serious problem if users could not log on to the network. To avoid this possibility, a BDC from the master domain is located at each remote location.
As a practical matter in most network environments, a computer workstation can still be started and used even if a domain controller is unavailable. It will be impossible to connect other network resources, but work can continue on the workstation itself. For example, Windows NT Workstation will, by default, cache the last used ID and password locally (in encrypted form). This is obvious to laptop users who have started their computers away from the office. A different user would not be able to use the workstation until the domain controller was available, but the main user of the machine could get some work done until the problem was remedied
In any case, it is probably undesirable for logon validation traffic to be sent across the WAN link. Again, this is not an absolute rule. Very fast links may well be able to handle this traffic in a timely manner. Although there are some protocol issues that must be addressed (e.g., network logon validation requests can be presented as broadcasts), with proper configuration (typically using WINS), it is possible to log on to a network using a domain controller on the other side of a WAN link. The question is not so much, Is it possible, as Is it desirable? In most situations, it makes sense to place a BDC at each geographic location for redundancy and logon traffic management. The physical implementation of the Fake Corporation's domain architecture might look like Figure 8.5.
This physical network diagram shows the WAN link and locations of various domain controllers.
The most common domain model used in large enterprises is the single master domain model. This structure uses a single master domain and one or more resource domains. No user accounts are created in the resource domains, but rather, they use accounts from the master domain. In a pure implementation of this model, all resources (shared directories, printers, application servers, and so on) would be located in a resource domain. In practice, it is common for some universally used resources (e.g., e-mail servers or remote access servers) to be located in the master domain.
All user accounts and global groups are created in the master domain. This domain is typically administered by the IS department for the organization. As people join the organization, an account is created for them in the master domain. If they leave the organization, that single account can be disabled or deleted, immediately eliminating access to the entire network.
TIP: It is a good idea to disable an account for a short period before deleting it to be absolutely certain that it will never be needed again. Once an account has been deleted, the permissions assigned to that account must be reestablished from scratch, even if a new account with an identical user ID is created. This is due to the fact that permissions are associated with a unique security identifier, orSID, which is automatically generated when an account is created.
A master domain typically has at least two domain controllers with fast processors and high-speed network cards. They do not usually need to have a lot of disk storage or RAM (32M to 64M of RAM should be enough) because they are only validating logons. Shared resources and server-based applications run on servers in the resource domains.
See Chapter 3, "Planning for BackOffice," for more information on selecting appropriate hardware and options for your server.
Resource domains are then created by installing one or more domain controllers and establishing a one-way trust relationship. The resource domain trusts the master domain. Figure 8.6 depicts a typical master domain with two resource domainsóeach with a primary domain controller.
The master domain contains the users and group accounts, while the resource domains contain shared resources.
The domain controllers and other servers in the resource domain provide the shared resources users need and are the real workhorses of the network. They may have multiple processors and a lot of RAM (128M or more) to support server-based applications. If they exist primarily to support file and printer sharing, you should consider fast disk subsystems with RAID level 5 disk arrays or disk mirroring for high reliability. Windows NT supports RAID up to level 5 as a standard feature.
"See Software RAID," [Ch 6]
The master domain model yields a very useful environment. The master domain administrators maintain control over who can and cannot log on to the network. But the day-to-day activities of sharing printers and directories and giving users permissions to use them can be controlled by members of the department or organizational unit where the work is being done. By making one or more members of the department administrators of the resource domain, you can delegate some authority and provide an environment responsive to rapid changes. If you want slightly less autonomy with more central control, you can make department members server operators, account operators, printer operators, or backup operators rather than full-fledged administrators.
Administrators and server operators in the resource domain can assign permissions to shared resources. After the trust relationship has been established, the user accounts and global groups from the master domain can be used to assign permissions for resources in the resource domain. Figure 8.7 depicts a typical scenario in which the group Staff from the master domain GSULLIVAN is being given permission to use a shared directory called TechInfo on the server HQSrv1 in the resource domain GAS_STL_EXHIBIT.
Permissions are assigned to a shared directory in a resource domain using master domain accounts and groups.
Although the administrators of the resource domain control which users and groups are assigned permissions to resources in their domain, they really must trust the administrators of the master domain to be responsible about creating user accounts, managing password policies, and assigning group affiliations to user accounts. If zero-length passwords are possible and inappropriate user IDs are included in groups, the permissions on resources will be relatively meaningless. Trust is, therefore, an apt term to describe the relationship between two domains.
The features of a single master domain model should now make sense. You have learned what its basic features are and how to apply them to actual real-world situations. The next section explores the ramifications of going one step further to the multiple master domain model.
The multiple master domain model provides additional features and levels of control beyond the single master domain model. It may be selected because of the size of an organization, or to create an architecture that meets the needs of a particular organizational structure.
If the multiple master model has been chosen simply to accommodate the size of a very large organization, the criteria used to break the account population into multiple domains is somewhat arbitrary. It should be chosen to yield a fairly small number of balanced domains. To illustrate with an example, a scheme yielding five well-balanced domains of roughly the same size would be preferable to a method resulting in three large domains and eight very small domains. The criteria used might be based on an alphabetic division based on name, a grouping by department, or other similar method.
In this situation, a trust relationship is set up between all resource domains and each master domain. Because any particular resource domain has a trust relationship with each master domain, permissions can be granted to users from any of those domains based on need. The user population is thereby broken into smaller, more manageable groups that can be assigned to a particular administrator or an administrative team. Resource domains can still be controlled by a person or group associated with the resource itself, using accounts and groups from the collection of master domains. Figure 8.8 shows the logical design of such a network.
The multiple master domain model allows groups of accounts to be separately managed.
In addition to accommodating a large number of accounts, there may be organizational reasons for creating multiple master domains. The example cited earlier that uses separate and autonomous divisions for Administration, Engineering, and Operations is a good illustration of this type of need. Although the size of the organization may be well within the limits of a single master domain, the management of the Engineering division may not want to depend on the Administration division for network support. If each of these groups wants to be firmly in control of its own destiny, the multiple master domain model is the best fit.
With this situation, it is less important that the various master domains are of equal size. It is important that the domain architecture accurately reflect the organizational needs it was designed to match. Some analysis of the organizational structure may be necessary. For example, do the various entities share any centralized services? This is important in determining where to establish trust relationships and where to locate resources.
Typically, each entity has its own master domain and one or more of its own resource domains. Resources that may require access by the entire organization can be located in a resource domain that trusts all master domains and is managed by a group populated with members of each entity. The rest of the resource domains are dedicated to the needs of the entity that owns them.
A variation of this scheme can accommodate the needs of one or more departments with special security needs. The majority of users are added to a primary master domain, much like the single master model. However, an additional master domain is created for each department that requires especially stringent security (e.g., Human Resources). Standard resources are placed in resource domains that trust all masters. The members of the HR department and any sensitive resources are created in the HR domain.
If any widely used resources are placed in the primary master domain, a one-way trust relationship should be established (e.g., the primary master trusts the HR domain) so that users from HR can access these generic resources. In this respect, the HR domain is almost like a standard resource domain, but it contains its own users rather than trusting the primary master. Since it trusts no other domain, only users with a valid HR domain account can access resources contained in that domain. This scenario is depicted in Figure 8.9.
A multiple master domain architecture is showing a special HR domain created to accommodate the tighter security requirements of a particular department.
It should be obvious by now that Windows NT domains can be used to create a wide variety of useful architectures with features that match the needs of common organizational needs. By spending some time planning your domain architecture, you can create a design that best fits your organization.
Directory service technology has a long history dating back to the Athena project, the Distributed Computing Environment (DCE), and other such efforts to describe a comprehensive platform for delivering computer-based services. Most recently, the X.500 standard, with its Directory Access Protocol (DAP), has specified a directory service that can be used for a variety of purposes. The recent work by the University of Michigan and the Internet Engineering Task Force (IETF) on the Lightweight Directory Access Protocol (LDAP) promises to alleviate some of the shortcomings of DAP, and have garnered the attention and support of Microsoft, Netscape, Novell, and other important vendors.
Microsoft has announced its intention to improve the current directory service capabilities in Windows NT Server with important new features. The additions will be based on recognized standards (e.g., X.500, LDAP, and DNS) and will be accessible to software developers through a programmatic interface called Open Directory Services Interface (ODSI). This will enable third-party tool and utility vendors to create management and reporting tools that depend on these services. In addition, it will provide application programmers the capability to utilize the information stored in the directory service to make their applications more useful and easier to run.
It is unknown at the time of this writing how this new technology will be packaged. It is likely that it will be a standard component of the next release of Windows NT Server, but it is also likely to be available before then as a plus pack add-on similar to the plus pack offered for Windows 95. The technology was discussed in detail at the Professional Developer's Conference in November of 1996, and the materials from that conference were posted on Microsoft's Web server. This section is based on that information that is subject to change as the technology is completed.
The heart of the new directory service initiative is something called Active Directory. This is a technology that replaces, and is backward compatible with, the existing domain architecture used to manage these services today. The primary goals of this initiative are the following:
Some of these goals clearly depend on efforts that must be undertaken outside Microsoft. It remains to be seen how widely adopted this technology will be, but the market is demanding that something be done to alleviate the proprietary nature of directory services and the resulting islands of computing resources that are created. To learn how other vendors' servers might participate in this scheme, see the next section, "The Open Directory Services Interface (ODSI)."
For Windows NT servers, Active Directory creates a hierarchical domain structure that is more flexible and powerful than the flat structure that is currently possible. These new domains have been referred to as NT DS domains to distinguish them from older-style domains as implemented in Windows NT Server version 4.0 and earlier. The new domain structure will support transitive trust relationships. In other words, if domain A trusts B, and B trusts C, then A trusts C. This is not the case in current trust relationships, and there are situations when this capability will lead to a cleaner domain architecture that more closely matches the organizational structure.
Transitive trust is a feature of many human organizational structures that are in place in organizations. They are also often, though not always, a characteristic of personal relationships. For example, if I trust Sue, and Sue trusts Joe, I will often trust Joe (based on Sue's trust). In addition to enabling the computer-based domain structure to map human and organizational relationships, transitive trust has the practical effect of reducing the number of individual trust relationships that are required. In a large, multi-master domain architecture, with many resource domains, the number of trust relationships that must be created can be large.
The enterprise network can then be thought of as a hierarchy of NT DS domains (see Figure 8.10). Each domain has its own unique names for each of the name spaces supported. At a minimum, an X.500 name and a DNS name are provided. Objects that are members of the domain also have (a set of) unique names, and should yield a globally unique identifier when used in conjunction with the domain name.
This figure depicts a hierarchy of domains with transitive trust relationships.
Because the directory service plays a role in authentication and access control, each object that belongs to a domain will have an access control list (ACL) much like those used to secure objects in current Windows NT domains. The ACLs contain individual access control entries (ACEs) that describe the particular rights granted to a user or group for the object in question. This is probably the single most important feature that a directory service can provide to application developeró access control in a secure fashion to network-based resources with the same programming conventions regardless of the network operating system that is managing them.
A closely related technology that is critical to the success of future directory services is a uniform method of accessing those services with software. The programmatic interface being promoted by Microsoft is called the Open Directory Services Interface (ODSI). In the same way that Open Database Connectivity (ODBC) drivers have simplified the job of developing database applications, it is hoped that ODSI will simplify directory-enabled or directory-aware applications.
In a manner similar to ODBC, the ODSI initiative involves both client-side and server-side components. To be successful, both players in a client-server scenario must be involved. Although it is theoretically possible to do all the work on the client, this is not the approach that will ultimately lead to the best performance.
Under the planned initiative, each directory service would implement an ODSI service provider interface that would understand a standard set of requests for directory services. A client can then use a standard, ODSI-based method of requesting directory services from any provider. Clearly, this requires less overhead on the application than under a current scenario. It also makes life much simpler for the application developer, and allows the resulting application to be used much more broadly than before.
Like with ODBC, issues must be addressed. The most straightforward implementation would be to find the least common denominator of services shared by all service providers, and provide this limited subset of features through the ODSI interface. This is probably not good enough to satisfy a wide audience of developers, however. To alleviate this problem, service providers can "inform" the client application about the services they provide, and enable the client to step up to a full range of features if they are available on a particular provider, or scale back to a more limited set available on a less powerful provider.
To become popular, this technology will also have to address the layering concern that was, and still is with some, such a big issue. Some members of the development communityóthough they don't like creating applications that must support different providers or different versions of a programófeel they must provide the absolute best performance possible. This can lead to the desire to use only native programming interfaces.
To be successful, ODSI client-side drivers and service providers will need to be implemented in an efficient fashion to alleviate the need for direct use of the native (and proprietary) interfaces. This should be somewhat simpler with directory services than with generic databases because the amount of information requested from, or added to, a directory service is typically much smaller than the potentially huge amount of information that can be transferred to or from a general purpose database. Eventually, service providers can implement the ODSI interface as their native interface if they so desire.
The ODSI initiative offers many powerful features, and it is likely to eventually become a de facto standard whether or not it receives the endorsement from a recognized standards body.
You should now have a better picture of the way Windows NT Server can be used to build a large enterprise network and how individual servers participate. Also, you learned some important terminology, and the basics of Windows NT and BackOffice security. In the Chapter 9, "Using TCP/IP with Windows NT Server," you will learn exactly how to set up Windows NT Server on a computer, and how to configure it to perform the tasks you've been learning about. For more information about some of the topics addressed in this chapter, see the following chapters:
© Copyright, Macmillan Computer Publishing. All rights reserved.