Server for NIS Overview

  • Article

Abstract

Services for UNIX includes Server for NIS, an NIS server that runs on the Microsoft® Windows® 2000 operating system and allows administrators to manage both Windows and UNIX networks using Windows 2000 Active Directory™ service. Server for NIS allows a Windows 2000 Server domain controller to act as the master NIS server. It integrates NIS data with that of Active Directory. This white paper describes the objectives, design goals, architecture, and deployment options for Server for NIS.

On This Page

Introduction Introduction
Overview of UNIX and Windows Network Management Overview of UNIX and Windows Network Management
Overview of Windows Network Management Overview of Windows Network Management
Architecture of Server for NIS Architecture of Server for NIS
Features of Server for NIS Features of Server for NIS
Deployment Scenarios Deployment Scenarios
Summary Summary

Introduction

What Is Server for NIS?

Server for NIS is an implementation of Sun Network Information System (NIS) server on a Windows server, which uses Active Directory to store NIS maps. It provides complete compatibility with the NIS specifications, and interoperates with other NIS servers and clients in the network. Server for NIS, running on a Windows 2000 (or later version), can be used as an NIS server in place of a UNIX-based server. Server for NIS allows managing NIS namespaces using Active Directory, and thus makes it easier to manage a mixed Windows 2000-based and UNIX-based network using only Active Directory. It provides the ability to integrate Windows and UNIX namespaces into a single logical namespace. This allows corporations to use Active Directory as a global directory and manage both UNIX and Windows objects using Active Directory-based tools. Server for NIS also allows migration of NIS maps to Active Directory.

Problems of Separate Windows and UNIX Networks

As Microsoft Windows 2000 and Windows XP have introduced additional features and have improved in reliability, availability, and scalability, a number of businesses have integrated Windows computers in their traditional UNIX enterprise networks. With heterogeneous networks come a variety of issues, described below.

Division of Logical Network

In an enterprise network, users need to share resources residing anywhere in the network depending upon business needs. However, historically, Windows and UNIX have used different mechanisms for managing user accounts, groups, computers, and other network objects. They also differ in mechanisms for resource sharing and access control. This makes it difficult to share resources effectively in a heterogeneous network dividing the logical network along the lines of implementation technologies. This creates an artificial gap between Windows and UNIX networks.

Separate Accounts

Due to differences in security mechanisms and account management tools on Windows and UNIX systems, users have separate accounts with different identities and passwords on each operating system. There is no relationship between the two accounts. The users and administrators must manage this externally by keeping the same user names and passwords in two separate places. Ideally, each user should be represented uniquely in the network with a single user name. And users should be able to access resources as determined by the corporate policies rather than by network implementation.

Due to differences in access control technologies each user must specifically request and obtain access to both UNIX and Windows. They need to log on differently, change passwords separately, and look up two separate directory namespaces.

Administrative Issues

Windows 2000-based and UNIX-based operating systems use different mechanisms for managing user accounts and groups, and use different directories to store user and system data. This combined with the need to keep two sets of accounts places an unnecessary burden on administrators. They need to manage two directories separately and to keep them in synchronization. Whenever a user joins the organization, that user must be added to both networks separately. Similarly, whenever user data is changed—for instance, the user's password or office number—this data must be changed on two directories separately.

Objectives of Server for NIS

The primary objective behind Server for NIS is to bridge the gap between the two networks for administrators and users. This is possible if the two sets of namespaces are integrated into a single entity. A common set of management tools can then be used to manage users, groups, and other objects in the two networks. Another important objective is to make this completely transparent and as easy as possible for users. Users continue to use the mechanisms that they were using for access to Windows or UNIX.

The primary design goal behind Server for NIS is to create a common network directory of Windows and UNIX objects. Administrators can consolidate UNIX and Windows objects under a common namespace and represent each object uniquely in this namespace. Administrators can then use Active Directory-based tools to reduce the divide between the two networks. Server for NIS implements NIS functionality on a Windows 2000-based server to allow UNIX NIS-based domains to continue to operate with little or no change.

Lastly, Server for NIS also provides a mechanism to easily migrate NIS maps to Active Directory.

Benefits of Server for NIS

Table 1, below, lists the benefits of Server for NIS.

Table 1 The features and benefits of Server for NIS

Feature

Function

Benefit

Uses Active Directory to store NIS maps. Extends Active Directory schema to store NIS maps.

