Lesson 6: Server for Network Information System | MCSE Training Kit(c) Microsoft Windows 2000 Accelerated 2000

Server for NIS is an implementation of Sun Network Information System (NIS) server in a Windows 2000-based network, which uses Active Directory directory service 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-based computer, 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 enables administrators 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.

After this lesson, you will be able to

Use Active Directory to store NIS map
Manage NIS maps with Active Directory directory service
Deploy Server for NIS

Estimated lesson time: 30 minutes

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 whereas 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 NIS data to be stored 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 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 receive maps associated with that domain only.

Storing NIS maps in Active Directory has a number of advantages, including 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 Lightweight Directory Access Protocol (LDAP) and Active Directory Service Interfaces (ADSI) application programming interface (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 (using 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, as shown in the following table.

Active Directory Class Created by Server for NIS

Object class	Class schema
Common name	MsSFUIpService
Class type	Structural
Subclass of	MsSFUTop
Must contain IpServiceProtocol ipServicePort msSFUName	CN
Inherited must contain from msSFUTop	SyncNISDomain
May contain msSFUAliases	Description
Inherited may contain from msSFUTop	NisMapName

Consider a services map entry such as the following:

 smtp     25/tcp     mail

This is represented as cn=25/tcp, msSFUIpProtocol=tcp, msSFUIpPort=25, msSFUName=smtp, msSFUAliases=mail. In addition to the way this entry is stored, Server for NIS also includes syncNISDomain for each NIS entry/object, which provides the domain in which this object appears. 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 nonstandard 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 msSFUPosixAccount as its auxiliary class (see table below). This allows UNIX attributes to be added to newly created objects of the User class.

MsSFUPosixAccount Class Created by Server for NIS

Object class	Class schema
Common name	MsSFUPosixAccount
Class type	Auxiliary class
Subclass of	Top
May contain syncNisDomain msSFUName uidNumber gidNumber msSFUPassword msSFUHomeDirectory loginShell gecos description posixMemberOf	Uid

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 through 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. Server for NIS allows resolution of the hosts map through DNS providing a functionality that is available in NIS.

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.

 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, which allows 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 msSFUPassword, 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 msSFUPassword. 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 password.

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, which means they have identical passwords on two platforms.

Administering Server for NIS

Server for NIS provides both a command-line tool and a 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 MapsIn 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, 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 interval. In addition, administrators can force a check for updates to maps at any time and send yppush requests.

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.

Follow these steps to deploy Server for NIS in a staged migration:

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.
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.
Migrate the NIS maps from the master UNIX-based NIS server to one of the domain controllers in the Windows domain.
Notify the subordinate NIS servers in the domain of the new Windows 2000-based master NIS server. Turn off the use of the old UNIX-based master NIS server.
If the NIS domain is merged into a new domain, set the NIS clients to use new NIS domain using the domain name command.
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.

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 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 standalone 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.

Lesson 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.

Also, 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, which cuts down on administrative responsibilities.

The migration tool for Server for NIS simplifies migration of information. 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 downtime.