Before starting the Migration 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 Migration 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 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.
During the actual migration, use verbose mode to get all
details of each migration step that took place in migration.
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 Migration 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 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 presents a
security vulnerability 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.