Server for NIS stores NIS map data in Active Directory. It extends the Active Directory schema to add a class for each NIS map. Each map entry is stored as an object of that class. Supports standard and non-standard maps.

This allows access to NIS data through Active Directory protocols, namely LDAP and ADSI in addition to NIS. This allows use of Active Directory tools such as Microsoft Management Console and other tools. It need not use tools such as make for map management as it is currently used for NIS. Use of Active Directory for NIS map storage also provides scalability and security for handling NIS maps.

Integrates NIS map data for password, group, and hosts with corresponding objects in Active Directory.

Server for NIS extends Active Directory classes such as user and group to include UNIX attributes. It stores the specific UNIX attributes of password, group, and hosts in these extended attributes of the corresponding Active Directory objects. If a Windows user is also a UNIX user, he/she will have UNIX-related data recorded in these attributes.

Allows integration of UNIX and Windows namespaces. Objects common to two namespaces are represented uniquely in this namespace. NIS attributes can be managed using Active Directory and its tools, such as the Users and Computers management console.

Supports NIS v2.0 protocol

Server for NIS implements NIS version 2.0 protocol using ONC-RPC. It implements all necessary NIS procedures.

This allows Server for NIS to be used as the master NIS server. Server for NIS supports UNIX NIS servers and clients seamlessly.

Allows migration of NIS domains to Active Directory

Server for NIS provides a migration tool and a migration wizard to migrate maps from existing NIS domains to populate the Server for NIS database.

Allows easy migration to an Active Directory-based NIS server. It allows administrators to take advantage of Active Directory by migrating existing NIS maps and manage them with little effort.

Supports multiple NIS domains

Server for NIS can serve multiple independent NIS domains at the same time. Server for NIS also allows migration of multiple NIS domains. NIS clients or servers from each domain receive maps and objects that are in that domain only.

This allows administrators to take advantage of the scalability of Active Directory. It also allows them to manage all domains from one place.

Allows merging of multiple NIS domain maps into a single domain

Server for NIS allows administrators to migrate multiple domains and merge the migrating domain into an existing NIS domain. It also supports a default NIS domain upon installation that can be used to create a universal NIS domain.

This allows creation of a truly global namespace that not only consists of UNIX and Windows objects but also objects from multiple NIS domains. Active Directory can work as a catalyst to create a truly enterprise-wide global directory.

Allows management of NIS maps using Active Directory tools

Since NIS data is stored in Active Directory, Active Directory-based tools can be used to manage NIS data. This might consist of Windows 2000-based management consoles, LDAP-based tools, or ADSI-based client server tools.

With the help of Active Directory, Server for NIS supports a variety of mechanisms to manage data from NIS. Tools based on ADSI and LDAP, NIS or Active Directory tools may be used for managing NIS.

Supports yppasswdd

UNIX users may change passwords using existing yp tools such as yppasswd. These passwords are changed on Server for NIS using yppasswd.

Migration to Active Directory is completely transparent to users. UNIX users continue to operate as usual.

Performs password synchronization

Server for NIS keeps loose synchronization between Windows and UNIX passwords. When users change their Windows passwords, their UNIX passwords are also set to this new password. However, if users change the UNIX password, Windows passwords remain unchanged.

Users who need to access to Windows 2000-based and UNIX-based computers can change passwords on the Windows 2000-based computer and get password synchronization. On the other hand, those users that use Unix-based computers exclusively can continue to use NIS based tools exclusively.

Notes:

  • Server for NIS supports only NIS; it does not support NIS+.

  • Server for NIS can be used only as a master server for NIS. It cannot function as a subordinate (slave) NIS server in a domain where a UNIX-based server is a master NIS server1.

  • Server for NIS may be a slave NIS server in a domain for which another Server for NIS is a master NIS server.

  • Server for NIS may only be installed on a Windows 2000-based domain controller.

  • Server for NIS in SFU version 3.0 supports upgrading from Server for NIS version 2.0. Both the schema and the data from the previous version will be migrated to the new version and clients of NIS will continue to obtain services from Server for NIS after the upgrade.2

Overview of UNIX and Windows Network Management

Traditionally, UNIX computers use files for storing directories and managing namespaces consisting of users, groups, networks, services, and so on. Examples of these files include /etc/passwd, /etc/group, and /etc/hosts (consisting of users, groups, and hosts respectively). These files are maintained and updated on each computer, giving each administrator complete control over that computer.

