Best practices when migrating a Network Information Service (NIS) domain
- 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
- 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.
Keep subordinate servers 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 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.
Do not migrate an NIS domain to more than one Active Directory domain
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.
Discourage users from using yppasswd to change NIS passwords
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.