You should now have an understanding of the core components and framework for the Exchange server and client. This chapter helps you understand the way Exchange integrates with the operating system. We will also discuss how Exchange can leverage the Windows NT platform to provide a robust and fault-tolerant messaging solution.
Windows NT is a 32-bit operating system. It provides multitasking and multithreading capabilities. This means that the operating system can simultaneously process multiple requests or instances of an application.
Windows NT is more that just an operating system. It is a framework to develop fault-tolerant client server applications. To enhance the operating system, Windows NT provides a full set of Application Programming Interfaces (APIs) and Software Development Kits (SDKs). The operating system is more than a file and print server: It is an application server. Through the use of the APIs and SDKs, many applications can harness the power of the operating system.
The operating system runs on a variety of platforms, including Intel and the Alpha platform. Although Exchange 5.0 also supported Power PC and MIPS platform, Microsoft offers only limited support. This portable operating system has several key benefits. The following sections cover the benefits in detail.
Windows NT provides native support for the following protocols: TCP/IP, IPX, NetBEUI, AppleTalk, DLC, SNA, X.25, and X.400(TP/x). This enables the operating system to support a wide array of clients. Windows NT can communicate with UNIX, Banyan Vines, DEC Pathworks, NetWare, Apple Macintosh, and of course all of the Microsoft networking clients, including MS-DOS, Windows For Workgroups, Windows 95, and Windows NT Workstation.
This feature enables Windows NT to interoperate in a heterogeneous environment. You will not be "bound" by implementing the Windows NT operating system into one of these environments. Windows NT can offer additional functionality in these situations. The alternative is providing native support that would be very costly or impossible.
For example, Windows NT can be easily added to a Novell NetWare environment to provide Remote Networking or Dial-in access. The Windows NT operating system ships with a complete remote access server component integrated with the OS. With NetWare you would have to purchase an additional product known as NetWare Connect to obtain this capability.
With Exchange, NetWare clients can easily access an Exchange server running on Windows NT with native IPX client software installed. Clients communicate with industry standards known as Remote Procedure Calls (RPC) by using the Exchange server. Windows NT supports every major communication protocol. Therefore, a client can connect to Exchange by using RPCs over TCP/IP or IPX in a NetWare environment.
In addition, Microsoft has released a standard for Remote Procedure Calls (RPCs) over AppleTalk, the Macintosh's native communications protocol. In order for a Macintosh work-station to connect to a Windows NT Exchange server, it can make RPCs over TCP/IP or AppleTalk. This functionality shows Microsoft's firm commitment to a Macintosh operating system and recognizes that the Macintosh operating system has an important share in the marketplace (see Figure 4.1).
FIG. 4.1 NT supports most industry-standard network protocols, as seen in this OSI model.
Security is a key element of any messaging system. Users want to know that their message will get to its destination without someone intercepting it. Exchange expands upon the Class C2 Level of Security, which is at the heart of the Windows NT operating system. The Department of Defense defines this level of security.
Class C2 requires a secure logon, discretionary access control, and full auditing capabilities. The secure logon requires that users identify themselves with a unique logon identifier (user ID) and password. This logon must be validated before accessing any system resources.
The discretionary access control enables the owner of a resource, whether it is a file, sub-directory, or printer, to determine who can access the resource. This also defines the level of control the user has over the resource. The owner grants rights to a user or group of users.
Auditing is the capability to log the security information of each operating system transaction to a file based on user ID. This feature provides the capability to detect and record important security-related events or instances in which security is challenged.
C2 security has several other components to its matrix of functionality. The Exchange server leverages its core features, however. Not all aspects of C2 security are required for use with Exchange. You also do not have to use every feature of C2 security when working on or creating a network application operating system. The company using the C2 security system can determine the level of security required.
Windows NT provides several tools to assist in managing the network as well as the operating system. Windows NT includes the Server Manager, the Event Viewer, and the User Manager to manage processes, define security privileges, provide auditing and security logging, and to create new users and groups, respectively.
The Server Manager enables the administrator to view all the servers from a single domain, multiple trusted domains across the enterprise, or individual servers and workstations inside a domain. The available functions enable you to control the share or access points to the file systems of a server, and to stop and start application processes. Using these functions, you can also close user sessions and manage specialized access via AppleTalk, NetWare Gateways, and the File Transfer Protocol (FTP).
The Event Viewer, also known as the Event Log, is the centralized repository for system, application, and security information for a server or workstation. From a remote console, an administrator can pull up the event viewer to see the etnries of a network server. All BackOffice-certified applications must write the events to the event viewer. Events can be informational (blue), cautionary (yellow), and serious (red) in nature. You will be able to tell whether your tape backup has finished properly and at what time of day it completed. From the system, you will see whether there have been any problems related to the operating system and the hardware. From the security log, you can view all the information predetermined for auditing.
The event will store information related to the Exchange server and all its gateways, connectors, and external processes. It will also store security information. Exchange itself has a security log, which extends the basic functionality provided by the event log.
The User Manager is a tool used by the security administrators or domain administrators to create the single domain logon user ID. This ID includes all the user's application profiles, the group memberships profile, and time and workstation restrictions. The User Manager helps you define trust relationships among domains, define auditing functionality, and define general domain user account functions.
From the User Menu, you can select to create a new user, a local group, or a global group. The user ID is the individual ID used in conjunction with the password to be authenticated by the domain to access network resources. Local groups are those residing within the single domain in which they were created. If the domain is referred to as "Dallas," all local groups created in this domain will be able to access resources only within the domain. Global groups, however, can be used to provide access to trusted domains. A local group can contain local user IDs, as well as global groups from both the local and trusted domains.
Exchange adds the functionality of creating a mailbox for users at the same time as the creation of their domain user account (see Figure 4.2). This gives the mail, security, and domain administrators control over the same set of user accounts. In large organizations, this is the responsibility of a Network Security Group. This one group would be responsible for creating the user Ids, as well as the appropriate mailboxes.
FIG. 4.2 Windows NT User Manager enables you to create domain user IDs, including the Exchange mailbox.
The functionality provided by these three tools is built into the Windows NT operating system. These tools can be run on remote machines, 16-bit workstations, and from the Internet.
At the heart of the Windows NT network operating system is the fundamental architecture of the domain model. A domain is a logical grouping of servers and workstations. One server in a domain must be the Primary Domain Controller (PDC) and subsequently have Backup Domain Controllers (BDCs). Windows NT provides the capability to build servers as "name servers," which belong to the domain. These servers, however, are not responsible for replicating user account and security information throughout the domain. The PDC and BDCs remain synchronized by updating each other's user and security databases at regular intervals 24 hours a day, seven days a week.
The domain architecture consists initially of a single PDC of a single domain. From there, Windows NT architecture can grow in any number of combinations that can include multiple BDCs in a single domain or a number of trusted domains with BDCs and member servers.
Trust relationships can be created between multiple domains. Trusts enable users from one domain to be granted secure access to resources in a second domain. This maintains the concept of the single network logon. Users will see no change from a single domain to multiple domains.
Two types of trusts exist: one-way and two-way. One-way trusts are set up to enable users from the second, or "trusted" domain, to access resources of the first or "trusting" domain. The second domain, however, has the freedom to create its user accounts and manage its own domain independently of the first domain. This can be illustrated by using a distributed administration model in which certain divisions have their own network administration; however, there is a central domain providing corporate-wide resources. The divisional domains can completely administer their own domains without affecting the central domain. The central domain has the capability to enable the divisional domain to access the central resources. This is useful because full administrator privileges can be given out at the divisional level without administrative rights over the entire WAN.
Two-way trusts grant access and administrative functionality among all domains that are in them. This is also known as the Complete Trust domain model (see Figure 4.3).
A domain is a logical grouping of servers that shares the same user accounts database and provides a single logon for all users to all the servers in the domain. As a comparison, on Novell version 3.x networks, each server maintains its own user account database or "bindery." In this way, user accounts must be individually created on each server.
The concept of a domain is primarily used for centralized administration. All the servers in a domain are updated with a single action. Regardless of when the user ID is created or modified, all the servers maintain the single logon for the group of servers in the domain.
A single domain consists only of a PDC. For small organizations, additional BDCs can be added to validate user access rights. A BDC is recommended if this system is in a production environment. This second Windows NT server will provide some fault tolerance. In the single domain, there are no trust relationships. Small organizations primarily use the single domain. These organizations do not have to be interconnected with other domains. Sometimes corporations use a single domain as a development domain. In this way, they do not affect the production domain. The server in the single domain can communicate with the other domains; however, additional user IDs will be necessary (see Figure 4.4).
FIG. 4.3 Establishing trust relationships between domains enables one domain to access the resources of another.
FIG. 4.4 The Single domain model represents the simplest form of a Microsoft Windows NT network.
In an environment with multiple domains, you can create trust relationships between domains. As discussed previously, domains can be interconnected via one-way or two-way trust relationships. In the master domain model, there is a one-way trust between the divisional domains and the central domain. All users and global domain groups are defined in the master domain. All other domains trust the master domain. This model ensures centralized administration for all domains. Again, this model maintains the single network logon by establishing one user account for the enterprise.
In a large organization, for example, the MIS Division manages from a central point. Therefore, the same should hold with the domain architecture. From one location, all users and security are maintained. The master domain referred to as "Corporate" houses all users and global groups. The resource domains, "Sales," "Marketing," and "Legal," only maintain local groups. When a resource is needed from the Sales domain, a local group is created in Sales, and its members include a global domain group from Corporate.
One disadvantage to this model is that performance might decrease as the number of users and groups grows. For this reason, larger domains need to consider the Multiple Master domain model (see Figure 4.5).
FIG. 4.5 The Master domain model puts global groups and users in the master domain. This model also places resources in separate domains.
The Multiple Master domain extends the Single Master domain into a broader scope. This domain model is typically seen in very large organizations. If your organization has two major corporate headquarters and many divisions, you might choose to implement the Multiple Master domain model.
Building on the previous example, the Multiple Master domain model has two tiers of domains (see Figure 4.6). The first tier interconnects the master domains. "Corporate" and "International" are the two domains. These two domains each house their respective users and global groups. These domains are then configured with a two-way trust. These domains trust each other; therefore, only one copy of each user ID is needed.
The second tier of domains includes all the resource domains. These domains each maintain a one-way trust to the two Master domains. This model can be scaled to networks with any number of users. You can easily have upwards of 10,000 users supported with this model. The resource domains can then be grouped logically based on function and geographic location. The resource domains also provide for local administration at the divisional level. The disadvantage to this model is that there are more trust relationships to manage. Also, not all user accounts are located in one domain.
FIG. 4.6 The Multiple Master domain model provides the scaling capability needed in a large organization when the master domain model is not sufficient.
The final option available for a Windows NT domain model is the Complete Trust domain. This model is best used in companies in which management of users and groups is distributed among different departments. Rather than being centralized, this model extends the administration down to the divisional level. Every domain trusts every other domain on the network. One immediate disadvantage to this model is that an administrator of one domain has full rights over every other domain in the model. This can lead to security problems. If you are going to use this model, an auditing process could help manage who has made administrative changes on the various domains.
In this model, the resources and the user accounts are grouped into divisions (see Figure 4.7). Again, the only situation in which a Complete Trust is appropriate is when there is a lack of centralized management. This model is not practical for corporations with a large central department. The reason is that the model lacks the security needed for a large enterprise network.
Several options exist for a Windows NT domain model. In Chapter 5, "Designing Exchange Topology," you are given the criteria for selecting which domain architecture to use when planning to deploy Exchange in your environment.
Microsoft also provides a tool through its BBS and Internet site to assist with planning a domain architecture. This tool is referred to as the Domain Planner. It is a Visual Basic application that steps you through the options when choosing your domain and trust relationships.
FIG. 4.7 The Complete Trust domain model is intended for decentralized management and carries many security risks for an enterprise network.
This section explains how Exchange leverages the Windows NT operating system. Exchange has been created to exploit all the features of Windows NT Server, including all the tools. These tools include the single logon, permissions that can be user defined, the User Manager for Domains, the Event Viewer, and the Performance Monitor.
Exchange runs on top of the Windows NT OS. However, it has hooks into the OS to provide a robust, high performance messaging system. Not all of the Windows NT terminology applies or directly converts to Exchange terminology. The reason is that the messaging platform has its own architecture.
Exchange uses the concepts of Organizations and Sites, whereas Windows NT uses domains. Organizations are at the top of the Exchange hierarchy. Typically, you find only one Organization name in the entire enterprise. Sites, on the other hand, can be geographic locations, divisions, or functional areas. Sites can also map one-to-one with domains.
Sites can span across multiple domains, provided that the domains are trusted. This is necessary because a server within a site must authenticate each user.
Both the Windows NT domain model and the Exchange architecture use the term "server." Within Windows NT, a server can be a PDC, a BDC, or a domain member server. Within Exchange, servers exist within a site. It is not necessary for the Exchange server to be either the PDC or a BDC of a domain. For performance reasons, it would be best for the Exchange server to simply be a member server. This way, the Exchange servers share the resources of a domain without having to continually replicate security information or validate user access to the network.
Following is a list of Exchange's features that help the Exchange server to closely integrate with the Windows NT Server:
FIG. 4.8 The Windows NT Service Manager enables you to start, stop, and pause services, as well as control their startup properties.
Exchange relies on the Windows NT operating system for certain functionality. The major function is that you must create a user account in the operating system for Exchange to run its services. Exchange also can import and export names from the Windows NT domain user database. This facilitates a quick migration to Exchange from your existing Windows NT Network architecture.
Exchange relies on the connectivity that Windows NT provides. Exchange enables all types of clients to connect to its servers. Novell NetWare clients, Macintosh, UNIX, and all the Windows clients can connect to Exchange using their native protocols. This is made possible through Windows NT's use of RPCs and multiple protocol support.
For remote access solutions, Exchange again relies on the Windows NT OS. Windows NT has an integrated remote access server as part of the operating system. The Windows NT server running Exchange can be configured for a user to dial directly into the server and access Exchange, as well as any other network resources. For performance reasons, it might be more appropriate to set up the remote access server on a dedicated server.
For WAN connections, Windows NT supports X.25 and ISDN without any additional software. An Exchange server can be configured to use an X.25 or ISDN connection to bridge the message route. If WAN links are already in place, these dial-up solutions provide a second level of fault tolerance, and an additional message route in an emergency.
The system service account enables Exchange servers to authenticate one another when transferring messages, updating the global address list, or performing directory synchronization. This account must be created with certain specifications.
It is important to carefully plan the implementation of this account. You must have a domain model that supports these user accounts. Whether you have a trusted or untrusted domain, you must ensure that the Exchange services can be authenticated between servers. If this does not occur, mail will not be forwarded from one system to another.
Exchange relies on the C2 level security of the operating system. Any user who attempts to access the system must first be authenticated by the domain. Exchange extends the single logon ID. Therefore, the domain logon also validates users for accessing the Exchange mailbox. As mentioned previously, in the file-sharing mail systems, users had full access to the file system that comprised the post office. Exchange now manages the access to the post office based on the central domain user database.
Exchange itself provides three levels of security. The user accounts are leveraged from the Windows NT user database. From within the Exchange Administrator Program, a user account can be specified as a complete administrator, a local administrator, or a read-only administrator.
There are many issues related to using Exchange on the Windows NT operating system. Windows NT provides connectivity to almost any other operating system used in the enterprise. Windows NT should not be a point of concern when deploying Exchange. The Windows NT OS interoperates more easily with your existing network operating systems and mail environments than some proprietary systems that communicate with themselves (this is the case with PROFS or OfficeVision). Exchange leverages the Windows NT OS to provide a strong messaging backbone. l