However, this scheme is problematic in networks where network administrators need control over entire namespaces for overall access control and resource sharing. The /etc files of all computers have to be kept in sync so that security and resource sharing can be achieved. Because of this, some ad hoc methods were developed to share these files among computers. One such method consists of distributing these files, through rdist, from one computer to all other computers. This requires that all updates to the namespace take place on the computer that distributes the changes to other computers.

Overview of NIS

In 1981, Sun introduced Network Information System (NIS), a simple network look-up service consisting of databases and processes. This protocol was formerly known as Yellow Pages (yp). NIS consists of a set of maps or databases consisting of data from /etc files, and a set of computers among which these maps are shared. NIS is an Open Network Computing (ONC)- and Remote Procedure Call (RPC)-based protocol.

An NIS domain consists of clients and servers. Clients use NIS protocol to look up information such as passwords, groups, and hosts stored in NIS databases on servers instead of local files. Databases are replicated among servers. There is one master server, which is used to update databases, whereas subordinate (slave) servers provide read-only access. Databases are kept consistent by copying them from master to server either periodically, or upon change.

When database source files, such as password and group, are changed, administrators use the shell script ypmake to update databases. In addition, makefiles are used to push databases to subordinate NIS servers using yppush by sending a ypxfr request to the subordinate servers. The transfer takes place either using ypxfrd, a daemon running on master server, or using the yp_all function. The time stamp maintained in the map is used for this synchronization.

Clients use various functions or rpc calls to interface to this network look-up service. These include, yp_match, yp_first, yp_next, yp_all, yp_order, and yp_master. In addition, NIS on UNIX includes some administrative tools to manage maps, namely, ypwhich, yppoll, ypset, ypcat, ypmatch and domainname.

Overview of Windows Network Management

Windows NT 4.0 uses Windows NT Directory Service, a domain-based architecture for network management. Windows NT Directory Service is based on a secure directory database that contains user IDs, passwords, access rights, and organizational information. In the domain model, the domain controller holds the copy of the domain directory database. Clients talk to domain controllers to authenticate and authorize users. The domain model supports a variety of configurations based on a variety of trust relationships.

With Windows 2000, Microsoft has introduced Active Directory, a flexible directory providing features such as security and replication. It allows creation of a hierarchical structure of the organization consisting of domains, sites, organizational units (OUs), and trust relationships. Active Directory creates replicated, reliable storage for storing network objects such as users or groups. It provides access to the directory database through protocols such as LDAP and programmatic interface such as ADSI.

Architecture of Server for NIS

Server for NIS implements NIS server functionality by providing NIS protocol using ONC-RPC mechanism. It implements NIS version 2.0 protocols including those necessary to serve NIS clients and subordinate NIS servers. It uses Active Directory to store NIS map data and hence must be installed on Windows 2000 domain controllers.

Figure 1: The network architecture for Server for NIS

Figure 1: The network architecture for Server for NIS

Figure 1 shows a typical network architecture within which Server for NIS might be used. Server for NIS is installed on Windows 2000-based domain controllers, while the Windows 2000-based domain structure remains unaffected. Windows clients continue to operate as before.

The NIS domain uses one or more Windows domain controllers as NIS servers. One of the domain controllers acts as an NIS master for the NIS domain, whereas the other domain controllers with Server for NIS installed act as NIS subordinate (slave) servers. In addition, the NIS domain may continue to use existing UNIX NIS servers as subordinate servers. Server for NIS provides NIS interfaces necessary to act as either a master or subordinate NIS server. Communication between a Server for NIS-based domain controller and UNIX subordinate NIS servers is done using NIS protocols*.* On the other hand, communication between NIS servers based on Active Directory takes place through Active Directory replication. It does not use NIS protocol for this communication3.

NIS clients continue to use NIS RPC calls such as ypfirst and ypnext to communicate with NIS servers as usual. NIS clients may use either UNIX NIS servers or Windows-based Server for NIS for resolving NIS queries.

Features of Server for NIS

Server for NIS provides the following main features:

  • Stores NIS maps in active directory by extending the Active Directory schema

  • Integrates some of the NIS classes with corresponding classes of Active Directory, thus integrating the two namespaces

  • Implements NIS server functionality on a Windows 2000-based server

  • Allows migration of existing NIS domains to Active Directory

  • Provides Active Directory-based tools to manage NIS domains

  • Supports yppasswd and provides password synchronization from Windows domain to NIS domain

Use of Active Directory for Storing the NIS Map

