Best Practices for Server for NIS

• Before performing the actual migration, carefully review “Checklist: Migrating NIS Maps to Active Directory Domain Services” in the Identity Management for UNIX Help.
  
  
• Before starting the wizard, decide whether the domain you are migrating should remain a separate domain or should 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 default Do not migrate (log only) option in the NIS Data Migration wizard first, so that Server for NIS tests all migration steps but does not actually migrate data. After analyzing the log files and deciding how you want to handle map conflicts if they occur, run the wizard again, selecting 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 Domain Services (AD DS), 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 you run the wizard with the Log only option selected, it reports only conflicts between NIS maps and AD DS, 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.
  
  

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 ensures that UNIX-based subordinate servers are updated soon after a change is registered on the master server. You can also use the Check for updates now command in the Actions pane of the Identity Management for UNIX snap-in to immediately update subordinate servers.

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

Users should change their NIS password by changing their Windows password. Server for NIS changes 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, Windows and UNIX passwords for the user will not be the same. In addition, yppasswd poses security risks because it transmits the deprecated passwords in plain text. Because the user's old password could also be the user's current Windows password, this can expose the user's Windows password to unauthorized users 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” in the Identity Management for UNIX Help.