Integrating Windows NT into a UNIX Environment

As a Swiss-based IS consulting firm, the Comit Gruppe offers services such as technical consulting and bespoke software development for the banking and financial industry. Like many companies that implemented computer networks in the 1980s, the Comit Gruppe's network evolved over the years into a disparate array of machines. These machines included various UNIX servers and workstations, VAX servers running OpenVMS, and PCs running DOS and Windows 3.1. The multitude of operating systems and various hardware platforms caused several problems for the IS department, including overlapping administrative and support tasks for different environments, needing to hire specialists for each client/server platform, and having to bolt on software so PCs could access data on the servers. The clients also suffered various problems because of conflicts among different protocol stacks and lack of available memory resulting from terminate-and-stay-resident (TSR) programs loaded in conventional memory.

The company eventually decided to migrate many of the workstation and server platforms to a common and more manageable environment. The company introduced several Windows NT 3.51 servers into the organization and deployed NT Workstation 3.51 on the clients. I was responsible for adding NT into this environment with minimum disruption to services. This article is for UNIX systems administrators who face the many issues associated with introducing NT into a corporate UNIX environment.

Pre-NT Networking Environment
With five offices in Switzerland (two in Basel, two in Zurich, and one in Bern) and one in Dublin, Ireland, the Comit Gruppe keeps in touch through a WAN using leased lines and dial-up connections. Each office in the company uses a LAN with 10MB Ethernet and TCP/IP. In the pre-NT network, several database servers throughout the organization ran Oracle on either SCO UNIX or an OpenVMS platform. Several UNIX servers ran Lotus Notes to provide corporate email, and other UNIX servers handled the network file and print sharing requirements.

The clients on the pre-NT network consisted of UNIX workstations and PCs running DOS and Windows 3.1. The PC clients accessed data and printers from the UNIX servers using an NFS client for Windows.

Moving to NT
The Comit Gruppe decided to migrate as much of its network as possible to NT for several reasons, including the need for an environment that supports the new 32-bit desktop Windows applications and a requirement for a robust and reliable platform that was easy to control and manage. Although the existing UNIX servers provided several services (such as file and print sharing and Lotus Notes database services) to the PC clients, the Comit Gruppe needed to satisfy the growing demands of its client population. Moving these services to an alternative platform would free up valuable resources on the UNIX servers and let the company fully deploy these machines as database servers.

In addition to supporting the growing needs of the desktop users, the company supports several mobile notebook PC users. These machines require multiple configurations to ensure that they have the correct TCP/IP address when they access the LAN from the different offices. Supporting these machines led to additional overhead for the company's IS staff. The company knew that upgrading and replacing the existing UNIX server hardware would be costly. Fortunately, NT offered an environment that suited both the desktop and mobile client requirements and gave the Comit Gruppe a relatively inexpensive Intel-based server environment, compared to the existing UNIX platform. (For a list of advantages associated with migrating to NT, see the sidebar, "Benefits of Migrating to Windows NT.")

Integration Issues
To integrate NT into the existing UNIX networking environment and ensure a smooth-running project, the Comit Gruppe had to address several issues. The company decided to migrate the clients to NT in waves, so they had to maintain access to existing data on the UNIX servers. The company had to ensure that remote users could access the network for email and file and print sharing services. The Comit Gruppe also had to maintain access to the Lotus Notes databases, which would remain on the UNIX servers. Finally, the company needed to ensure that the migration caused minimum disruption to the clients. With these issues in mind, the next step was deciding how to deploy NT by considering which domain model to use, where to locate the NT servers, whether to deploy TCP/IP with NT, and how best to install NT on the workstations. (For a list of the migration issues that the Comit Gruppe faced, see the sidebar, "Migration Issues," page 192.)

When a Domain Is Not a Domain
When preparing to deploy NT, the Comit Gruppe had to sort through the differences in terminology for the UNIX and NT platforms. For example, UNIX administrators think of a domain in terms of Network Information Service (NIS) domains, Domain Name Service (DNS) domains, and email domains. An NT domain is a secure logical grouping of servers, workstations, and users. Domains form the basis for NT's networking security.

Grouping NT servers, workstations, and users into an NT domain prevents computers or users who are not members of that domain from accessing resources within the domain. More than one domain can exist on the same physical network as other domains and remain secure from users not defined within that domain, except by means of specific sharing mechanisms known as trusted domains.

By logging on once, without having to log on to each server that's part of the domain, users on an NT domain can access resources on servers within the domain. With this single logon, clients don't need to remember different user IDs and passwords for each server they access. One logon also reduces the administrative overhead associated with maintaining user IDs.

NT Server comes with several tools, such as the User Manager and Server Manager for Domains, which let the administrator centrally manage all user accounts and servers within the domain.

NT Domains
Understanding NT's domains will be old hat for NT network administrators, but UNIX network administrators will want to review the basics before adding an NT domain into a UNIX environment. Each NT domain must have a Primary Domain Controller (PDC). The PDC is an NT server that validates users logging on to the NT domain and contains the master copy of the Security Accounts Manager (SAM) security database for the domain. The SAM database contains information about users who are members of the domain, details about the servers and workstations in the domain, and information about the security accounts policy for the domain.

For fault tolerance and performance reasons, most NT domains have another server acting as a Backup Domain Controller (BDC), which maintains a copy of the SAM database. The BDC provides fault tolerance in case the PDC fails or goes offline. The BDC can also share the workload with the PDC and authenticate users logging on to the domain. More than one BDC can exist within the domain to provide additional redundancy and performance enhancement.

NT domains can also contain other domain servers that don't take part in authenticating users logging on to the domain. These servers are typically not suited to the additional overhead of maintaining a copy of the SAM database and authenticating user logons. As a result, these servers are better suited as database servers, application servers, and intranet servers.

NT Domain Models
Each domain's SAM database can be up to 40KB in size, which allows for up to 40,000 user accounts. However, many companies require more than one domain within the organization because of security, political, and size considerations. With NT Server, you can set up multiple domains and establish trust relationships between pairs of domains, so that one domain trusts another domain. This feature lets members of the trusted domain access resources on the trusting domain. Selecting the correct domain structure (i.e., domain model) to use within your organization is key to the successful implementation of NT networking and security. (For more information about domains and trust relationships, see "Related Articles in Windows NT Magazine," page 190.)

You can categorize most types of domains into one of four major domain models:

• Single domain: All user and machine accounts reside in one domain. This model requires only one SAM database.
• Single master domain: All user accounts reside in one database in the master domain, and machine accounts are split among one or more databases in resource domains that trust the master domain.
• Multiple master domain: User accounts are split among several master domains, which usually trust one another. Machine accounts are typically split among several domains, each of which trusts all master domains.
• Independent domains: User and machine accounts for a subset of the organization may be stored in the same database. Some domains trust each other, but some domains do not.

The Comit Gruppe Model
Because of its multiple office locations, the Comit Gruppe considered setting up a separate domain for each office and establishing trust relationships among the various domains. However, because the company has fewer than 200 users throughout the whole organization and uses mostly high-speed leased lines between four out of five of its offices, it decided to use a single domain model, as you see in Figure 1. Deploying one domain reduces the administrative overhead. Because the company doesn't have to maintain trust relationships, it can train fewer staff to administer NT, and it can manage the entire domain from one location.

   Previous  [1]  2  Next