UNIX NIS server stores NIS maps using DBM format, which is supported natively on UNIX. NIS is a simple directory wherein map data is flat. Server for NIS does not use DBM format, rather, it stores NIS maps using Active Directory. Active Directory provides a flexible and extensible mechanism to store directory information.

Server for NIS allows storing of NIS data in any container in Active Directory, although it stores maps for each NIS domain in a separate container. Administrators may specify any container—such as an organization unit (OU)—that reflects the organizational structure in order to store that domain. Storing the objects in the default container for the NIS domain speeds up searches and thus improves the performance of NIS operations such as ypmatch and ypcat.

Server for NIS can support multiple NIS domains at the same time. Each object includes an attribute listing the domain to which it belongs. Using this information, requests from each UNIX client belonging to a particular domain will receive maps associated with that domain only.

Storing NIS maps in Active Directory has a number of advantages such as scalability and security. Access to Active Directory data is secure, which ensures that only authorized administrators may modify the data. With Active Directory replication, all domain controllers of the Windows domain have the copies of the NIS maps. This makes it possible for the remaining domain controllers to act as slave servers for the same NIS domain. Server for NIS does not use the NIS mechanism for keeping maps synchronized, but rather uses directory replication.

Further, due to its support for LDAP and ADSI API, it is possible to create NIS map management tools using any of these protocols in addition to using NIS protocol itself.

Extension of Active Directory Schema

While implementing NIS server functionality, Server for NIS does not store NIS maps as flat data or as plain text entries in Active Directory. It extends Active Directory schema to store UNIX attributes. Each map is created as a separate Active Directory class. It stores NIS map by associating each field of the map as a separate attribute. Entries in the NIS map are stored as objects of that class. Fields of NIS maps are stored as attributes of that object.

The advantage of this approach is that it is possible to provide semantic meaning to fields of map entries. It is also possible to search entries using different fields. Since Active Directory allows search on any attribute, maps can be looked up (through ypmatch) on any of the attributes of the map.

For example, consider NIS services map, which consists of entries as follows:

telnet    23/tcp
smtp      25/tcp     mail  
iostation  35/tcp     imagen # imagen net port
iostation  35/udp     imagen # imagen net port (status)
time      37/tcp     timserver
time      37/udp     timserver

In order to save services map in Active Directory, Server for NIS creates the Active Directory class shown in table 2.

Table 2 Active Directory class created by Server for NIS

Object class

Class schema

Common name

MsSFU30IpService

Class type

Structural

Subclass of

MsSFU30Top

Must contain

CN
msSFU30IpServiceProtocol
msSFU30ipServicePort
msSFU30Name

Inherited must contain

msSFU30NISDomain
from msSFU30Top

May contain

Description
msSFU30Aliases

Inherited may contain

msSFU30NisMapName
from msSFU30Top

Consider a services map entry such as the following:

smtp      25/tcp     mail

This will be represented as cn=25/tcp, msSFU30IpProtocol=tcp, msSFU30IpPort=25, msSFU30Name=smtp, msSFU30Aliases=mail. In addition to the way this entry is stored, Server for NIS also includes msSFU30NISDomain for each NIS entry/object, which provides the domain in which this object appears4. This scheme is used for both standard maps and non-standard maps.

As maps from each domain are migrated, Server for NIS creates objects corresponding to entries of each map. For non-standard maps, it first defines the structure of the map, such as the key field and field separator, and then stores the map entries. During installation, Server for NIS already creates a default NIS domain whose domain name is the same as the Windows 2000-based domain. NIS entries can be created or assigned to this domain.

Integration of NIS Maps with Active Directory

In addition to extending Active Directory for storing NIS maps, for certain classes Server for NIS integrates NIS data with Windows objects stored in Active Directory. These NIS maps include password, group, and hosts. For these maps, NIS objects are not represented separately in Active Directory. If a corresponding Windows object is present in Active Directory, it adds UNIX attributes to the same object creating a unique object representing both UNIX and Windows identities. If no such Windows object exists, a new Windows object is created and UNIX attributes are added to it. With this, UNIX objects are made first class entities of the Windows domain.

For example, information needed for a UNIX user is stored in Active Directory as part of the Active Directory User group. To allow storing UNIX attributes, Server for NIS extends the User group with msSFU30PosixAccount as its auxiliary class. This allows UNIX attributes to be added to newly created objects of the User class.

