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
Estimated lesson time: 30 minutes
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.
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|
|Must contain |
|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.
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|
|Class type||Auxiliary class|
|May contain |
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.
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.
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.
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.
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.
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.
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.
Server for NIS is designed to support the following deployment objectives:
Administrators can take advantage of these features while deploying Server for NIS.
Follow these steps to deploy Server for NIS in a staged migration:
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.
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:
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.
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.