Networking With Windows Nt

Transcript

INTEROPERABILITY INSIGHTS BY JOHN E. JOHNSTON Networking With Windows NT B This article describes the basic building blocks of a Windows network and identifies areas and components that form the framework of the network. uilding a Microsoft network using Windows NT servers and Windows 95 and/or Windows for Workgroups is a relatively simple undertaking. Because it is so easy to implement a Windows network, we must not forget to perform the planning steps that are required to ensure that the network we build is scalable to meet our future needs. This article describes the basic building blocks of a Windows network and identifies areas and components that form the framework of the network. DOMAINS VS. WORKGROUPS The first decision you will face when building your Windows network is whether to implement a domain or utilize the workgroup network model. The workgroup model is a peer-to-peer network where individual users can “share” the resources on their individual workstations with other users in their workgroup. For example, a user could allow other users in the workgroup access to his hard drive(s), printer and CD-ROM drive. The workgroup model is the simplest way to implement a Windows network but can quickly become a management nightmare. Workgroups can become unwieldy due to the lack of centralized control in the following areas: ■ ■ ■ ■ sharing of resources; user accounts; security rights; and local group creation. User accounts for local workgroups are stored on the individual workstations within that workgroup. This necessitates the duplication of user accounts on multiple PCs. The workgroup network model does work well in small environments. Larger shops that wish to implement hundreds of workstations should investigate the domain models which address the issues mentioned above. The domain networking models provide for centralized administration of network resources, including user accounts and security rights. A database maintained by the network administrator is established using the domain TECHNICAL SUPPORT JANUARY 1997 model which provides a central repository for this information, much in the same way the bindery or NDS operate in NetWare networks. The domain models are more complex and require more components to implement. Users can still manage and share their local resources with the domain models just as they can with the workgroup model. DOMAIN MODELS AND TRUST RELATIONSHIPS There are several domain models that you can use to implement a Microsoft network at your organization. Planning your domain setup is the most important factor you must address when building the network because changing the domain model after the network is in place is extremely difficult. You can choose from four domain models: ■ ■ ■ ■ single domain model; master domain model; multiple trust model; and multiple master domain model. If you choose to implement any of the models that utilize multiple domains (all but the single domain model) you must plan for interdomain trust relationships. When a domain is implemented, a database containing user account information, group information and security rights is established. You can allow the user accounts on one domain to be used in another domain. The best way to visualize this trust relationship is with an example: An administrator established INTEROPERABILITY INSIGHTS two domains — Domain1 and Domain2. User accounts are then established on both domains. There are users on Domain1 who need access to resources on Domain2. The administrator can configure Domain2 to allow accounts from Domain1 to have access to Domain2’s resources. Domain2 now trusts Domain1. Domain1 is known as a trusted domain to Domain2 while Domain2 is referred to as a trusting domain. The administrator can give users in the trusted domain access to resources in the trusting domain. This access extends to files, directories, printers, communication devices and services. Single Domain Model The single domain model is the least complicated of the domain models. With the single domain model, there is only one domain, so trust relationships are not required. The single domain model provides centralized management of all user accounts. The single domain model may not be appropriate for organizations with a large number of users (more than 10,000) or in complex organizations with a large number of servers. each domain then require access to resources in each others domains. Trust relationships are then established where both domains trust one another. Another domain is created in the MIS department. Users in the payroll and accounts payable department need access to the MIS domain. Trusts are then established between all three domains. As you can see, the multiple trust model can quickly get out of hand. Planning your domain setup is the most important factor you must address when building the network because changing the domain model after the network is in place is extremely difficult. Master Domain Model The master domain model utilizes one “master” domain that is trusted by all other domains in the organization. Although all other domains trust the master, the master does not trust any other domain. This allows for centralized administration of user accounts while allowing the implementation of multiple domains. Multiple Master Domain Model With the multiple master domain model multiple master domains are established. Each master domain trusts all other master domains in the network. This can be an effective design for very large networks as it allows for a mix of centralized and de-centralized administration. Multiple (Complete) Trust Domain Model In a multiple trust domain model all domains in the network trust one another. With this model domain administration is completely de-centralized. Because of the de-centralized structure of this model administration and security of the entire network becomes very complex. Many organizations find themselves implementing the multiple trust model by accident and then find out (when it’s too late to change) that the administration is too complex to effectively control. The way this happens is as follows: An initial domain is established in an organization in the payroll department. Another domain is then created in the accounts payable department, independently of the payroll domain. Users in DOMAIN COMPONENTS This section will examine the components required to implement a domain. Each domain requires the implementation of a Primary Domain Controller (PDC) to house the userid and security database. While the PDC is the only required component in the deployment of a domain, other components, such as the backup domain controller, will enhance the availability, stability and performance of your network. Primary Domain Controller The Primary Domain Controller is the most important single hardware component of the Windows network. The PDC is a Windows NT Server file server that is used as a repository for the userid and security databases. As new users are added to the network and security rights are granted, this information is stored on the PDC database. When a user logs into the network, the network access authentication occurs using the data stored on the PDC (a backup domain controller can also be used for authentication, and will be discussed later). Due to the critical nature of the PDC, you should take steps in the planning stages of your network design to ensure that the PDC will perform at acceptable levels. You should also investigate hardware options that enhance the availability of the PDC. The PDC should be implemented on a high quality file server. The server should be a Pentium or PentiumPro based machine. Plan on installing at least 48MB of RAM on the PDC as a starting point. You may need to increase the amount of RAM as your network grows. The PDC should also utilize a fault tolerant disk storage system, such as mirroring or a hardware implementation of RAID 5. A hardware implementation of RAID 5 requires the use of an array controller card and multiple SCSI disk drives. This array controller offloads the overhead of RAID 5 from the file server’s CPU(s) to the processor(s) on the controller. You should not attempt to utilize a software RAID 5 disk subsystem on a PDC. The overhead associated with the RAID 5 software will cause the performance of the PDC to suffer. The file server that contains the PDC should also be dedicated to the Primary Domain Controller function. No other applications or services should be implemented on the PDC file server. One of the traps that many administrators find themselves in is the need to implement multiple PDCs. The scenario in which this tends to happen follows: Department A implements a Windows network, utilizing its own PDC. Department B then implements its own Windows network and installs its own PDC. Now IS comes along and decides to implement a company-wide Windows network and builds yet another PDC. When it is time to tie all of these networks together, the administrator must deal with the multiple PDCs. All of the information in the PDCs could be combined into a single PDC or the PDCs could be linked together. Neither option is simple to implement. The best way to address this problem is to never let it happen in the first place. BACKUP DOMAIN CONTROLLER The Backup Domain Controller (BDC), as its name implies, is a dynamic backup of the PDC. While the BDC is not mandatory in the implementation of a Windows network, it is a very important redundancy feature and should be implemented in almost all production-level Windows networks. As changes are made to the Windows network domain (such as the definition of a new user), the information is updated in the PDC. These changes are then replicated on the Backup Domain Controller(s). If the PDC fails, the users can authenticate via the BDC. There are three important facts about the BDC that should be considered when designing your network: ■ The BDC is a “read-only” copy of the PDC. Many of you who are familiar with NetWare 4.x have dealt with NDS replicas. You may have read/write and read-only NDS replicas. With a read/write NDS replica, changes to both copies of the NDS database are kept synchronized using the services of NetWare. In other words, if a change is made to a read/write NDS TECHNICAL SUPPORT JANUARY 1997 INTEROPERABILITY INSIGHTS Figure 1: The BDC Can Be Used in WAN Environments to Distribute Network Authentication dynamically. This provides for centralized management of computer names. DYNAMIC HOST CONFIGURATION PROTOCOL San Francisco Regional Office BDC Frame Relay Cloud BDC Philadelphia Regional Office Houston Home Office BDC BDC PDC replica, that change is automatically replicated to the master NDS database, and when a change is made to the master NDS, that change is automatically replicated to the read/write replica(s). The BDC, on the other hand, is a read-only copy of the PDC. You may not add a user to a BDC or change security rights in a BDC. All such changes must be made on the PDC. However, when changes are made on the PDC, these changes will be replicated to the BDC(s). ■ The BDC can be used in WAN environments to distribute network authentication. The best way to envision this mechanism is with an example. A home office of a corporation is located in Houston, Texas, as illustrated in Figure 1. The Windows network installed at this site contains a single PDC. Regional offices are located in San Francisco, Calif., and Philadelphia, Pa. The local area networks of these three offices are connected to each other utilizing a frame relay cloud. The PDC is located in the Houston office, while the two regional offices each contain a BDC. When a user in the Houston office logs into the network, the data on the PDC is used to authenticate the user. When a user in either regional office logs into the network, the data stored on the BDC is accessed to provide authentication for the user. The authentication process for the regional office user was not required to traverse the WAN link to verify the userid and password. This helps us in two ways. First, the regional office users’ authentication process occurs much quicker since the slow WAN link is not accessed. Second, TECHNICAL SUPPORT JANUARY 1997 if the Primary Domain Controller is down (which would make for a very bad day for the network administrator at the home office), the regional user could still log into the Windows network domain and access the network resources. ■ The BDC can be promoted to a PDC. If a PDC is down, and the time required to recover the PDC file server is expected to be very lengthy, a BDC can be promoted to a PDC. Let’s look at an example where this would be useful. The corporation previously illustrated also implemented two additional BDCs at the home office in Houston, as shown in Figure 1. If the PDC is destroyed or experiences a traumatic hardware error, one of the BDCs would be promoted to the PDC. When this promotion occurs, the new PDC will announce that it has been promoted and all of the remaining BDCs would recognize the presence of the new PDC and any changes made to the PDC would be replicated at each BDC. When the original PDC file server is recovered, the PDC on that server cannot reestablish itself as the PDC (current as of release 4.0 of Windows NT Server). Attempting to re-instate the old PDC into this scenario would prove to be unpredictable at best, disastrous at worst. WINDOWS INTERNET NAME SERVICE The Windows Internet Name Service (WINS) is used in a Microsoft-based TCP/IP network to resolve internal computer names. WINS contains a database of names and corresponding addresses that it updates Dynamic Host Configuration Protocol (DHCP) is a tool that helps to automate the administration of IP address administration. Devices are assigned IP addresses by the DHCP server when they are powered up. If a device is moved to another subnet within the LAN, it will automatically be assigned a new IP address. The DHCP function is run on a Windows NT Server. When configuring the DHCP server a range of IP addresses under its control is specified. DHCP then “leases” these addresses to the devices as required. DHCP does have one glaring fault: There is no redundancy built into the DHCP function as with the PDC and BDC. To address this issue, you may implement multiple DHCP servers, each given a separate range of IP addresses to administer. If one of these DHCP servers is unavailable, the alternate can still perform the IP address assignments. PLANNING FOR FUTURE GROWTH Planning for future growth of your Windows network can make your life much easier in the long run. A proper domain model and PDC/BDC configuration is essential and the implementation of the Dynamic Host Protocol can make IP administration much simpler. The BackOffice suite should also be considered for large Windows networks. This suite includes Microsoft SQL Server, SNA Server, Systems Management Server and Mail Server. ts NaSPA member John E. Johnston is manager of technical support and communications for a major hospital in Pennsylvania. He designs and maintains cross-platform local and wide area networks utilizing NetWare, OS/2, DOS, and Windows. ©1997 Technical Enterprises, Inc. Reprinted with permission of Technical Support magazine. For subscription information, email [email protected] or call 414-768-8000, Ext. 116.