Table 3 MsSFUPosixAccount class created by Server for NIS

Object class

Class schema

Common name

MsSFU30PosixAccount

Class type

Auxiliary class

Subclass of

Top

May contain

msSFU30NisDomain
msSFU30Name
msSFU30UidNumber
msSFU30GidNumber
msSFU30Password
msSFU30HomeDirectory
msSFU30LoginShell
msSFU30Gecos
description
msSFU30PosixMemberOf

When Server for NIS creates an entry from the passwd map, it first checks if the user with the same user name is already present in Active Directory. If this user does not exist, it creates an object of class User with CN and samAccountName set to the UNIX user name, thereby creating a Windows user with the same user name. It then adds UNIX attributes to that user object. This allows UNIX users to be also created as Windows user in Active Directory and allows them to be managed by using Active Directory. Those users who only had UNIX accounts also get a Windows account.

If a Windows user with the same user name as a UNIX user being added already exists, it adds the UNIX attributes of that existing object. This mechanism allows a Windows user to be made a user of an NIS domain as well. This allows an integration of Windows and UNIX networks wherein each user is represented uniquely. Those users that need only Windows access remain unchanged. Those users that were previously represented as two separate users in UNIX and Windows are represented uniquely as a single user. Administrators can assign UNIX attributes to existing Windows users and assign them to a particular NIS domain.

Entries from the group map are created in the same manner. If there is no Windows group with the same name as a group being migrated from NIS, a group with that NIS name is created. If a Windows group with the same name does exist, UNIX attributes are assigned to that group. By assigning a GID and a domain name, a Windows-based group also can be marked to be part of NIS.

Server for NIS maintains a reciprocal relationship between users and groups; in other words, if an NIS user is a member of some NIS group, that NIS group automatically gets the user as a member. However, Server for NIS does not keep UNIX user and Windows user memberships for a group synchronized. Each group maintains two sets of memberships: users who are members of the group in a Windows 2000-based domain and users who are members of that group in a UNIX-based domain. This is due to differences in how Windows and UNIX treat group memberships. Windows maintains a strict reciprocal relationship whereas UNIX maintains a non-strict relationship between users and groups.

Entries from the hosts map are treated similarly and integrated with the computers class in Active Directory. They are created as members of the computers class in Active Directory. Essentially, this allows the entire network of UNIX and Windows computers to belong to the same network.

Migrating NIS Domains to Active Directory

Server for NIS provides migration tools to migrate NIS maps from a UNIX NIS server to Active Directory. With migration, NIS map entries can be migrated and corresponding objects created in Active Directory.

After the migration, Server for NIS running on the domain controller takes the role of an NIS master. The NIS domain can then be administered using Active Directory.

Migration tools (a graphical migration wizard and a command-line tool) make it easy to migrate all NIS maps, and hence the NIS domain, to a Windows 2000-based domain controller. Administrators do not have to recreate the NIS objects in Active Directory. These tools help ensure that the transition to Server for NIS is minimally disruptive and that all data is migrated. Migration tools flag migration errors and identify any conflicts. During the migration of an entry, if an entry with the same key value already exists in the Active Directory for the same NIS domain, conflict is identified. Administrators can forcefully overwrite existing entries, preserve existing entries, or manually resolve the conflict by merging the two entries.

Management of NIS Domains Using Active Directory Tools

Server for NIS allows administration of NIS maps using Active Directory-based tools. Entries from NIS maps such as password, group, and hosts are migrated to their corresponding Active Directory objects such as users, groups and computers, and therefore these objects may be managed using the Active Directory Users and Groups snap-in.

In order to manage other standard and non-standard maps, Server for NIS provides a command line tool called nismap. Nismap allows administrators to add, delete, and edit entries from NIS maps.

For example, consider a map called phones for domain physlab on Server for NIS. In this example, the administrator modifies the map entry for Linda by changing the phone numbers.

C:\temp>ypcat -d physlab phones
Peter xxx-936-4234 xxx-941-3444
John  xxx-321-3343 xxx-334-3434
Mary  xxx-321-9089 xxx-323-9887
Janet xxx-832-2534 xxx-421-9865
Linda xxx-345-8765 xxx-454-5567
C:\temp>nismap mod -a physlab -k Linda -e "Linda xxx-345-8765 xxx-454-6667" phones
Updating 'phones'...
SUCCESS
Updating 'Linda' existing at
   DN= 'CN=Linda,CN=physlab,CN=DefaultMigrationContainer,DC=winnis,DC=microsoft,DC=com'.
