Best practices for Server for NIS

  • Article

Applies To: Windows Server 2003 R2

The following information provides best practices for using Server for NIS.

Best practices when migrating a Network Information Service (NIS) domain

  • Before performing the actual migration, carefully review Checklist: NIS migration to Active Directory using the NIS Data Migration wizard.

  • Before starting the wizard, decide whether the domain you are migrating will remain a separate domain or will be merged with another domain on Server for NIS.

  • If you migrate maps separately, you should migrate passwd maps before you migrate group or shadow maps. This ensures that the UNIX passwords will be stored properly.

  • Be sure you know the structure of your nonstandard maps before starting the wizard. In particular, you should know the field separators, key field, file name, and map name. Nonstandard maps are accessed using only one key.

  • Use the Do not migrate (log only) option first, so that the wizard performs all the steps but does not actually migrate the data. After analyzing the log files, run the wizard again, choosing the Migrate and log option.

  • After examining the log, correct any problems before you migrate the data. If the same user name exists in both the Windows and NIS domains, determine whether the duplicate user names represent the person. If not, change the user name of one of the users. If the user names refer to the same person, determine whether the UNIX properties are the same. If not, determine which are correct. You can then preserve the existing entry in Active Directory, or overwrite it with the information in the UNIX map.

  • If a conflict is reported during the actual migration, even though none was reported in the test migration, there might be conflicts within the NIS maps themselves. When the wizard is run with the Log only option, it reports only conflicts between NIS maps and Active Directory, not conflicts within the NIS maps themselves. If a conflict happens during the actual migration, resolve the conflict in the NIS maps and then migrate the NIS data that was not migrated using the command line nis2ad –r yes option.

Make sure that subordinate (slave) servers are kept up-to-date

If your NIS domain is active (that is, changes to the domain occur frequently), you should increase the frequency at which Server for NIS checks for changes. This will ensure that UNIX-based subordinate servers are updated soon after a change is registered on the master server. You can also click Check for updates now to immediately update subordinate servers.

Do not migrate an NIS domain to more than one Windows Active Directory domain

Although you can migrate an NIS domain to computers running Server for NIS in more than one Windows domain, this is strongly discouraged, because changes made in one Windows domain will not be replicated to the other domains.

Discourage users from using yppasswd to change their NIS passwords

Instead, users should change their NIS password by changing their Windows password. Server for NIS will then change the NIS password to match.

Server for NIS does not fully support the yppasswd utility available on UNIX systems. When a user runs yppasswd, Server for NIS changes the user's password in the NIS passwd map. Because yppasswd encrypts the new password before sending it to the NIS master server, however, Server for NIS cannot obtain a plain-text password to set the user's Windows password. Consequently, the Windows and UNIX passwords will no longer be the same. In addition, yppasswd can create security issues because it also sends the old password in plain text. Because the old password could also be the user's Windows password, this might expose the user's Windows password on the network.

Using Password Synchronization, you can provide users with a method for changing their NIS password using the yppasswd command. For more information, see Synchronizing passwords with an NIS domain.