Server for NIS Troubleshooting

  • Article

Applies To: Windows Server 2008 R2, Windows Server 2012

Troubleshooting

What trouble are you having?

  • NIS Data Migration wizard or command-line utility completes successfully, but no maps are added to Server for NIS.

  • Migration conflicts occur even though a test migration succeeded with Do Not Migrate (log only) option selected.

  • A conflict occurs while attempting to migrate more than one user with the same user identifier (UID).

  • NIS Data Migration Wizard or command-line utility reports Network Information Service (NIS) name conflicts with system account.

  • The ypmatch utility on an HP-UX computer fails.

  • The first request to Server for NIS fails.

  • Objects migrated to nonstandard containers do not appear in Active Directory Users and Computers.

  • The ypcat utility sometimes displays incorrect passwd information, but ypmatch provides accurate information.

  • Users with new Windows accounts created by NIS migration cannot log on to Windows and cannot log on to NIS client computers.

  • A user account disabled in Active Directory is not also disabled on UNIX hosts.

  • A newly-migrated user is not authenticated by a UNIX client.

NIS Data Migration wizard or command-line utility completes successfully, but no maps are added to Server for NIS.

Cause:   The Do not migrate (log only) option was selected.

Solution:   Because migration is irreversible, the Do not migrate (log only) option is the default. You can override the default when running the wizard by selecting either Overwrite or Preserve on the Manage Migration Conflicts page of the NIS Data Migration Wizard. To override the default when you are running the command-line utility to migrate instead (Nis2ad.exe), specify the -m option on the command line.

Migration conflicts occur even though a test migration succeeded with Do Not Migrate (log only) option selected.

Cause:   If data conflicts in the Network Information Service (NIS) maps you are migrating, the conflict might not be reported until an actual migration is complete, because Server for NIS reports only conflicts between NIS maps and Active Directory.

Solution:   Resolve the conflicts in the original NIS maps and then migrate the NIS data that was not migrated by using the nis2ad   –r yes command-line option.

A conflict occurs while attempting to migrate more than one user with the same user identifier (UID).

Cause:   The NIS Data Migration Wizard cannot migrate users that have the same UID. Only the first user is successfully migrated.

Solution:   Make sure all users have unique UIDs before migrating NIS maps.

NIS Data Migration Wizard or command-line utility reports Network Information Service (NIS) name conflicts with system account.

Cause:   A user name in NIS is identical to a reserved Windows account name. Reserved account names include such names as Network, System, Users, and Computers.

Solution:   Resolve the conflict by renaming the UNIX-based account, and then remigrate the entry by using the nis2ad   –r yes command-line option.

The ypmatch utility on an HP-UX computer fails.

Cause:   A map contains keys in mixed case. The HP-UX operating system converts all keys to lower case before sending the NIS request. This is an issue with the HP-UX operating system that is beyond the control of Server for NIS.

Solution:   Convert keys to lower case before migrating them.

The first request to Server for NIS fails.

Cause:   If the number of objects migrated to Server for NIS was very large, Server for NIS can take a long time to build the map cache.

Solution:   Make the request again after waiting 30 minutes or more. Subsequent requests might succeed.

Objects migrated to nonstandard containers do not appear in Active Directory Users and Computers.

Cause:   Active Directory Users and Computers does not display nonstandard containers by default.

Solution:   On the View menu, click Advanced Features .

The ypcat utility sometimes displays incorrect passwd information, but ypmatch provides accurate information.

Cause:   Server for NIS data has not yet updated the map cache after data in Active Directory has changed. The ypcat utility takes its information from this cache; the ypmatch utility takes its information directly from Active Directory.

Solution:   Decrease the refresh interval between updates to the map cache, or check that the updates have been cached immediately upon making changes in Active Directory. For more information, see Changing the frequency of map updates and Propagate changed maps now.

Users with new Windows accounts created by NIS migration cannot log on to Windows and cannot log on to NIS client computers.

Cause:   To avoid exposing new accounts to misuse, the migration wizard disables the new accounts.

Solution:   After completing migration, enable new accounts only when users are ready to use them. For security reasons, it is recommended that you change the password on all newly created Windows user accounts to temporary values. Notify users of the temporary passwords and instruct them to change their Windows passwords as soon as possible. Inform them of how often map changes are propagated (see Sending periodic map updates to subordinate NIS servers) so they will know when they can expect their UNIX passwords to be updated.

A user account disabled in Active Directory is not also disabled on UNIX hosts.

Cause:   Windows and UNIX accounts must be disabled separately because the mechanism for doing so is fundamentally different, and the method for disabling UNIX accounts differs based on system version and administrator preference.

Solution:   After disabling an account by using Active Directory Users and Groups, you must also disable or lock the corresponding UNIX account by the usual means (such as by changing the password to a value unknown to the user, by adding a special character to the user's password in the passwd file, by changing the account's login shell, or all three).

A newly-migrated user is not authenticated by a UNIX client.

Cause:   Possible configuration errors on the client computer.

Solution:   Perform the following troubleshooting steps for the indicated client operating system.

On a client computer running the Solaris operating system:

  • Ensure that the Windows-based computer that is running Server for NIS is added to the /etc/hosts file on the Solaris client. Then run the ypwhich command on the client and check that it shows the correct Windows-based computer.

  • Ensure that the /etc/nsswitch.conf file contains an entry similar to the following:

    passwd:     files[NOTFOUND=continue] nis

  • Ensure that the user is not listed in the local passwd file.

  • Add the following to the end of the /etc/passwd file on the client computer:

    +::::::

  • Ensure that shadow files, if any, are also migrated to Server for NIS.

  • Ensure that the ypcat password command does not show X in the user's password field.

  • Ensure that the file /var/yp/securenets is configured to allow authentication from the client computer.

On a client computer running the Linux operating system

  • Ensure that the Windows server running Server for NIS has been added to the /etc/hosts file on the client computer and that the ypwhich command on the client computer correctly shows the name of the Windows-based computer.

  • Ensure that the USENIS entry in the /etc/sysconfig/authconfig is set to USENIS=yes .

  • Ensure that the nsswitch.conf file is properly configured.