C:\temp>ypcat -d physlab phones
Peter xxx-936-4234 xxx-941-3444
John  xxx-321-3343 xxx-334-3434
Mary  xxx-321-9089 xxx-323-9887
Janet xxx-832-2534 xxx-421-9865
Linda xxx-345-8765 xxx-454-6667

Because Server for NIS is based on Active Directory, administrators can write new tools using Active Directory interfaces and protocols, such as ADSI and LDAP, to manage NIS maps.

Yppasswd and Password Synchronization

Server for NIS supports yppasswdd, thus allowing NIS users to change their passwords from UNIX clients using yppasswd. UNIX-based users benefit by being completely unaffected during the transition to Server for NIS and Active Directory.

Server for NIS includes an attribute called msSFU30Password, which is the password in the UNIX format. Whenever a Windows user changes the password on Windows, Server for NIS synchronizes the UNIX password by encrypting the new Windows password and storing it in msSFU30Password. By default, passwords are encrypted using the crypt password encryption type. Server for NIS in SFU 3.0 also supports the MD5 encryption type. This allows NIS password to be kept the same as Windows password. User may still change the password on UNIX and his/her UNIX password on Server for NIS will be changed accordingly. However, as mentioned earlier, the Windows password will not be changed upon changing the UNIX password5.

This feature is extremely valuable. Those UNIX users that do not use Windows are unaffected and continue to operate in the usual manner. Those UNIX users that also use Windows machines are encouraged to change their passwords on Windows providing them with an identical password on two platforms.

Administering Server for NIS

Server for NIS provides both a command line tool and a Microsoft Management Console (MMC)-based GUI tool for administering the Server for NIS. It allows starting and stopping the service.

Setting Master vs. Subordinate (Slave) Mode

Server for NIS can be configured to be a master or a subordinate NIS server for a given NIS domain. The GUI and command line administration tools, mentioned above, allow changing the mode of the server for one of the domains that it supports.

Adding and Removing NIS Servers

Server for NIS administration tools allow the adding and deleting of UNIX-based subordinate NIS servers in a domain. Windows-based NIS servers are handled differently. All peer domain controllers have NIS maps due to Active Directory replication. Every domain controller with Server for NIS installed acts as an NIS server for the NIS domains. To add or remove Windows NIS server from a domain, you need to install or uninstall Server for NIS on the domain controller.

Propagating NIS Maps

In UNIX, whenever the administrator or user, using yppasswd, makes changes to NIS source files, NIS maps are updated using make and changed maps are propagated, by using yppush, to subordinate NIS servers. Because Server for NIS supports a variety of Active Directory-based tools for updating subordinate NIS servers, executing yppush upon changes to NIS maps is not possible. Instead, Server for NIS periodically examines Active Directory for any changes to maps in all domains that it supports and sends yppush requests to subordinate servers in each domain for those maps that are changed during that interval6. In addition, administrators can force a check for updates to maps at any time and send yppush requests.

Selecting Encryption Type for a domain

Server for NIS supports the crypt and the MD5 encryption methods. Administrators can select the encryption type applicable using the GUI or the command line administration tools. This can be selected on a per domain basis.

What's new in version 3.0?

In version 3.0 Server for NIS has several improvements, some of which are:

  • Support for netgroup, auto.home and auto.master maps added

  • Support for more than 1024 users per group

  • Support for up to and greater than 64K users per domain

  • Performance of ypmatch has been significantly improved

Deployment Scenarios

Migration from UNIX NIS Servers

Server for NIS is designed to support the following deployment objectives:

  • Easy migration from UNIX NIS servers

  • Staged migration of UNIX NIS domains to Windows 2000-based NIS server

  • Cause little disruption to UNIX-based domains or Windows 2000-based domains

  • Consolidate NIS domains under one domain in Active Directory, and manage using Active Directory

Administrators can take advantage of these features while deploying Server for NIS.

