Windows Services for UNIX provides a full Active-Directory based implementation of the Network Information Service (NIS). NIS is used by UNIX-based computers to provide a centralized database for a variety of information about the network. NIS is also used as a central account database for user and group information and authentication. NIS is based on a master/subordinate server relationship, where subordinate servers can read the available information and authenticate based on this relationship. However, the actual changes must take place on the master NIS server and these changes are propagated to the subordinate NIS servers.
Windows Services for UNIX version 3.0 uses Microsoft Installer for installation. As a result, you can install individual modules of the product from the command line. If previous components of Windows Services for UNIX have been installed, you must include these components in the addlocal parameter of the installation command line, separated by a comma (,). If you do not do so, these products are removed during the installation of Server for NIS. You can install Server for NIS only on an Active Directory domain controller. Server for NIS makes changes to your Active Directory schema by adding objects to support NIS. These changes to the schema are permanent and cannot be rolled back.
To install Server for NIS from the command line:
Log on to a Windows 2000-based domain controller by using a Schema Admin level account.
Click Start, click Run, type cmd, and then click OK.
Insert the Windows Services for UNIX version 3.0 CD in the CD drive. (This example uses drive D.)
From the command prompt, run the following command to install Server for NIS:
Note: The addlocal parameter to msiexec show above is case and space sensitive. Installation will fail if the exact case above is not followed.
Default install path is "\SFU".Note: Services for UNIX should be installed in a directory without spaces in the path to prevent problems with some components of SFU. Microsoft recommends that you install SFU to the default directory.
To include the product key in the command line, add PidKey=key, where key is the 25 character product keywithout the dashes.Note: If installing from a telnet prompt, where no GUI is available, or via a script, use the following command line instead: msiexec /I D:\sfusetup.msi /q addlocal="NIS" pidkey="key" [targetdir="install path"]Note: Server for NIS can also be installed using the graphical installation wizard. The installation option for Server for NIS will only be available when the installation wizard is run on an Active Directory Domain Controller.
The following troubleshooting tips may help resolve problems with a Server for NIS installation.
The ypmatch utility on an HP-UX computer fails.Cause: A map contains keys in mixed case. HP-UX converts all keys to lowercase before sending the NIS request. This is an issue with HP-UX that is beyond the control of Server for NIS.
Solution: Convert keys to lowercase 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 Windows 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.
After upgrading to version 3.0, netgroup data no longer appears in Active Directory.Cause: Windows Services for UNIX does not preserve netgroup data when upgrading Active Directory schema.
Solution: Use the Server for NIS Migration Wizard to migrate the netgroup data from the map source file originally used to migrate the data.
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 interval between map updates, or check updates immediately upon making changes in Active directory.
Users with new Windows accounts created by NIS migration cannot log on to Windows and cannot log on NIS client computers.Cause: To avoid exposing new accounts to misuse, the Migration Wizard sets the password of the new accounts to a random value. This password then is propagated to NIS clients.
Solution: Immediately after completing migration, 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 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 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).