Best Operation for NIS Server

Before performing the actual migration, take a closer look at the "List: migrate NIS ing to Active Directory domain service" in the UNIX identity management help ".

Before starting the wizard, decide whether the domain to be migrated should be an independent domain or be merged with other domains on the NIS server.

If the mappings are migrated separately, first migrate the passwd ing and then migrate the group or shadow ing to ensure that the UNIX Password is properly stored.

Before starting the wizard, make sure that you understand the structure of non-standard ing, especially the field separator, key field, file name, And ing name. Non-standard ing only uses one keyword for access.

First, use the default "do not migrate only records)" option in the NIS data migration wizard, so that the NIS server can test all migration steps, but not actually migrate data. After analyzing the log file and deciding how to handle the ing conflict, run the wizard again and select the "migrate and record" option.

After checking the log, correct all the problems and then migrate the data. If the Windows domain and NIS domain have the same user name, determine whether the duplicate user name represents the same user. If not, change the user name of one of the users. If the user name refers to the same user, check whether the UNIX attributes are the same. If not, determine which one is correct. You can then retain existing entries in Active Directory domain service (ad ds), or overwrite existing entries using information in UNIX ing.

If a conflict is reported during the actual migration, but no conflict is reported during the test migration, there may be a conflict within the NIS ing. When you run the wizard with the "record only" option selected, only the conflict between the NIS ing and the ad ds is reported, rather than the internal conflict of the NIS ing. If a conflict occurs during the actual migration, resolve the conflict in the NIS ing and use the command line nis2ad-r yes option to migrate the unmigrated NIS data.

Keep slave servers up-to-date
If the NIS domain is active, that is, the domain is often changed), you should increase the frequency of NIS Server check changes. This ensures that the UNIX-based slave server is updated quickly after the changes are registered on the master server. You can also use the "check updates now" command in the "actions" pane of the "unix id management" Management Unit to update the slave server immediately.

Do not migrate the NIS domain to Multiple Active Directory Domains
Although the NIS domain can be migrated to multiple computers running the "NIS server" in Windows-based domains, it is strongly recommended not to do so, because changes made in a Windows-based domain are not copied to other domains.

We recommend that you do not use yppasswd to change the NIS password.
Users should change their NIS password by changing their Windows Password. The NIS Server changes the NIS password for matching.

The NIS server does not fully support the yppasswd Utility available on UNIX systems. When you run yppasswd, the NIS Server changes the user password in the NIS passwd ing. However, yppasswd encrypts the new password before it is sent to the NIS master server. Therefore, the NIS server cannot obtain the plain text password to set the user's Windows Password. In this way, the user's Windows Password and UNIX password will not be the same. In addition, yppasswd transmits the discarded password in plain text, which brings security risks. Because your old password may also be your current Windows Password, this may expose your Windows Password to unauthorized users on the network.

You can use the "password synchronization" command to change the NIS password by using the yppasswd command.