To deploy Server for NIS in a staged migration

  1. Identify the NIS domain that you want to migrate to Server for NIS. Choose the NIS domain that has a number of network objects, such as users or groups, in common with the Windows 2000-based domain you are migrating to.

  2. Determine if you want to create an enterprise-wide NIS domain. This choice is influenced by the resource sharing that is desired between different domains. Determine the name of the intended global NIS domain.

  3. Migrate the NIS maps from the master UNIX-based NIS server to one of the domain controllers in the Windows domain.

  4. Notify the subordinate NIS servers in the domain of the new Windows 2000-based master NIS server7. Turn off the use of the old UNIX-based master NIS server.

  5. If the NIS domain is merged into a new domain, you need to set the NIS clients to use new NIS domain using the domain name command8.

  6. Once migration of the master NIS server is completed, install Server for NIS on other Windows 2000-based domain controllers. Configure UNIX clients to use the new master or subordinate Windows 2000-based server.

  7. Turn off the use of the subordinate UNIX-based NIS servers in a phased manner. You can then install Server for NIS on subsequent Windows domain controllers. Once Server for NIS is installed on a domain controller, it can take the role of another NIS server.

Password Synchronization and Server for NIS

Server for NIS supports two aspects of password synchronization between UNIX and Windows. It allows passwords to be changed from a UNIX-based computer using yppasswd. It also provides Windows 2000 to UNIX password synchronization. By encrypting the Windows password using the specified encryption method and setting it as the UNIX password, Server for NIS achieves a common password for both systems. This is only possible when Server for NIS is used as the master server.

The password synchronization feature is designed specifically for synchronizing passwords. It provides the following features:

  • Synchronization between stand-alone UNIX-based computers, such as those that use /etc/passwd, or those using NIS or NIS+ with Windows. Password Synchronization does not require a UNIX-based network to use Server for NIS as the NIS server.

  • Password Synchronization synchronizes passwords between UNIX and Windows NT 4.0 or Windows 2000

  • Password Synchronization synchronizes both local and domain passwords

  • Password Synchronization supports strong encryption for propagating passwords. Server for NIS uses yppasswd protocol.

If the UNIX-based network is using NIS, Server for NIS will provide a number of features including one-way password synchronization described above. Password synchronization on the other hand may be appropriate where only passwords need to be synchronized.

Summary

Server for NIS is ideal for mixed environments where both UNIX-based and Windows 2000-based domains and computers interact. Server for NIS makes it possible for administrators of such network environments to take advantage of the scalable, dynamic Windows 2000 Active Directory service. Administrators can move the NIS objects, such as passwords, groups, or hosts, over to their equivalents in Active Directory.

As well, passwords set on a UNIX-based server can be synchronized with the passwords of those same users on a Windows 2000-based server. That means users of both environments need only one password—cutting down on administrative responsibilities.

The migration tool for Server for NIS simplifies migration of information. And when the migration is complete, Active Directory-based tools help you easily manage NIS. Best of all, the process of moving the NIS directory over to a Windows 2000 Active Directory environment is transparent to the UNIX user. Thus, no work time is lost, and networks don't suffer downtown.

For More Information

For more information on individual components of Services for UNIX, refer to https://www.microsoft.com/windows/sfu/.

For the latest information on Windows 2000 Server, check out these Web sites:

Reporting Problems

Problems with Microsoft Windows Services for UNIX should be reported by way of the appropriate bug reporting channel and alias. Please make sure to adequately describe the problem so that the testers and developers can reproduce it and fix it. Refer to the Release Notes included on the Windows Services for UNIX distribution media for some of the known issues.

1 Server for NIS implements all procedures necessary for a master NIS server. It does not implement ypxfr procedure used by a slave NIS server. Slave servers must transfer maps using ypcat (yp_all). It implements map replication through Active directory replication.
2 The only exception for data migration is the netgroup map. The netgroup map from 2.0 is not migrated to SFU 3.0 due to a change of schema in version 3.0 for the netgroup map. If you have a netgroup map in SFU 2.0, you can dump the map to a text file using ypcat before upgrading to SFU 3.0 and then migrate the map after upgrading to SFU 3.0.
3 This puts a restriction on Server for NIS that it can be a slave NIS server only if the master NIS server is also a Server for NIS.
4 NisMapName is only used for non-standard maps.
5 This is different from the Password Synchronization feature included in Services for UNIX. Password Synchronization provides complete two-way password synchronization between Windows NT 4.0 or Windows 2000 and UNIX computers. That feature does not require users to run Server for NIS.
6 Server for NIS does not support functionality equivalent to ypxfrd. However, all NIS subordinate servers fall back to use of yp_all for transferring maps and can thus stay synchronized with Server for NIS.
7 This procedure is listed in the Help documentation for Server for NIS.
8 UNIX clients can continue to use the old NIS domain name even if the domain is merged into another domain