Identity Management for UNIX: Welcome

Identity Management for UNIX

Identity Management for UNIX makes it easy to integrate users of Windows operating systems into existing UNIX environments. It provides manageability components that simplify network administration and account management across both platforms.

With Identity Management for UNIX, you can:

  • Manage user accounts and passwords on Windows and UNIX systems using Network Information Service (NIS).

  • Automatically synchronize passwords between Windows and UNIX operating systems.

For details about Identity Management for UNIX, see Identity Management for UNIX overview. For information about installable components, see Identity Management for UNIX components.

In this section

  • Identity Management for UNIX overview

  • Identity Management for UNIX components

  • Connect to a computer you want to manage

  • Identity Management for UNIX: Server for NIS

  • Identity Management for UNIX: Password Synchronization

  • Accessibility Features of Identity Management for UNIX


Identity Management for UNIX overview

Identity Management for UNIX overview

Identity Management for UNIX makes it easy to integrate computers running Windows into your existing UNIX enterprise. Active Directory network administrators can use Server for NIS to manage Network Information Service (NIS) domains, and Password Synchronization automatically synchronizes passwords between Windows and UNIX operating systems.

With minor differences, Identity Management for UNIX is compliant with Internet Engineering Task Force (IETF) standard Request for Comments (RFC) 2307, meaning that your network's password and NIS attributes can be resolved by the Lightweight Directory Access Protocol (LDAP). For more information about RFC 2307, including a complete list of attributes specified in the RFC 2307 schema, see the RFC database Web site.

Identity Management for UNIX: Server for NIS completely integrates UNIX NIS networks with Windows Active Directory. Identity Management for UNIX includes an easy-to-use wizard that a Windows domain administrator can use to export NIS domain maps to Active Directory entries. Once this is done, an Active Directory domain controller running Server for NIS becomes the master server for the NIS domain.

Identity Management for UNIX: Password Synchronization automatically changes a user password on the UNIX network when the user changes his or her Windows password, and vice versa. This allows users to maintain just one password for both networks.

Password Synchronization supports Sun Solaris version 8 running on x86-based computers and Scalable Processor Architecture (SPARC)–based computers; Solaris version 9 running on SPARC–based computers; Hewlett Packard HP-UX version 11i; IBM AIX version 5L 5.2; and Red Hat Linux versions 8 and 9 running on x86-based computers and 64-bit AMD-based computers. Server for NIS should work with any operating system or product that uses LDAP.


Identity Management for UNIX components

Identity Management for UNIX components

You can use the Identity Management for UNIX installation program to install the following:

  • Administration components. Provides utilities for administering Identity Management for UNIX.

  • Password Synchronization. Password Synchronization makes it easy for users to maintain one password for Windows domains and UNIX systems, synchronizing them when one of them changes.

  • Server for NIS. Enables a Windows-based server to function as a Network Information Service (NIS) server, integrating NIS domains with Active Directory and giving Windows Active Directory administrators the ability to manage Windows and NIS domains together. Server for NIS can be installed only on an Active Directory domain controller.


Connect to a computer you want to manage

To connect to the computer you want to manage

  1. Open Identity Management for UNIX.

  2. Do one of the following:

    • Right-click the Microsoft Identity Management for UNIX node at the top of the hierarchy pane, and then click Connect to another computer. On the Select Computer dialog box, select Another Computer.

    • In the Actions pane, click Connect to another computer, and then select Another Computer.

    • With the Microsoft Identity Management for UNIX node at the top of the hierarchy pane highlighted, click Connect to another computer on the Action menu. On the Select Computer dialog box, select Another Computer.

  3. In the box, type the name of the computer to use, or click Browse.

  4. When you have identified or found the computer you want, click OK.

Notes
  • You must be logged on with an account that has administrator privileges on the remote computer.
  • There is no command-line method for this procedure.
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.


Identity Management for UNIX: Server for NIS

Server for NIS

Server for NIS enables a Microsoft Windows–based Active Directory domain controller to administer UNIX Network Information Service (NIS) networks.

  • Before you start using Server for NIS, see Server for NIS Checklists.

  • For tips about using Server for NIS, see Best practices for Server for NIS.

  • For help with specific tasks, see How To.....

  • For general background information, see Concepts of Server for NIS.

  • For detailed reference information about command utilities for managing Server for NIS, see Server for NIS command-line utilities.

  • For problem-solving instructions, see Server for NIS Troubleshooting.


Server for NIS Checklists

Checklists

  • Checklist: Setting up Server for NIS

  • Checklist: NIS migration to Active Directory using the NIS Data Migration wizard


Checklist: NIS migration to Active Directory using the NIS Data Migration wizard

Checklist: NIS migration to Active Directory using the NIS Data Migration wizard

Step Reference

Read more about Network Information Service (NIS) migration.

Understanding NIS Data Migration

Back up your Windows domain controllers, or use a test domain controller.

Windows documentation

Log on as a member of the Domain Admins group.

Windows documentation

Identify the NIS domain to migrate and how it will be migrated, keeping in mind the following:

  • You can migrate only one NIS domain at a time, but you can merge the NIS domain with a previously migrated NIS domain.

  • If you do not merge the domain, you can preserve the existing domain name or create a new name for the migrated domain.

  • You should migrate an NIS domain to only one Active Directory domain.

NIS administrator

Make sure that the source files for the NIS maps that you want to migrate can be accessed by the computer running the NIS Data Migration wizard. (NIS map source files are the plain text files from which the NIS map databases are compiled.) You can make the files available to the Windows-based computer by using network file system (NFS), or by copying them to the Windows-based computer through File Transfer Protocol (FTP). All standard and nonstandard map source files should be in the same directory.

Determine which standard NIS maps to migrate, and the directory paths to the map source files, keeping in mind the following:

  • You can migrate maps in steps, that is, migrate one map first, then another, and so on.

  • You should migrate the passwd map before migrating other maps (such as group or shadow maps) that rely on it.

  • You must migrate the networks map before migrating netmasks.

NIS administrator Managing standard and nonstandard NIS maps

Determine any nonstandard NIS maps to migrate, their formats, and the directory paths to their map source files. All standard and nonstandard map source files should be in the same directory.

NIS administrator

Examine NIS map source files for multiple entries having the same primary key (for example, more than one user with the same user identifier (UID) in the passwd file) and eliminate the duplicate primary keys.

NIS administrator

Determine Active Directory containers to which you will migrate the NIS domain.

Decide on the strategy to migrate using one of the following two alternatives. If there are conflicts between the existing map entry and the entry being migrated during the migration process, you can choose one of the following methods:

  • Overwrite the existing entry with data from the entry being migrated.

  • Preserve data from the existing entry and ignore the entry being migrated.

  • Resolve conflicts by changing the Windows account name in Active Directory. If objects of different types have the same name, the names of both objects are changed before the data is migrated.

Best practices for Server for NIS

Determine whether you want to run the wizard first without migrating to examine all events that will take place during migration (recommended), or migrate all data the first time the wizard is run. The migration wizard can be configured to log all the migration steps without actually migrating the data to Active Directory.

Migrate NIS maps to Active Directory on a computer running Windows Server and Active Directory.

Migrate NIS domains

Review the log files after migration for errors or conflicts. Resolve log conflicts and migrate the resolved entries again.

Resolving migration conflicts

Configure any UNIX NIS subordinate (also known as slave) servers to use Server for NIS as the master NIS server.

Configuring a UNIX NIS server to use Server for NIS as the master server

Configure any UNIX NIS client computers to use Server for NIS as the master NIS server.

Configuring UNIX clients to use Server for NIS as the master server

Set the passwords of new Windows user accounts (created as a result of the NIS migration) to a known, temporary value, inform the users of the temporary password and instruct them to change their Windows password as soon as possible.


Checklist: Setting up Server for NIS

Checklist: Setting up Server for NIS

Step | Reference
Read about Server for NIS. | Concepts of Server for NIS
Migrate Network Information Service (NIS) maps to Active Directory. | Checklist: NIS migration to Active Directory using the NIS Data Migration wizard
Set how often maps are propagated to subordinate (also known as slave) NIS servers. | Change the frequency of map updates to UNIX subordinate (slave) NIS servers
Review and, if needed, add or remove UNIX subordinate servers in the domain. | Add or remove UNIX subordinate (slave) servers
As needed, install Server for NIS on other domain controllers, which will automatically be configured as subordinate servers. Install Password Synchronization on all other domain controllers. This will ensure that when a user's password is changed, the password will be updated across the domain. Server for NIS will receive the updated passwords when the data is replicated to the domain controller. | Install Server for NIS Synchronizing passwords with an NIS domainSynchronizing passwords with an NIS domain


Best practices for Server for NIS

The following information provides best practices for using Server for NIS.

Best practices when migrating a Network Information Service (NIS) domain

  • Before performing the actual migration, carefully review Checklist: NIS migration to Active Directory using the NIS Data Migration wizard.

  • Before starting the 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 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 Do not migrate (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.

  • 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 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 command line 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 can create security issues 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.


How To....

  • Install Server for NIS

  • Start Server for NIS

  • Stop Server for NIS

  • Add or remove UNIX subordinate (slave) servers

  • Change a subordinate (slave) server to a master server

  • Manage NIS Maps


Install Server for NIS

To install Server for NIS

  1. Click Start, click Control Panel, and then click Add or Remove Programs.

  2. Click Add/Remove Windows Components.

  3. When the Windows Components Wizard opens, fill the Active Directory Services check box.

  4. With Active Directory Services highlighted, click Details.

  5. When the Active Directory Services dialog box opens, fill the Identity Management for UNIX check box.

  6. With Identity Management for UNIX highlighted, click Details.

  7. When the Identity Management for UNIX dialog box opens, fill the Server for NIS check box.

    Because Administration Components are required for Server for NIS operation, Administration Components are automatically selected for installation when you select Server for NIS.

  8. Click OK.

    The Windows Components Wizard begins installing the Identity Management for UNIX components you selected.

  9. If you are prompted to locate files required for Server for NIS installation, insert the Windows Server 2003 R2 product CD, or browse to the network location of your Windows Server 2003 R2 installation files.

  10. If NIS map data compatible with Windows Services for UNIX 3.5 is stored in Active Directory, the Server for NIS installation process automatically migrates the data, and uses it to populate Server for NIS maps.

  11. When installation completes, restart your computer to begin working with Server for NIS.

Notes
  • To open Add or Remove Programs, click Start, point to Control Panel, and then click Add or Remove Programs.
  • Server for NIS can be installed only on an Active Directory domain controller.

See Also

  • Installing and uninstalling Server for NIS


Start Server for NIS

To start Server for NIS

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Right-click Server for NIS, and then click Start.

Note

To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.

Using a command line

  • At a command prompt, type:

    nisadmin [server] start [–u user [–p password]]

Argument | Description
server | The name of the server you want to start.
user | The name of the user who has administrative permissions on the server to be started, if different from the current user.
password | The password of the user who has administrator permissions on the server to be started, if different from the current user. If you type a user name but omit the password, you will be prompted for the password.
Notes
  • To view the complete syntax for this command, at a command prompt, type the following:
  • nisadmin /?

See Also

  • nisadmin
  • Starting and stopping Server for NIS
  • Connect to the computer you want to manage


Stop Server for NIS

To stop Server for NIS

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Right-click Server for NIS, and then click Stop.

Note

To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.

Using a command line

  • At a command prompt, type:

    nisadmin [server] stop [–u user [–p password]]

Argument | Description
server | The name of the server you want to stop.
user | The name of the user who has administrator permissions on the server to be stopped, if different from the current user.
password | The password of the user who has administrator permissions on the server to be stopped, if different from the current user. If you type a user name but omit the password, you will be prompted for the password.
Notes
  • To view the complete syntax for this command, at a command prompt, type:
  • nisadmin /?

See Also

  • nisadmin
  • Starting and stopping Server for NIS


Add or remove UNIX subordinate (slave) servers

To add or remove UNIX subordinate (slave) servers

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. In the console tree, expand Server for NIS and view the list of Network Information Service (NIS) domains.

  4. Click the domain you want to modify.

  5. In the details pane, click the NIS Servers tab, and then do one of the following:

    • To add a subordinate (also known as slave) server, in Server Name, type the name of the server you want to add, and then click Add.

    • To remove a subordinate server, in Servers and modes, click the server you want to remove, and then click Remove.

  6. To save the settings, click Apply.

Note

To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.

Using a command line

  • To add a UNIX subordinate (slave) server, at a command prompt, type:

    nismap add -e " NewSubordinate " -a NISDomain ypservers

    To remove a server, at a command prompt, type:

    nismap del -k " NewSubordinate " -a NISDomain ypservers

Argument | Description
NewSubordinate | The new UNIX Network Information Service (NIS) server to be added to the NIS domain.
NISDomain | The name of the NIS domain.
Notes
  • To view the complete syntax for this command, at a command prompt, type:
  • nismap /?

See Also

  • nisadmin
  • Master and subordinate (slave) modes
  • Connect to a computer you want to manage


Change a subordinate (slave) server to a master server

To change a subordinate (slave) server to a master server

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. In the console tree, click Server for NIS and view the list of Network Information Service (NIS) domains.

  4. Select the domain you want to modify.

  5. In the details pane, click NIS Servers, select the Windows server you want to make the new master server, and then click Promote.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • Only an Active Directory domain controller can be promoted to be the master server.
  • When you change a subordinate server to a master server, the previous master server automatically changes to a subordinate server.

Using a command line

Do one of the following:

  • To change a master server to a subordinate server, at a command prompt, type:

    nisadmin [server] mkslave –m newMaster–d domainName –u username–p password

  • Or, to change a subordinate server to a master server, at a command prompt, type:

    nisadmin [server] mkmaster –d domainName–u username –p password

Argument | Description
server | The domain controller server that is hosting Active Directory. If not specified, the current server is used.
newMaster | The name of the new master server, required for the mkslave command.
domainName | The name of the domain for which the change is being made.
username | The name of the user who has administrator permissions on the server to be changed, if different from the current user.
password | The password for the user who has administrator permissions on the server to be changed. If the password is not supplied, you will be prompted for it.
Notes
  • To view the complete syntax for this command, at a command prompt, type nisadmin /?.
  • Only an Active Directory domain controller can be promoted to be the master server.

See Also

  • Master and subordinate (slave) modes
  • nisadmin
  • Connect to a computer you want to manage


Manage NIS Maps

Manage maps

  • Migrate NIS domains

  • Add a group to an NIS domain

  • Set the encryption method for a domain

  • Change the frequency of map updates to UNIX subordinate (slave) NIS servers

  • Propagate selected maps now

  • Propagate changed maps now

  • Use ypmatch to view an entry in an NIS map

  • Use ypcat to print values in an NIS map

  • Edit Maps

  • Manage NIS Users

  • Manage NIS Groups

  • Manage NIS Computers


Migrate NIS domains

To migrate NIS domains

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open the NIS Data Migration wizard.

  2. Follow the step-by-step directions in the wizard.

Notes
  • To start the NIS migration wizard, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX. Click Server for NIS in the navigation pane. With Server for NIS highlighted in the navigation pane, click the NIS Data Migration Wizard command in the Actions pane. You can also click NIS Data Migration Wizard on the Action menu, or right-click Server for NIS, then click NIS Data Migration Wizard on the shortcut menu.
  • Password file entries with names longer than eight characters will not be migrated.
  • Windows user accounts created as a result of the migration are disabled. After performing the migration, you must enable the accounts. For security reasons, it is recommended that you assign a temporary password to these accounts and instruct the affected users to change their Windows password as soon as possible.

Using a command line

The following arguments are required.

Argument | Description
-y UNIXNISDomain | Specifies the name of the Network Information Service (NIS) domain that contains the map to migrate.
-a ActiveDirectoryNISDomain | Specifies the NIS domain name in Active Directory.
MapfileToMigrate | Specifies the name of the NIS map source file to migrate. NIS map source files are the plain text files from which the NIS map databases are compiled.

The nis2ad utility accepts the following options.

Option | Description
-m | Perform the migration. If this option is omitted, the program finds and reports conflicts but does not actually perform the migration.
-c FileName | Specifies the file where conflict details are written. Uses a default file (%sfudir%\nis\conflicts.log) if not specified.
-t TargetContainer | Specifies the target container name. Applicable only when creating a new NIS domain. If not specified, uses the default or uses the container of the target domain.
-f FileName | Specifies the name of the log file. If not specified, nis2ad uses a default file (%sfudir%\nis\nis2ad.log).
-r yes|no | Replace object in Active Directory with object being migrated. Default is no.
-n | Resolves conflicts by changing the Windows account name in Active Directory. If objects of different types have the same name, the name of both objects is changed before the data is migrated.
-p Password | If needed and if not specified, the user will be prompted.
-d Directory | Specifies the path of the directory that contains NIS map source files.
-s Server | Specifies the domain controller server hosting Active Directory. Otherwise use the current server.
-u User | Specifies the name of the user having administrator privileges on this computer. If not specified, nis2ad uses the current user.
Notes
  • To view the complete syntax for this command, at a command prompt type:
  • nis2ad /?
  • You can migrate only one map at a time using nis2ad. To migrate more than one map at a time, use the NIS Data Migration wizard.
  • Password file entries with names longer than eight characters will not be migrated.
  • Windows user accounts created as a result of the migration will be disabled. After performing the migration, you must enable the accounts. For security reasons, it is recommended that you assign a temporary password to these accounts and instruct the affected users to change their Windows password as soon as possible.
  • Even if you specify another user by using the -u option, the currently logged on user must have write permissions for the folder that will contain the log and conflict files. If necessary, modify the permissions on the folder to grant write access to the user who will be running the nis2ad utility before running the utility.

See Also

  • Understanding NIS Data Migration
  • nis2ad


Add a group to an NIS domain

To add a group to an NIS domain

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the group you want to add to the NIS domain, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the NIS Domain list, click the domain to which you want to add the group.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The name of the group must comply with UNIX naming conventions. It must contain only lowercase alphabetic and numeric characters, no more than eight characters, and at least one alphabetic character. It must not include either a colon (:) or a newline character.
  • A group identifier (GID) is automatically assigned to the group. If your NIS domain has special requirements for GID values, you can change the assigned value.

See Also

  • Managing NIS groups
  • Change a group's ID (GID)
  • Add or remove members of a group
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Set the encryption method for a domain

To set the encryption method for a domain

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. In the console tree, expand Server for NIS and view the list of NIS domains.

  4. Select the domain for which you want to set an encryption method.

  5. In the details pane, click the Maps tab.

  6. In the UNIX passwords are encrypted using list, click the encryption method used by all UNIX computers in the domain.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • You can select the MD5 encryption method for a UNIX domain that consists exclusively of computers running Linux and using MD5 encryption. Domains that contain one or more computers using the crypt algorithm or that run any other operating system must use crypt. Although Linux versions 6.2 and later support MD5 encryption, Identity Management for UNIX is not supported for versions of Linux prior to version 8.

Using a command line

  • At a command prompt, type:

    nisadmin [computer] encryptiontype -d domain {crypt | md5} [-u usr [-p pword]]

Argument | Description
computer | Specifies the remote computer you want to administer. You can specify the computer using a WINS or DNS name, or by Internet Protocol (IP) address.
domain | Specifies the name of the domain for which the change is being made.
usr | Specifies the user name of the user whose credentials are to be used. It might be necessary to add the domain name to the user name in the form domain\username.
pword | Specifies the password of the user specified using the -u option. If you specify the -u option but omit the -p option, you are prompted for the user's password.
Notes
  • To view the complete syntax for this command, at a command prompt, type: nisadmin /?
  • You can select the MD5 encryption method for a UNIX domain that consists exclusively of computers running Linux and using MD5 encryption. Domains that contain one or more computers using crypt or that run any other operating system must use crypt. Although Linux versions 6.2 and later support MD5 encryption, Identity Management for UNIX is not supported for versions of Linux prior to version 8.
  • Password encryption can only be set to one encryption method at a time. Changing the encryption method invalidates user passwords. All passwords must be reset if the encryption method is changed.

See Also

  • Synchronizing user passwords
  • Connect to a computer you want to manage


Change the frequency of map updates to UNIX subordinate (slave) NIS servers

To change frequency of map updates to UNIX subordinate (slave) NIS servers

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Server for NIS.

  4. In the details pane, type the update interval you want, and then click Apply.

Note

To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.

Using a command line

  • At a command prompt, type:

    nisadmin config pushint=[[days:]hh:]mm [-s Server] [-u User] [-p Password]

Argument | Description
[[days:]hh:]mm | Specifies the interval at which the service checks changes to Network Information Service (NIS) maps in Active Directory and propagates them to secondary NIS servers for all domains, in days, hours, and minutes. If hh is specified, hh must be in the range 0–23 and mm must be in the range 0–59.
Server | The master server for the domain.
User | The name of the user who has administrative privileges on the server to be started, if different from the current user.
Password | The password of the user who has administrative privileges on the server to be started, if different from the current user. If you type a user name but omit the password, you will be prompted for the password.
Notes
  • •To view the complete syntax for this command, at a command prompt, type:
  • nisadmin /?

See Also

  • Sending periodic map updates to subordinate (slave) NIS servers
  • nisadmin


Propagate selected maps now

To propagate selected maps now

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. In the console tree, expand Server for NIS and view the list of NIS domains.

  4. Select the domain of interest.

  5. In the details pane, click the Maps tab.

  6. In the NIS maps in this domain list, click the maps to propagate, and then click Propagate. To select more than one map, press and hold the CTRL key while clicking the maps.

Note

To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.

Using a command line

  • At a command prompt, type:

    yppush [-d ActiveDirectoryNISDomain] [-q] [-t Timeout] [-h Hosts] MapName

Argument | Description
-d ActiveDirectoryNISDomain | Network Information Service (NIS) domain name in Active Directory.
-q | Quiet mode. Do not wait for response from subordinate (slave) servers and do not report errors.
-t Timeout | The number of seconds to wait for a response from the subordinate server before sending the next request. Must be greater than zero. The default value is 30.
-h Hosts | The hosts to notify of changes. Default is all subordinate servers in the domain. Can be used multiple times for more than one computer.
MapName | The name of the NIS map to be transferred.
Notes
  • This command propagates a single map. Run the command again to propagate additional maps.
  • The yppush command pushes map data only from the Windows-based NIS master server to UNIX-based NIS subordinate servers. It does not push map data to NIS subordinate servers running Windows operating systems. Active Directory updates Windows-based NIS subordinate servers.
  • To view the complete syntax for this command, at a command prompt type:
  • yppush /?

See Also

  • Pushing map updates immediately
  • yppush
  • Connect to a computer you want to manage


Propagate changed maps now

To propagate changed maps now

  • Using the Windows interface

  • Using a command line

Using the Windows interface

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Server for NIS.

  4. Click Check Now.

Notes
  • ReplaceThisText
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.

Using a command line

  • At a command prompt, type:

    nisadmin [server] syncall [–u user [–p password]]

Argument | Description
syncall | Propagate all maps.
server | The name of the server where the maps are stored.
user | The name of the user who has administrator permissions on the server, if different from the current user.
password | The password of the user who has administrator permissions on the server, if different from the current user. If you type a user name but omit the password, you will be prompted for the password.
Notes
  • The nisadmin syncall command propagates maps only on UNIX-based NIS subordinate servers. It does not propagate maps on NIS subordinate servers running Windows operating systems. Active Directory updates Windows-based NIS subordinate servers.
  • To view the complete syntax for this command, at a command prompt, type:
  • nisadmin /?

See Also

  • nisadmin
  • Pushing map updates immediately


Use ypmatch to view an entry in an NIS map

To use ypmatch to view an entry in an NIS map

  • At a command prompt, type:

    ypmatch [-d Domain] [-h HostName] [-t] [-k] Key [Key ...] MapName

    or

    ypmatch -x

Argument | Description
Domain | A domain other than the default domain.
HostName | The name of the Network Information Service (NIS) server to which you want to send the request.
-t | Inhibits translation of nickname to map name.
-k | Prints a key followed by a colon before printing the value of the key. This is useful only if your keys do not have duplicate values, and you do not have an unreasonable number of keys to clutter the output.
Key | The key for which you want to print the value.
MapName | The name or the nickname of a map.
-x | Lists the nicknames as specified by the MapName parameter.
Notes
  • There is no Windows interface method for this procedure.
  • To view the complete syntax for this command, at a command prompt, type:
  • ypmatch /?

See Also

  • ypmatch


Use ypcat to print values in an NIS map

To use ypcat to print values in an NIS map

  • At a command prompt, type:

    ypcat [-k] [-d DomainName] [-t] [-h NISServer] MapName

    or

    ypcat -x

Argument | Description
-k | Displays keys and their values.
DomainName | Searches the specified domain for the specified map.
-t | Forces the ypcat command to bypass the nickname translation table and search only for the map specified by the MapName parameter.
NISServer | Name of the Network Information Service (NIS) server where the map is stored.
MapName | The name of the map to be listed.
-x | Lists the nicknames as specified by the MapName parameter.
Notes
  • There is no Windows interface method for this procedure.
  • To view the complete syntax for this command, at a command prompt, type:
  • ypcat /?

See Also

  • ypcat


Edit Maps

Edit maps

  • Edit passwd, group, and host map entries using Active Directory Users and Computers

  • Edit standard and nonstandard map entries using the command line interface

  • Create the structure of a nonstandard map


Edit passwd, group, and host map entries using Active Directory Users and Computers

To edit passwd, group, and host map entries using Active Directory Users and Computers

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Active Directory domain that contains the map you want to edit, and then do one of the following:

    • To edit passwd or group maps, click Users.

    • To edit the host map, click Computers.

  3. Double-click the user or computer whose properties you want to edit.

  4. Click the UNIX Attributes tab.

  5. In the boxes provided, edit the properties you want to change.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Important

Do not use Active Directory Users and Computers to modify attributes of special users and groups, that is, users and groups with user identifiers (UIDs) or group identifiers (GIDs) of less than 100. If you do, the data returned by Server for NIS will be incorrect for those users and groups. Use the procedure described in "Using a command line" instead.

Note

To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Edit standard and nonstandard map entries using the command line interface
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Edit standard and nonstandard map entries using the command line interface

To edit standard and nonstandard map entries using the command line

At a command prompt, do one of the following:

  • To add a user to a passwd map, type:

    nismap add –e " passwdEntry " –a nisDomain passwd

  • To modify a user in a passwd map, type:

    nismap mod –e " passwdEntry " –k username –a nisDomain passwd

  • To delete a user from a passwd map, type:

    nismap del –k username –a nisDomain passwd

  • To add a group to a group map, type:

    nismap add –e " groupEntry " –a nisDomain group

  • To modify a user from group map, type:

    nismap mod –e " groupEntry " –k groupName–a nisDomain group

  • To delete a user from group map, type:

    nismap del –k groupName –a nisDomain group

Argument | Description
passwdEntry | An entry from the passwd map.
nisDomain | The Network Information Service (NIS) domain.
username | The name of the user.
groupEntry | An entry from the group map.
groupName | The name of the group to which the user belongs.
Notes
  • To view the complete syntax for this command, at a command prompt, type:
  • nismap /?
  • When you use nismap to delete a user, group, or host object, only the UNIX attributes of the object are deleted. To delete the object from Active Directory, use the Active Directory administration tools.

See Also

  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • nismap
  • Managing standard and nonstandard NIS maps


Create the structure of a nonstandard map

To create the structure of a nonstandard map

  • At a command prompt, type:

    nismap create –i fieldNumber –g "separator" mapName

Argument Description

fieldNumber

The number of the field that contains the key to the map.

" separator "

The character used to separate fields, in quotation marks. To specify a space as a separator, enclose the space in double quotation marks (" "). For example:

nismap create –i 1 –g " " Phones

creates a map called Phones in which the key field is the first field and the separator character is a space. Other white-space characters, such as tab, are also accepted.

mapName

The name of the map.

Notes

Notes
  • There is no Windows interface method for this procedure.
  • After this structure is created, there is no way to remove it.
  • This structure applies to all NIS domains, so it is important to ensure that the format is consistent across all NIS domains.
  • Do not use the hash character (#) as a field separator because this character is used in standard maps to mark the beginning of a comment.
  • To view the complete syntax for this command, at a command prompt, type:
  • nismap /?

See Also

  • nismap
  • Managing standard and nonstandard NIS maps


Manage NIS Users

Manage NIS users

  • Add a user to an NIS domain

  • Change a user's ID (UID)

  • Change a user's default shell

  • Change a user's home directory


Add a user to an NIS domain

To add a user to an NIS domain

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the user you want to add to the NIS domain, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the NIS Domain list, click the domain to which you want to add the user.

  6. In the Primary group name/GID list, click the name of the user's primary group, and then click OK

  7. In the details pane, right-click the group you selected as the user's primary group, and then click Properties.

  8. Click the UNIX Attributes tab, and then click Add.

  9. In the Available NIS Users list, click the name of the user you just added to the domain, click Add, and then click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The logon name of the user must comply with UNIX user-naming conventions. It must contain only lowercase alphabetic and numeric characters, no more than eight characters, and at least one alphabetic character. It must not include either a colon (:) or a newline character.
  • A user identifier (UID), default shell, and home directory are automatically assigned to the user. If your NIS domain has special requirements for these values, you can change them when you add the user to the domain or at any later time.

See Also

  • Managing NIS users
  • Change a user's ID (UID)
  • Change a user's default shell
  • Change a user's home directory
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Change a user's ID (UID)

To change a user's ID (UID)

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the user you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the UID box, type the new user identifier (UID) for the user.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS users
  • Add a user to an NIS domain
  • Change a user's default shell
  • Change a user's home directory
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Change a user's default shell

To change a user's default shell

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the user you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the Login Shell box, type the full path name of the new shell for the user.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS users
  • Add a user to an NIS domain
  • Change a user's ID (UID)
  • Change a user's home directory
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Change a user's home directory

To change a user's home directory

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the user you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the Home Directory box, type the full path name of the new home directory for the user.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS users
  • Add a user to an NIS domain
  • Change a user's ID (UID)
  • Change a user's default shell
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Manage NIS Groups

Manage NIS groups

  • Add a group to an NIS domain

  • Change a group's ID (GID)

  • Add or remove members of a group


Add one or more groups to an NIS domain

To add a group to an NIS domain

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the group you want to add to the NIS domain, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the NIS Domain list, click the domain to which you want to add the group.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The name of the group must comply with UNIX naming conventions. It must contain only lowercase alphabetic and numeric characters, no more than eight characters, and at least one alphabetic character. It must not include either a colon (:) or a newline character.
  • A group identifier (GID) is automatically assigned to the group. If your NIS domain has special requirements for GID values, you can change the assigned value.

See Also

  • Managing NIS groups
  • Change a group's ID (GID)
  • Add or remove members of a group
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Change a group's ID (GID)

To change a group's ID (GID)

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the group you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the GID (Group ID) box, type the new group identifier (GID) for the group.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS groups
  • Add a group to an NIS domain
  • Add or remove members of a group
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Add or remove members of a group

To add or remove members of a group

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Users folder.

  3. In the details pane, right-click the group you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. Do one of the following:

    • To add a user, click Add. In the Available NIS users list, click Add, and then click OK.

    • To remove a user, in the Members list, click the user you want to remove, and then click Remove.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS groups
  • Add a group to an NIS domain
  • Change a group's ID (GID)
  • Edit passwd, group, and host map entries using Active Directory Users and Computers
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Manage NIS Computers

Manage NIS computers

  • Add a computer to a domain

  • Specify the IP address of a computer in a domain

  • Specify the alias of a computer in a domain


Add a computer to a domain

To add a computer to a domain

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Computers folder.

  3. In the details pane, right-click the computer you want to add to the domain, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the NIS Domain list, click the domain to which you want to add the computer.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS computers
  • Specify the IP address of a computer in a domain
  • Specify the alias of a computer in a domain
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Specify the IP address of a computer in a domain

To specify the IP address of a computer in a domain

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Computers folder.

  3. In the details pane, right-click the computer you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the IP Address box, type the Internet Protocol (IP) address of the computer.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

See Also

  • Managing NIS computers
  • Add a computer to a domain
  • Specify the alias of a computer in a domain
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Specify the alias of a computer in a domain

To specify the alias of a computer in a domain

  1. Open Active Directory Users and Computers.

  2. In the console tree, click the Computers folder.

  3. In the details pane, right-click the computer you want to administer, and then click Properties.

  4. Click the UNIX Attributes tab.

  5. In the Alias box, type the alias of the computer, and then click Add.

  6. To save the changes and keep the dialog box open, click Apply. To save the changes and close the dialog box, click OK.

Notes
  • There is no command-line method for this procedure.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • To remove an alias of the computer, select the alias in the List of Aliases list, and then click Remove.

See Also

  • Managing NIS computers
  • Add a computer to a domain
  • Specify the IP address of a computer in a domain
  • Propagate changed maps now
  • Managing standard and nonstandard NIS maps


Concepts of Server for NIS

Concepts

This section contains information about:

  • Understanding Server for NIS

  • Administering Server for NIS


Understanding Server for NIS

Understanding Server for NIS

Server for NIS integrates Windows and Network Information Service (NIS) networks by giving a Windows–based Active Directory domain controller the ability to act as a master NIS server for one or more NIS domains. Server for NIS stores both standard and nonstandard NIS map data in Active Directory. (Standard maps consist of aliases, bootparams, ethers, hosts, group, netgroup, netid, netmasks, networks, passwd, protocols, rpc, services, pservers, and shadow; all other maps are non-standard.) Server for NIS thus creates a single name space for the Windows and NIS domains that can be managed by the Windows administrator using a single set of tools. The administrator can easily create, modify, and delete user accounts for Windows and UNIX domains at the same time. A user who has accounts on both Windows and UNIX can be managed from Active Directory with all attributes necessary for the respective domain and name space.

Server for NIS can also be installed on other domain controllers in the same domain as the master NIS server, giving them the ability to function as NIS subordinate (also known as slave) servers. In this case, the NIS data in Active Directory is automatically replicated among the Windows domain controllers running Server for NIS. In addition, UNIX-based computers can continue to function as subordinate servers in the NIS domain; Server for NIS uses yppush to propagate changes to the NIS data to UNIX-based NIS servers just as a UNIX-based master NIS server would.

After you install Server for NIS, your first major task is to migrate NIS maps from UNIX-based NIS servers to the computer running Server for NIS. You can use either a Windows-based migration wizard, or you can use a command-line utility to carry out this process. After the maps for an NIS domain have been migrated, Server for NIS is ready to act as a master server for the NIS domain. You can migrate multiple NIS domains to the same Windows–based Active Directory domain controller. These domains can be merged with each other or kept separate. You can migrate NIS map data in a staged manner by migrating NIS maps one at a time.

Server for NIS can support multiple NIS domains concurrently. Maps that belong to multiple domains can also reside concurrently in Active Directory. Requests from a client or another server in a domain receive data from a map in the same domain.

You can manage Server for NIS using the Windows-based Identity Management for UNIX. You can manage the passwd, group and hosts maps that you have migrated to Active Directory using Windows–based tools such as Active Directory Users and Computers. You can also use the command-line tools nismap and nisadmin to manage all standard and non-standard maps and to manage Server for NIS. You can monitor Server for NIS performance using Windows administrative tools, including using Event Viewer to audit significant events and errors logged by Server for NIS.

In addition to using administrative tools provided by Windows, you can also create additional administrative tools using Active Directory Service Interfaces (ADSI) or Lightweight Directory Access Protocol (LDAP).

Server for NIS implements the NIS remote procedure calls necessary to serve requests from UNIX-based and Windows-based NIS clients, as well as other subordinate NIS servers. Server for NIS supports both broadcast mode and the normal binding mode.

This section contains information about:

  • Understanding NIS

  • Master and subordinate (slave) modes

  • Understanding NIS Data Migration


Understanding NIS

Understanding NIS

Formerly known as Yellow Pages (yp), Network Information Service (NIS) provides a simple network look-up service that consists of databases and processes. An NIS domain consists of a client and one or more servers. Clients use the NIS protocol to look up information stored in NIS databases, which are replicated among servers. A single master server is used to update databases; subordinate (also known as slave) servers provide read-only services. Databases are synchronized by copying them from master servers to subordinate servers periodically or upon change.

A database served by NIS is called an NIS map. The NIS lookup calls require a map (database) name and an NIS domain name. An NIS domain consists of a collection of such maps. In addition to map databases, the master NIS server maintains the time stamp that indicates when each database was last modified.

Each database is created from a source file. For example, passwd.byname and passwd.byuid databases are created from the source file named passwd. When source files change, administrators either execute a shell script called ypmake or a makefile to update the databases. In addition, the makefiles used to create the databases push the databases to subordinate NIS servers using yppush. The transfer uses ypxfr, a program that runs on the subordinate servers.

Clients can use many functions and remote procedure calls to connect to the network lookup service, including yp_match, yp_first, yp_next, yp_all, yp_order, yp_master, yperr_string, and ypprot_err. In addition there are usually many tools for administering NIS, such as ypwhich, yppoll, ypset, ypcat, and domainname.

Note

Server for NIS does not support ypxfrd, which might cause some UNIX subordinate (also known as slave) Network Information Service (NIS) servers to display warning messages. The warning messages originate in ypinit and do not indicate actual errors. Some UNIX subordinate NIS servers run ypxfrd on the master NIS server to replicate NIS maps. If they fail to connect to ypxfrd, they obtain copies of NIS maps by using yp_all.


Master and subordinate (slave) modes

Master and subordinate (slave) modes

Server for NIS can operate in a master mode or subordinate mode. (If Server for NIS is used in a domain, the master server in the domain must be Server for NIS.) In UNIX, the primary difference between the two is that both subordinate and master servers can read map data, while only the master server can update maps. Additionally, the master Network Information Service (NIS) server provides periodic updates of the maps to subordinate servers.

In Windows with Server for NIS, because the data is stored in Active Directory, both master and subordinate servers share the same replicated Active Directory database. This makes them peers as far as map updates or write access are concerned. Server for NIS in either master mode or subordinate mode will allow updates to Network Information Service (NIS) map data stored in Active Directory. Changes to Active Directory on any of these servers are propagated to other Servers for NIS in the domain by the Active Directory synchronization mechanism.

Although these servers run as peers for data updates, there must still be only one master server as far as the UNIX subordinate servers and UNIX clients are concerned. UNIX subordinate servers will continue to receive map updates from the Server for NIS that is designated as the master server. Similarly, they will continue to send passwd changes only to the master server.

For information about changing a subordinate server to a master server, see Change a subordinate (slave) server to a master server.


Understanding NIS Data Migration

Understanding NIS data migration

Server for NIS allows Network Information Service (NIS) map data to be migrated to Active Directory.

After the migration, and upon receiving NIS requests from clients or other servers, Server for NIS searches Active Directory to reply to NIS queries.

Migration consists of the following three steps:

  1. Migrate the NIS maps to a Windows-based server.

    • Using the command line

      Identity Management for UNIX includes a command-line tool called nis2ad to migrate maps from UNIX-based NIS servers to Active Directory–based Server for NIS.

    • Using the migration wizard

      The NIS Data Migration wizard in Identity Management for UNIX extracts the information necessary to perform the migration. Even when using the migration wizard, however, you must complete steps 2 and 3, which follow.

    The migration wizard and the nis2ad command read map data from NIS map source files, which are the plain text files from which the NIS map databases are compiled. These source files must be located in a location that can be accessed by the domain controller during migration, such as on a disk on the domain controller or in a shared directory accessible by the domain controller.

  2. Inform the existing subordinate (also known as slave) NIS servers of the new master NIS server.

    After the migration, the original UNIX-based NIS server must send an update of maps to all subordinate NIS servers with the name of the new master server in the maps.

  3. Disable the original NIS server.

UNIX-based subordinate NIS servers can continue to work as before; however, they will receive map updates from the Windows-based computer instead of the UNIX-based computer. Client computers will continue to get NIS maps or data from the new master.

This section provides information about the following:

  • Migrating NIS to Active Directory

  • Migrating standard and nonstandard maps

  • Resolving migration conflicts

  • Handling special users during migration to Active Directory


Migrating NIS to Active Directory

Migrating NIS to Active Directory

During migration, Server for NIS can migrate each Network Information Service (NIS) domain and preserve it as a separate domain in Active Directory. It can also merge the data in an existing domain, however. This domain can be one of the previously migrated domains or a special NIS domain that is created when Server for NIS is installed.

One of the advantages of migrating NIS maps to Windows is to merge UNIX and Windows users and objects to create a common name space. Another advantage is that objects common in two networks can have a unique identity.

During migration, you must specify the Active Directory container in which migrated objects will be created. It is strongly recommended that you create these objects in the same container as the other Windows objects. If the container is not specified, new objects will be created in the default container that is the same as Windows.

If you migrate passwd, groups, or host maps to a container other than the default container, migrated entities will not appear by default in Windows Active Directory Users and Computers. To view all objects, select Advanced features in the View menu of the Active Directory Users and Computers console.

Windows user accounts created as a result of the migration will be disabled. After performing the migration, you must enable the accounts when you are ready for them to be used. For security reasons, it is recommended that you also assign a temporary password to these accounts and instruct the users to change their Windows password as soon as possible.

See Server for NIS Troubleshooting for information about dealing with migration problems.

Staged migration

After the maps are migrated to the Windows Active Directory domain controller, other UNIX-based subordinate (also known as slave) servers can also be migrated to other domain controllers in the same Windows domain. Migration of subordinate servers does not require migration of the data. Because of the architecture of Active Directory, other domain controllers in the Windows domain share the same Active Directory schema and database. Consequently, these domain controllers already have the NIS data. After the Server for NIS is installed on a domain controller in the same Windows domain, it is ready to act as a subordinate NIS server for the NIS domain.

The steps in the migration of a subordinate NIS server are as follows:

  1. Make sure the master server of the NIS domain is migrated to Server for NIS.

  2. Install Server for NIS on another Active Directory domain controller. The subordinate NIS server that you are migrating to Windows can continue to work as before. This will mean that each subnet can have more than one subordinate NIS server.

  3. Disable the subordinate NIS server on the UNIX-based computer.

The NIS map source files of an NIS domain need not be migrated all at once. (NIS map source files are the plaintext files from which the NIS map databases are compiled.) In fact, each NIS map that belongs to a domain is migrated separately. The administrator can specify the domain name to which this map will be migrated. If a domain with that name does not exist, Server for NIS creates a new NIS domain.

After you migrate NIS maps to Server for NIS, there might be some delay before this data is available to Server for NIS.

Migrating multiple NIS domains

The migration utility or migration wizard allows migration of multiple NIS domains to Active Directory. During migration of a map, the administrator must specify the domain from which the data is being migrated. Server for NIS keeps the name of the domain with the map entries created in Active Directory. Subsequently, these map entries are returned to clients or subordinate servers from that domain only.

In addition, however, the migration wizard can also merge a map from one domain into another NIS domain. This can be one of the previously migrated NIS domains or a special domain that is created when Server for NIS is installed. The administrator must specify the name of the NIS domain to which the data will be migrated.

If you migrate multiple domains, you can manage individual domains through Identity Management for UNIX Administration.

Server for NIS supports a maximum of 960 unique combinations of NIS domains and maps. For example, Server for NIS cannot support more than 64 domains with 15 maps each (64×15=960).


Migrating standard and nonstandard maps

Migrating standard and nonstandard maps

The command-line migration program and the NIS Data Migration wizard are both designed to migrate standard Network Information Service (NIS) maps, such as passwd, group, and services. The NIS Data Migration wizard provides a list of NIS map source files (that is, the plaintext files from which the NIS map databases are compiled) from which the administrator chooses the maps to migrate. The migration wizard then uses the standard format of these NIS map source files to migrate the data to Active Directory.

The following are considered standard maps. All other maps are nonstandard maps.

  • aliases

  • bootparams

  • ethers

  • hosts

  • group

  • netgroup

  • netid

  • netmasks

  • networks

  • passwd

  • protocols

  • rpc

  • services

  • ypservers

  • shadow

Note that domain names are not case sensitive. Domains cannot be migrated if they have the same name, even if the case of the names is different.

Migration is handled in one of two ways, depending on whether the map being migrated has an equivalent in Active Directory. For standard maps such as passwd, group, and hosts, that have an equivalent Active Directory class, auxiliary classes are added. For example, an auxiliary class called posixAccount is added to the class user, which, in turn, adds attributes such as uidNumber and unixHomeDirectory. For standard NIS maps that have no equivalent in Active Directory, such as services and rpc, additional classes are created.

Because Identity Management for UNIX is compliant with Internet Engineering Task Force (IETF) standard Request for Comments (RFC) 2307, map attributes match those identified in the RFC 2307 schema, with the following exceptions:

  • The Identity Management for UNIX equivalent of the RFC 2307 attribute userPassword is unixUserPassword.

  • The Identity Management for UNIX equivalent of the RFC 2307 attribute homeDirectory is unixHomeDirectory.

  • In Identity Management for UNIX, posixgroup is not a unique class as defined by RFC 2307. It is an auxiliary class.

For each map entry being migrated during the migration of standard maps, the migration wizard either creates a new object of the corresponding class or adds appropriate attributes to the auxiliary class.

Because the classes and attributes found in non-standard maps may not have matching correspondents in Active Directory, the migration wizard relies upon a key field to make a one-to-one match between entries in the existing map and entries created in Active Directory. Using the key field as a reference, the migration wizard copies to Active Directory other classes in the nonstandard map as they appear in the map source file.

Important

When you migrate passwd and group maps, users will not appear as members of their primary group. If you want users to be members of their primary group in Active Directory, you must use Active Directory Users and Computers to add users to their primary group.

Before you migrate a nonstandard map, you must provide the syntax of the map. You must provide the name of the nonstandard map, the delimiter between the fields, and the field number of the key field.

For information about managing maps after migration, see Managing standard and nonstandard NIS maps.

Migrating passwd maps

If a new Windows user is created as a result of the migration, the user's Windows account is disabled. Before the user can log on to the Windows domain or a UNIX computer in the NIS domain, you must enable the Windows account. For security reasons, it is recommended that you change the user's Windows password to a known, temporary value, inform the user what the temporary password is, and then instruct the user to change the Windows password as soon as possible. When the user changes the Windows password, the new password will be propagated to UNIX-based NIS clients the next time the NIS maps are refreshed. After this refresh occurs, the user can log on to UNIX computers in the NIS domain.

If migration results in adding UNIX attributes to an existing Windows user, the UNIX password in Active Directory will be set to the existing UNIX password, and the Windows password will remain unchanged.

Server for NIS is designed so that whenever a user's Windows password is changed, the password in the NIS passwd map stored in Active Directory is changed. The reverse is not true, however. That is, when the user runs yppasswd on a UNIX client computer to change the user's NIS password, only the password in the NIS passwd map will be changed; the Windows password will not change. As a result, the UNIX and Windows passwords will differ. Users should change passwords only in Windows to ensure that Windows and UNIX passwords in the NIS map are identical. Note, however, that you can install and configure Password Synchronization to provide two-way password synchronization between Server for NIS and UNIX hosts in an NIS domain. For more information, see Synchronizing passwords with an NIS domain.

Migrating ypservers maps

Keys within the ypservers map are the ASCII names of the computers on which the NIS servers run. That is, the ypservers map can contain only a list of NIS servers, each one listed on a separate line. If your ypservers map contains aliases, before migrating the map, edit the ypservers map to contain only the host names of the servers, one per line. The following list is an example of a valid ypservers map:

ypserver_1
ypserver_2
ypserver_3

Migrating Automount File System (AutoFS) maps

You can migrate Automount File System (AutoFS) maps by importing the auto_master and auto_home files from a UNIX computer. You can use either command-line tools or the NIS Data Migration wizard.

Before performing the migration, you must copy the auto_master and auto_home files from the UNIX computer to any directory (such as %TEMP%) on the Windows-based computer.

When you use the wizard to migrate AutoFS maps, specify auto_master or auto_home, depending on which map you are migrating. Specify a blank space as the field separator and 1 (one) as the key field. Verify that the Key is part of value check box is not selected.

You can use the wizard to import other AutoFS maps as well. For example, you can migrate the auto.redirect map by copying and then importing the auto_redirect map file, making sure that the Key is part of value check box is not selected.

Using command-line tools to migrate AutoFS maps involves using the nismap utility to create the corresponding structure in the Active Directory schema and then running the nis2ad utility to import the map data.

For example, the following commands would migrate AutoFS maps from the NIS domain named NIS01 to the Windows domain named WIN01 by using files located in C:\Temp:

nismap create -i 1 -g " " -y auto.master
nismap create -i 1 -g " " -y auto.home
nis2ad -y NIS01 -a WIN01 -d C:\Temp -s localhost -r yes -m auto_master
nis2ad -y NIS01 -a WIN01 -d C:\Temp -s localhost -r yes -m auto_home

You can use the same method to migrate other AutoFS maps. For example, to migrate the auto.redirect map, use the nismap utility to create the structure for the auto.redirect map in Active Directory, copy the auto_redirect file to the Windows-based computer, and then run the nis2ad utility to import the data in the auto_redirect file.

Migrating nonstandard maps

Active Directory includes a class that applies to any NIS map. This class requires the name of the map, the key, and the rest of the entry.

To migrate nonstandard maps, the administrator must provide the name of the map source file and the format of the map entries to the migration wizard or command-line utility. The migration wizard uses the key field and the separator to migrate the data and create appropriate objects in Active Directory.

Important

If you migrate passwd, group, or hosts maps to a container other than the default container (CN=users,...), some migrated objects do not typically display in Windows Active Directory Users and Computers. To view all objects in Active Directory Users and Computers, select the domain and then click Advanced Features on the View menu.


Resolving migration conflicts

Resolving migration conflicts

During migration, conflicts may occur when Server for NIS attempts to merge incoming user accounts, groups, and computer names into classes that already exist in Active Directory. Conflicts can also occur because Server for NIS allows one Network Information Service (NIS) domain to merge with another NIS domain that has already been migrated to Server for NIS.

For example, consider a passwd map source file being migrated to Server for NIS. Suppose there is a UNIX user with a user name of johnwood. If there is no existing user with a user name of johnwood, migration of this user to Server for NIS is simple. If there is already a user with that user name previously migrated from another NIS domain, however, a conflict would occur.

When the NIS Data Migration wizard encounters a potential name conflict during migration, it resolves the conflict by prefixing the name being migrated. If the name being migrated is a user name, the prefix consists of the NIS domain name plus the characters _u_. If the name being migrated is a group name, the prefix consists of the NIS domain plus the characters _g_. This allows the migration to complete even if there is a conflict.

For example, if you are migrating a user named johnwood in an NIS domain named mktg, and a user with the same name was previously migrated from another NIS domain, then the user name of johnwood in the mktg domain will be changed to mktg_u_johnwood during the migration.

When such conflicts occur, you need to examine the migration logs and then determine how to handle each case. You need to consider whether the conflicting name represents the same user or group in both domains, or different users or groups. If not, you will probably want to rename one or both users or groups. If they do represent the same user or group, then you will need to decide whether the user or group really needs to be in both domains (in which case, at least one of them needs to be renamed) or whether the user or group in one of the domains can be deleted.

Rather than deal with the conflict after the domain migration has occurred, you can determine in advance whether a conflict will occur and then take steps to prevent the conflict (such as by changing the name of a user or group in the NIS domain).

By default, the NIS Data Migration wizard performs what is known as a dummy migration. During this process, the wizard goes through all the steps required to migrate an NIS domain to Active Directory, but does not actually change Active Directory. This lets you record the anticipated migration results in a log file and then, if potential conflicts are found, deal with those conflicts appropriately before actually performing the migration.

When identical names are detected during a dummy or actual migration, the conflict can be logged to a conflicts file. This file lists conflicts that have arisen during the migration of a particular map. If there was a conflict, the conflicts file lists the NIS entry being migrated and the existing entry in Active Directory. Consider the following two examples. In the first one, the conflicts file states that there were no conflicts in the migration of the passwd file.

--------------
## Tue Jun 1 16:22:47 1999 : Conflicts between entries from map file 'passwd' and existing entries in Active Directory. ##
-------------

In the next example, the conflicts file states that there was a conflict in the migration of the map. It lists the existing entry in Active Directory and the new entry being migrated.

-------------
## Tue Jun 1 16:22:52 1999 : Conflicts between entries from map file 'aliases' and existing entries in Active Directory. ##
EXISTS : having DN = 'CN=al1,CN=nisadmin,CN=DefaultMigrationContainer,DC=nis, DC=sfu,DC=nttest,DC=microsoft,DC=com'
OLD : staff:wnj,mosher,sam
NEW : staff:pradeep,peter,wjs
-------------

According to the file, the "staff" map already exists in Active Directory. The entry in Active Directory is different from the entry being added. In such a case, you can change the name of the alias "staff" either in Active Directory or in the map source file, that is, the plain text file from which the NIS map database is compiled. You can also preserve or replace the existing entries by force.

In addition to a conflicts file, you can specify a log file where the entire migration steps will be logged. The following is a sample output of such a log file:

## Start of NIS to Active Directory migration of 'passwd' @ Tue Jun 1 16:26:21 1999 ##
MESSAGE : Migrating 'passwd' entries from UNIX NIS domain 'nis01' to Active Directory domain 'CorpDomain.'
SUCCESS : Migration of object 'nis0101' of class 'User' into 'LDAP://localhost/CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'.
SUCCESS : Migration of object 'nis0102' of class 'User' into 'LDAP://localhost/CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'.
## Start of NIS to Active Directory migration of 'passwd' @ Tue Jun 1 16:41:46 1999 ##
MESSAGE : Migrating 'passwd' entries from UNIX NIS domain 'conflicts' to Active Directory domain 'conflicts'.
CONFLICT : Can't migrate 'nis0101' to
'LDAP://localhost/CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'. An object having same attributes(name/uidNumber/gidNumber) exists at 'CN=nis0101,CN=Users,DC=nis,DC=sfu,DC=nttest,DC=microsoft,DC=com'.

For more information about dealing with migration problems, see Server for NIS Troubleshooting.


Handling special users during migration to Active Directory

Handling special users during migration

During migration, for special users with user identifiers (UIDs) that are less than 20, Windows accounts are created such that the first nine characters of their Network Information Service (NIS) domain are appended to their UNIX user name to create a Windows logon name. Their UNIX user name is unaffected. For example, if you migrate root from physlab to Server for NIS, a new Windows user will be created called physlab_u_root. The UNIX user name is still root, and NIS queries from physlab domain will be unaffected.

A group called root from such a domain, if migrated, will create a group called physlab_g_root.


Administering Server for NIS

Administering Server for NIS

This section provides information about:

  • Installing and uninstalling Server for NIS

  • Starting and stopping Server for NIS

  • Configuring a UNIX NIS server to use Server for NIS as the master server

  • Configuring UNIX clients to use Server for NIS as the master server

  • Using the migration wizard

  • Using the command-line utility for migration

  • Managing standard and nonstandard NIS maps

  • Managing NIS users

  • Managing NIS groups

  • Managing NIS computers

  • Synchronizing user passwords

  • Setting UNIX passwords to special values

  • Synchronizing and propagating NIS changes

  • Sending periodic map updates to subordinate (slave) NIS servers

  • Pushing map updates immediately


Installing and uninstalling Server for NIS

Installing and uninstalling Server for NIS

The NIS domain

Upon installation, Server for NIS creates a Network Information Service (NIS) domain with the same name as the Active Directory domain. Administrators can add users, groups, or computers to this domain. Moreover, administrators can migrate UNIX NIS domain data to Server for NIS and designate the Server for NIS computer as the master NIS server for the migrated domain.

Uninstalling in master mode

If you uninstall Server for NIS while it is running on a master server, you must verify that another server takes over the tasks of the master server. If other Windows-based subordinate (also known as slave) NIS servers are in the domains supported by the master server you uninstall, you must assign one of these servers the role of master server. Server for NIS cannot be a subordinate server to a master NIS server running on a UNIX operating system.

Uninstalling in subordinate mode

If you uninstall Server for NIS running as a subordinate server, the domain controller on which it was running will continue to receive NIS map updates through Active Directory Synchronization.


Starting and stopping Server for NIS

Starting and stopping Server for NIS

You can use Identity Management for UNIX to start or stop Server for NIS. When Server for NIS is stopped, it will not respond to Network Information Service (NIS) requests from clients, including requests for password changes.

Even when Server for NIS is stopped, you can continue to make changes to NIS map data through Active Directory. UNIX-based computers respond differently in this situation, however. If the NIS server is down on UNIX, changes to maps undertaken through make will not be updated in the NIS database.

In addition, when Server for NIS is stopped, NIS map changes will not be propagated to subordinate (also known as slave) NIS servers running on UNIX. However, subordinate NIS servers running on Windows domain controllers will continue to receive updates.


Configuring a UNIX NIS server to use Server for NIS as the master server

Configuring a UNIX NIS server to use Server for NIS as the master server

To change a UNIX-based Network Information Service (NIS) server from a master server to a subordinate (also known as slave) server, follow these steps:

  1. Migrate maps from the UNIX master NIS server.

  2. Transfer the maps from the old master server to other subordinate NIS servers by providing the name of the new Server for NIS for each map. At a command prompt, type:

    ypxfr –h newserver mapname

    where newserver is the name of the new NIS master server, and mapname is the name of the map to be transferred.

  3. Run this command for each map on each of the subordinate servers. After this step, the UNIX subordinate servers will recognize the new Server for NIS master server.


Configuring UNIX clients to use Server for NIS as the master server

Configuring UNIX clients to use Server for NIS as the master server

For each UNIX client computer on which you want to use Server for NIS as the master server, do the following:

  1. If the domain name has changed, run the following command:

    domainName newdomain

  2. Stop ypbind by running the following command:

    kill –9 ypbindpid

  3. Restart ypbind by running the following command:

    ypbind


Using the migration wizard

Using the migration wizard

Identity Management for UNIX provides a wizard that you can use to migrate your Network Information Service (NIS) system easily to Windows. The wizard takes you through a step-by-step process to complete the migration. Before using the wizard, review the following:

  • Checklist: NIS migration to Active Directory using the NIS Data Migration wizard.

  • Best practices for Server for NIS

  • Migrating NIS to Active Directory

Caution

The migration of NIS to Active Directory is not reversible. Always back up your UNIX NIS systems and Windows-based server before performing an NIS migration.


Using the command-line utility for migration

Using the command-line utility for migration

Instead of using the migration wizard, you can use a command-line utility to migrate maps. For information about the command-line tool, see nis2ad.

Caution

The migration of Network Information Service (NIS) to Active Directory is not reversible. Make sure you back up your UNIX NIS systems and Windows server before doing the migration.


Managing standard and nonstandard NIS maps

Managing standard and nonstandard maps

You can use a Windows-based Network Information Service (NIS) server to manage both standard and nonstandard maps. You can manage maps that are part of a domain served by a Windows-based NIS server through two different mechanisms:

  • The Identity Management for UNIX graphical user interface (GUI).

  • Command-line utilities.

In many cases, you can use either method to perform a task. In some cases, however, only one method or the other can be used.

For information about migrating maps, see Migrating standard and nonstandard maps

Managing passwd maps

You can use Active Directory Users and Computers to manage passwd maps for Server for NIS. You can also use Active Directory Users and Computers to manage password file–related attributes for a user in the Windows domain, or for the users migrated from a given NIS domain.

Managing group maps

Data for group maps for Server for NIS are managed through Active Directory Users and Computers. Each group in the Windows domain or from the groups migrated from a given NIS domain can be managed by using Active Directory Users and Computers.

Note that, for a given group, the UNIX members are different from the Windows users for the same group.

Managing hosts maps

You can manage data for hosts maps for Server for NIS by using Active Directory Users and Computers. Each computer in the Windows domain, as well as the hosts migrated from a given NIS domain, can be managed through this snap-in.

Managing other maps and nonstandard maps

Server for NIS does not include GUI tools for managing standard NIS maps other than passwd, group, and hosts. Maps other than these can be managed using tools provided as part of Active Directory. In particular, administrators can use the adsiedit snap-in to view and edit NIS maps.

Standard maps include:

  • passwd

  • group

  • hosts

  • aliases

  • bootparams

  • ethers

  • netgroup

  • netid

  • netmasks

  • networks

  • protocols

  • rpc

  • services

  • ypservers

  • shadow password maps


Managing NIS users

Managing NIS users

UNIX systems store basic information about authorized users in the passwd file. This file consists of a series of lines, one for each authorized user. Each line can contain the following information about a user:

  • User name

  • Password (in encrypted form)

  • User identifier (UID)

  • Group identifier (GID) of the user's primary group

  • User's full name and other information (known as the gecos field)

  • Default login shell

  • Home directory

Conventional Network Information Service (NIS) servers generate two maps from the passwd file, passwd.byname and passwd.byuid, which contain the same information as the passwd file, but are indexed to provide quick access to the records.

Instead of storing this information in files, Server for NIS maintains user information in Active Directory entries for each user. This allows you to manage the Windows and UNIX (NIS) information together by using the user properties dialog box in Active Directory Users and Computers. When adding a new user, for example, you have to enter the information shared by Windows and NIS (the user name, password, and full name and other gecos-type information) only once. In the case of UNIX-specific information (UID, primary GID, login shell, and UNIX home directory), you can enter this information using the UNIX Attributes tab of the same dialog box.

For more information about how to manage UNIX user accounts using Active Directory Users and Computers, see Manage NIS Users.


Managing NIS groups

Managing NIS groups

UNIX systems store basic information about groups of users in the group file. This file consists of a series of lines, one for each group. Each line can contain the following information about a group:

  • Group name

  • Group identifier (GID)

  • List of users belonging to the group

Conventional Network Information Service (NIS) servers generate two maps from the group file, group.byname and group.bygid, which contain the same information as the group file, but are indexed to provide quick access to the records.

Instead of storing this information in files, Server for NIS maintains group information in Active Directory entries for each group. This allows you to manage the Windows and UNIX (NIS) information together by using the group properties dialog box in Active Directory Users and Computers. When creating a new group, for example, you must enter the group name, which is shared by Windows and NIS, only once. In the case of UNIX-specific information (GID and members), you can enter this information using the UNIX Attributes tab of the same dialog box.

For more information about how to manage UNIX group accounts using Active Directory Users and Computers, see Manage NIS Groups.


Managing NIS computers

Managing NIS computers

UNIX systems store basic information about host computers on the network in the hosts file. This file consists of a series of lines, one for each computer. Each line can contain the following information about a computer:

  • Internet Protocol (IP) address

  • Computer name

  • List of aliases

A UNIX computer consults this list to determine the IP address of another computer when that computer is referred to by name or alias, rather than by address.

Instead of storing this information in a file, Server for NIS maintains information about network computers in Active Directory entries for each computer. This allows you to manage the Windows and UNIX (NIS) information together by using the computer properties dialog box in Active Directory Users and Computers. When adding a computer to the Windows and Network Information Service (NIS) domains, for example, you must enter the computer name, which is shared by Windows and NIS, only once. In the case of UNIX-specific information (IP address and aliases), you can enter this information using the UNIX Attributes tab of the same dialog box.

Note that you have to enter the IP address only if it is statically assigned. If the address is assigned by a DHCP server, the hosts map will be automatically updated whenever the computer's IP address changes.

For more information about how to manage UNIX computer name and address information using Active Directory Users and Computers, see Manage NIS Computers.


Synchronizing user passwords

Synchronizing user passwords

Server for NIS provides limited support for keeping passwords synchronized between a user's Windows and UNIX accounts. Whenever a user's Windows password is changed, Password Synchronization (which you can install with Server for NIS for this purpose) captures the new password, encrypts it, and then stores the password in the passwd map in Active Directory. The new password is then propagated to UNIX-based Network Information Service (NIS) secondary servers and clients when Server for NIS performs its periodic map update.

If Server for NIS is installed in a Windows domain with multiple domain controllers, it is recommended that you install Password Synchronization on all domain controllers in the domain. This is because any domain controller can potentially respond to a request to change a user's password, and so it is recommended that Password Synchronization be running on that domain controller to ensure that the NIS passwd map is updated. If you install Password Synchronization on a domain controller solely to support Server for NIS in this fashion, it is not necessary to configure UNIX hosts to work with Password Synchronization running on the domain controller. On the other hand, you can configure Password Synchronization on a domain controller and selected UNIX hosts to provide two-way password synchronization. This will allow users of the UNIX hosts to use the passwd command (instead of yppasswd) on those hosts to change their NIS domain password as well.

When synchronizing passwords, Server for NIS can use either crypt or Message Digest 5 (MD5). Server for NIS can support different encryption methods for multiple domains, but all UNIX computers in a particular domain must use the same encryption method. See Set the encryption method for a domain for how to specify the encryption method.


Setting UNIX passwords to special values

Setting UNIX passwords to special values

You can set the password for a UNIX user to a special value, such as NP (no password) or * (no login) without affecting the user's Windows password. To do this, use nismap to change the Network Information Service (NIS) password entry for specific user, as follows:

  • To set password to no password (usually a blank):

    nismap mod -e "username:: uid : gid : gecos :/ home / username :/ login_shell " -k username passwd

  • To set password to * (no logon):

    nismap mod -e " username :*: uid : gid : gecos :/ home / username :/ login_shell " -k username passwd

  • To set password to *LK* (locked):

    nismap mod -e "username:*LK*: uid : gid : gecos :/ home / username :/ login_shell " -k username passwd


Synchronizing and propagating NIS changes

Synchronizing and propagating NIS changes

A Windows-based master Network Information Service (NIS) server can propagate changes in maps to subordinate (also known as slave) NIS servers in the same domain. These changes are propagated to subordinate NIS servers using the features of the NIS protocol.

The master NIS server supports the following transfer modes:

  • Periodic transfer of NIS maps.

  • On-demand transfer of NIS maps to subordinate servers. Typically, NIS maps get transferred to subordinate servers upon change through make. The Windows-based NIS server does not use make; instead, the server pushes immediately.

  • Subordinate NIS servers can request transfer of maps at any time.


Sending periodic map updates to subordinate (slave) NIS servers

Sending periodic map updates to subordinate (slave) NIS servers

In Network Information Service (NIS), a master NIS server sends periodic map updates to subordinate NIS servers to ensure that both the master and subordinate servers have the same view of the maps. This process uses yppush. Server for NIS also sends periodic map updates to subordinate NIS servers. You can set the frequency of map updates through Server for NFS Administration.

Server for NIS uses yppush to send map updates only to subordinate NIS servers running on UNIX.

Because Server for NIS uses Active Directory to store data, both master and subordinate servers share the same replicated Active Directory database. Changes to maps for a given domain are propagated to other Servers for NIS running in subordinate mode by Active Directory's synchronization mechanism. Thus, Windows-based subordinate NIS servers receive updates from the master NIS server with every change. The update frequency is the property of the Server for NIS and is fixed for all domains that server supports.

For information about how to change the frequency of map updates, see Change the frequency of map updates to UNIX subordinate (slave) NIS servers.

For information about using yppush, see yppush.


Pushing map updates immediately

Pushing map updates immediately

In Network Information Service (NIS), whenever a change is made to map data, administrators run make to make corresponding changes to the NIS database. Typically, as a part of this process, make also propagates the changes to subordinate (also known as slave) servers through yppush. This provides a way for administrators to push changes immediately to subordinate servers.

Because Server for NIS does not use make to make changes to the database, it provides an explicit yppush command to immediately propagate changes to UNIX-based subordinate servers. Server for NIS also provides a control in Identity Management for UNIX to immediately push maps to subordinate NIS servers.

Note that you use yppush to push changes only to subordinate NIS servers running on UNIX. Because Server for NIS uses Active Directory to store data, both master and subordinate servers running Windows operating systems share the same replicated Active Directory database. Changes to Active Directory are immediately propagated to other Servers for NIS. Thus, it is not necessary to use yppush to push changes to subordinate NIS servers running Windows operating systems.

For information about propagating maps immediately, see Propagate selected maps now and Propagate changed maps now.

For information about using yppush, see yppush.


Server for NIS command-line utilities

Command-line Utilities

The following command-line utilities are available to administer Server for NIS:

nis2ad

nisadmin

nismap

ypcat

ypclear

ypmatch

yppush


yppush

yppush

NAME

yppush - Force propagation of a changed Network Information Service (NIS) map

SYNOPSIS

yppush [-d adNisDomain] [-q] [-t timeout] [-h host[...]] mapname

DESCRIPTION

The yppush(1w) Windows command-line utility sends a request to UNIX-based subordinate (also known as slave) NIS servers to transfer a new version of the NIS map specified by mapname from the master NIS server. It is run only on the master NIS server after the NIS map has been changed. If the -h option is specified, the transfer request is sent only to the specified server. Otherwise, yppush first constructs a list of NIS server hosts by reading the ypservers NIS map within the domain. For more information about the correct format of the ypservers map, see "Note" later in this topic.

The yppush command sends a transfer map request from the NIS server to the transfer agent on each subordinate host computer. A host's transfer agent is the utility that copies map data from the master server. When the transfer has completed, whether the transfer operation succeeded or failed, the transfer agent returns a status message, the contents of which can be printed to standard output. Transfer agents also return messages when a transfer is not possible; for example, when the yppush request is undeliverable to one or more host computers, or when the time-out period on responses from host computers has expired.

The yppush command accepts the following options and arguments:

Term | Definition
-d adNisDomain | Specifies the NIS domain. If this option is not used, the NIS domain is assumed to be the domain named in the DEFAULT_NIS_DOMAIN environment variable.
-q | Quiet mode. Does not wait for a response from subordinate servers, and does not report errors.
-t timeout | Specifies a time-out value, in seconds, that yppush will wait for a response from the subordinate server. This value must be greater than zero. The default value is 30 seconds.
-h host[...] | The name of the host to notify of the map change. You can specify multiple host names, separated by spaces. If you do not specify this option, the notification is sent to all subordinate servers in the domain.
Note

Keys within the ypservers map are the ASCII names of the computers on which the NIS servers run. That is, the ypservers map should contain a list of NIS servers, each one listed on a separate line. If your ypservers map contains aliases, edit the ypservers map to contain only the host names of the servers, one per line. The following list is an example of a valid ypservers map:

ypserver_1
ypserver_2
ypserver_3

See Also

  • Identity Management for UNIX: Server for NIS


ypclear

ypclear

NAME

ypclear - Windows command-line utility to clear the Network Information Service (NIS) server cache for an NIS map and its dependent maps

SYNOPSIS

ypclear [-d domainName] [-t] [-h nisServer] mapname
ypclear -x

DESCRIPTION

The ypclear(1w) Windows command-line utility tells the specified Network Information Service (NIS) server in a specified domain that a map has changed and that the server should clear its cache. Without this notification, the NIS server can sometimes serve out-of-date information.

The ypclear command can be used to rebuild the map cache of an NIS server that still displays obsolete map data, even when Active Directory shows a current and accurate map of the network. Typically, using ypclear corrects the problem.

The ypclear command accepts the following options and arguments:

Term | Definition
-d domain | Specifies the NIS domain. If this option is not used, the NIS domain is assumed to be the domain named in the DEFAULT_NIS_DOMAIN environment variable.
-t | Inhibits map nickname translation.
-h nisServer | Specifies the name of the NIS server. If this option is not used, the NIS server is assumed to be the server named in the NIS_SERVER environment variable.
-x | Displays the map nickname translation table.

See Also

  • Identity Management for UNIX: Server for NIS


ypmatch

ypmatch

NAME

ypmatch - Windows command-line utility to display the values of one or more keys from a Network Information Service (NIS) map

SYNOPSIS

ypmatch [-k] [-t] [-d domain] [-h nisServer] key[...] mapname
ypmatch -x

DESCRIPTION

The ypmatch(1w) Windows command-line utility displays the values one or more keys from the Network Information Service (NIS) map specified by mapname, which may be a map name or a map nickname.

The ypmatch command accepts the following options and arguments:

-k
Displays map keys. This option is useful with maps in which the values are null or the key is not part of the value.
-t
Inhibits map nickname translation.
-d domain
Specifies the NIS domain. If this option is not used, the NIS domain is assumed to be the domain named in the DEFAULT_NIS_DOMAIN environment variable.
-h nisServer
Specifies the name of the NIS server. If this option is not used, the NIS server is assumed to be the server named in the NIS_SERVER environment variable. If NIS_SERVER is not set, ypmatch broadcasts the request.
key
The key for which you want to display the value. To display the value of more than one key, specify the keys separated by spaces. If any key begins with a slash mark (/), backslash (\) or hyphen (-), these special characters must be preceded by a backslash (\). For example, if the key name is \mykey, then use \\mykey.
-x
Displays the map nickname translation table.

See Also

  • ypcat
  • Identity Management for UNIX: Server for NIS


ypcat

ypcat

NAME

ypcat - Windows command-line utility to print values of all keys in an NIS map

SYNOPSIS

ypcat [-k] [-t] [-h nisServer] [-d domain] mapname
ypcat -x

DESCRIPTION

The ypcat(1w) Windows command-line utility prints the values of all keys from the Network Information Service (NIS) database specified by mapname, which can be a map name or a map nickname.

The ypcat command accepts the following options and arguments:

Term | Definition
-k | Displays map keys. This option is useful with maps in which the values are null or the key is not part of the value.
-t | Inhibits map nickname translation.
-d domain | Specifies the NIS domain. If this option is not used, the NIS domain is assumed to be the domain named in the DEFAULT_NIS_DOMAIN environment variable.
-h nisServer | Sends a request to the server name represented by the nisServer variable. The -h option broadcasts the request to all other NIS servers in the domain specified with the -d option, if no server name is provided.
-x | Displays the map nickname translation table.

See Also

  • ypmatch
  • Identity Management for UNIX: Server for NIS


nisadmin

nisadmin

NAME

nisadmin - Windows command-line utility to administer Server for NIS

SYNOPSIS

nisadmin [computer] [-u usr [-p pword]]
nisadmin [computer] [-u usr [-p pword]] mkmaster -d domain
nisadmin [computer] [-u usr [-p pword]] mkslave -d domain -m server
nisadmin [computer] [-u usr [-p pword]] config option[...]
nisadmin [computer] [-u usr [-p pword]] syncall
nisadmin [computer] [-u usr [-p pword]] start
nisadmin [computer] [-u usr [-p pword]] stop
nisadmin [computer] [-u usr [-p pword]] pause
nisadmin [computer] [-u usr [-p pword]] continue
nisadmin [computer] [-u usr [-p pword]] encryptiontype
         -d domain {crypt | md5}

DESCRIPTION

The nisadmin Windows command-line utility administers Server for NIS on the local computer or on a remote computer. If you are logged on with an account that does not have the required privileges, you can specify a user name and password of an account that does. The action performed by nisadmin depends on the command argument you supply.

In addition to specific command arguments, nisadmin accepts the following options and arguments:

Term | Definition
computer | Specifies the remote computer you want to administer. You can specify the computer using a Windows Internet Name Service (WINS) or Domain Name System (DNS) name, or by Internet Protocol (IP) address.
-u usr | Specifies the user name of the user whose credentials are to be used. It might be necessary to add the domain name to the user name in the form domain\username.
-p pword | Specifies the password of the user specified using the -u option. If you specify the -u option but omit the -p option, you are prompted for the user's password.

The specific action that nisadmin performs depends on the command argument you specify:

Term Definition

mkmaster

Changes a subordinate (also known as slave) server to a master server. The following option and argument are required when you use mkmaster:

Term | Definition
-d domain | Specifies the name of the domain for which the change is being made.

mkslave

Changes a master server to a subordinate (slave) server. The following options and arguments are required when you use mkslave:

Term | Definition
-d domain | Specifies the name of the domain for which the change is being made.
-m server | Specifies the name of the domain controller to be promoted to master server.

config

Configures service parameters. You must supply one or more of the following options when you use config:

Term | Definition
pushint =[[days:]hh:]mm | Specifies the interval at which the service checks changes to Network Information Service (NIS) maps in Active Directory and propagates them to secondary NIS servers for all domains, in days, hours, and minutes. If hh is specified, hh must be in the range 0-23 and mm must be in the range 0-59.
logging ={n[ormal] | v[erbose]} | Specifies the amount of information to be available in event logs. Specify normal (or n) to log only failure events; specify verbose (or v) to log failure, warning, and success events.

syncall

Synchronizes changed maps with those on UNIX-based subordinate servers immediately.

start

Starts the Server for NIS service.

stop

Stops the Server for NIS service.

pause

Pauses the Server for NIS service.

continue

Continues running the Server for NIS service.

encryptiontype

Specifies the method used to encrypt UNIX passwords for the specified domain. For domains whose UNIX-based computers are all running Linux with MD5 encryption, this value can be md5. For domains containing one or more UNIX-based computers running any other operating system or encryption method, this value must be crypt (the default). All computers in the domain must use the same method.

Password encryption can only be set to one encryption method at a time. Changing the encryption method invalidates user passwords. All passwords must be reset if the encryption method is changed.

If you do not supply a command argument, nisadmin displays the current Server for NIS settings.

See Also

  • Identity Management for UNIX: Server for NIS


nis2ad

nis2ad

NAME

nis2ad - Windows command-line utility to migrate maps from Network Information Service (NIS) to Active Directory directory service

SYNOPSIS

nis2ad.exe -y NIS_Domain -a AD_domain [options] mapfile

DESCRIPTION

The nis2ad Windows command-line utility transfers the entries in the Network Information Service (NIS) map source file specified by mapfile located in the UNIX NIS domain specified by NIS_domain to the Active Directory domain specified by AD_domain. NIS map source files are the plain text files from which the NIS map databases are compiled.

The -m option must be specified to perform the actual migration; otherwise, nis2ad performs the actions it would perform in an actual migration without actually changing Active Directory, including logging any conflicting entries.

The nis2ad utility accepts the following options and arguments:

Term | Definition
-d directoryname | Specifies the name of the directory that contains NIS map source files.
-s server | Specifies the domain controller server hosting Active Directory; otherwise, uses the current server.
-u user | Specifies the name of a user having administrator permissions on this computer; otherwise, uses the current user.
-p password | If a password is needed but is not specified, nis2ad prompts the user for the password.
-f logfile | Specifies the name of the log file. The log file must be on your local computer. The default is %sfudir%\nis\nis2ad.log.
-c conflictfile | Specifies the file where conflict details are written. The default is %sfudir%\nis\conflicts.log.
-r {yes|no} | Replaces the object in Active Directory with the object being migrated. The default is no.
-n | Resolves conflicts by changing the Windows account name in Active Directory. If objects of different types have the same name, the name of both objects is changed before the data is migrated.
-t targetContainer | Specifies the target container name. Applicable only when creating a new NIS domain. If not specified, uses default or uses the container of the target domain.
-m | Performs the migration. If this option is omitted, the program finds and reports conflicts, but does not actually perform the migration.
-h/-? | Displays usage information for the command.
Note

The currently logged on user must have write permissions for the folder that will contain the log and conflict files, even if another user is specified with the -u option. If necessary, modify the permissions on the folder to grant write access to the user who will be running the nis2ad utility before running the utility.

See Also

  • Identity Management for UNIX: Server for NIS


nismap

nismap

NAME

nismap - Windows command-line utility to manage Network Information Service (NIS) maps

SYNOPSIS

nismap add [common_option[...]] -e "mapentry"
           [-r {yes | no}] [-c conflictfile] mapname
nismap mod [common_option[...]] -e "mapentry" -k key mapname
nismap del [common_option[...]] -k key mapname
nismap create [common_option[...]] -i fieldnum -g separator [-y] mapname

DESCRIPTION

The nismap Windows command-line utility manages the Network Information Service (NIS) map specified by mapname maintained by Server for NIS on a local computer or a remote computer. If you are logged on with an account that does not have the required privileges, you can specify the user name and password of an account that does. The specific action that nismap performs depends on the command argument you specify.

In addition to specific command arguments, nismap accepts the following common options and arguments, represented by common_option in the command synopsis:

Term | Definition
-a AD_domain | The name of the NIS domain in Active Directory. This option is not available for the create command argument.
-f logfile | Specifies the fully qualified path and name of the log file. Logged events are appended to this file. The default path and file name is %temp%\conflicts.log.
-s server | Specifies the name of the domain controller. The default is the domain controller of the domain of the computer on which the command is executed.
-u usr | Specifies the user name of the user whose credentials are to be used. It might be necessary to add the domain name to the user name in the form domain\username.
-p pword | Specifies the password of the user specified using the -u option. If you specify the -u option but omit the -p option, you are prompted for the user's password.
-h/-? | Displays usage information for the command.

The following command arguments are accepted by nismap:

Term Definition

add

Adds a map entry. The following options and arguments are used with add:

Term | Definition
-e "mapentry" | Specifies the new map entry as a string in the appropriate NIS map format. The string must be enclosed in quotation marks (" ").
-r {yes | no} | Specifies whether the existing object in Active Directory is to be replaced with this entry. The default is no.
-c conflictfile | Specifies the name of the file in which conflict information is to be recorded. If this option is not provided, a default file name is used.

mod

Modifies an existing map entry. The following options and arguments are required with mod

Term | Definition
-e "mapentry" | Specifies the replacement map entry as a string in the appropriate NIS map format. The string must be enclosed in quotation marks (" ").
-k key | Specifies the search key that identifies the map entry to be modified.

del

Deletes an existing map entry. The following option and argument are required with del:

Term | Definition
-k key | Specifies the search key that identifies the map entry to be deleted.

create

Creates a structure for a nonstandard map. The following options and arguments are required with create:

Term | Definition
-i fieldnum | Specifies the field number of the key field.
-g separator | Specifies the character that separates fields in the map.
-y | Specifies that the key is not part of the value for this map.
Notes
  • When you use nismap to delete a user, group, or host object, only the UNIX attributes of the object are deleted from Active Directory. To delete the object from Active Directory, use the Active Directory administration tools.
  • Do not use nismap to change a user's password. Use net.exe or the Windows interface (CTRL+ALT+DELETE) instead. The nismap utility will fail if you change the passwd entry using the nismap mod command. This value is the encrypted string of the user's password. If you need to change the passwd entry, use ypcat(1w) or ypmatch(1w) to retrieve the user's current passwd entry and to ensure that the password field is identical.
  • If you try to modify a mail alias using the nismap mod command, Server for NIS adds the new alias to the original one instead of replacing it. To change the alias, first use nismap del to delete the original alias, and then use nismap add to add the modified alias.

See Also

  • Identity Management for UNIX: Server for NIS


Server for NIS Troubleshooting

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 test migration with "Do Not Migrate" option succeeded

  • A conflict occurs while trying 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 Windows 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 from 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 in effect.

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. To override the default when you are running the command-line utility (Nis2ad.exe), specify the -m option on the command line.

Migration conflicts occur even though test migration with "Do Not Migrate" option succeeded.

Cause: If data in the Network Information Service (NIS) maps being migrated conflicts, the conflict might not be reported until the maps are actually migrated because only conflicts between NIS maps and Active Directory are reported.

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

A conflict occurs while trying 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 will be 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 account, and then remigrate the entry.

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.

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 Change the frequency of map updates to UNIX subordinate (slave) NIS servers 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 (slave) 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 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 from 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 Solaris client:

  • Ensure that the Windows server 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 server.

  • 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 Linux client

  • 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.


Identity Management for UNIX: Password Synchronization

Password Synchronization makes it easy for users to maintain one user name and password for Windows domains and UNIX systems, synchronizing the passwords when one of them changes.

Depending on how Password Synchronization and the UNIX servers are configured, synchronization can be one way or two way.

  • Before you begin using Password Synchronization, see Checklists for Password Synchronization.

  • For information about how to implement Password Synchronization most effectively, see Best practices for Password Synchronization.

  • For help with specific tasks, see How To .....

  • For general background information, see Password Synchronization Concepts.

  • For problem-solving instructions, see Troubleshooting Password Synchronization.

  • For information about the Password Synchronization command-line utility, see Command-line utility.


Checklists for Password Synchronization

Checklists

  • Checklist: Setting up Password Synchronization for use with standalone UNIX hosts

  • Checklist: Setting up Password Synchronization for use with an NIS domain (UNIX master server)

  • Checklist: Setting up Password Synchronization for use with an NIS domain (Server for NIS master server)


Checklist: Setting up Password Synchronization for use with standalone UNIX hosts

Checklist: Setting up Password Synchronization for use with standalone UNIX hosts

Configuring Windows systems

Step | Reference
Read about Password Synchronization. | Password Synchronization Concepts
Log on as a member of the Administrators group. |
Install Password Synchronization on the appropriate Windows-based computers. If the passwords of local accounts on a server are to be synchronized, install Password Synchronization on the server. If Windows domain passwords are to be synchronized, install Password Synchronization on all domain controllers. | Install Password Synchronization
Change the encryption key. | Set the default encryption key
Change other settings, as needed. | Configure Password Synchronization
Add UNIX computers with which passwords will be synchronized. If you want to use nondefault values, specify values for the port number, encryption key, or both. | Add and remove computers for synchronization
Ensure that the Password Synchronization configurations on all domain controllers in the domain are identical. |

Configuring UNIX systems

Step | Reference
Install and configure the Password Synchronization single sign-on daemon (SSOD) on all UNIX computers with which passwords will be synchronized. Be sure to change the default encryption key in the sso.conf file to match the Password Synchronization encryption key set in previous steps before copying it to the UNIX computers. | Install the Password Synchronization daemon
Specify which users will and will not be allowed to synchronize passwords. | Controlling password synchronization for user accounts
Start the Password Synchronization daemon. | Start the Password Synchronization daemon
Install and configure the Password Synchronization pluggable authentication module (PAM) on all UNIX computers from which password changes are to be synchronized with Windows passwords. | Configure UNIX Computers for UNIX-to-Windows Synchronization


Checklist: Setting up Password Synchronization for use with an NIS domain (UNIX master server)

Checklist: Setting up Password Synchronization for use with an NIS domain (UNIX master server)

Configuring Windows systems

Step | Reference
Read about Password Synchronization. | Password Synchronization Concepts
Log on as a member of both the Schema Administrators and Enterprise Administrators groups. |
Install Password Synchronization on the appropriate Windows-based computers. If the passwords of local accounts on a server are to be synchronized, install Password Synchronization on the server. If Windows domain passwords are to be synchronized, install Password Synchronization on all domain controllers. | Install Password Synchronization
Change the encryption key. | Set the default encryption key
Change other settings, as needed. Be sure to select the Synchronize password changes from computers that run UNIX to computers that run Windows check box. | Configure Password Synchronization
Add the Network Information Service (NIS) master server to the list of computers with which the Windows-based computer will synchronize passwords. Select the NIS master server in the list, click Configure, select both the Synchronize password changes to and Synchronize password changes from check boxes, and then click OK. | Add and remove computers for synchronization
Add UNIX computers with which passwords will be synchronized. For each computer, select the computer in the list, click Configure, clear the Synchronize password changes to check box, select the Synchronize password changes from check box, and then click OK. If you want to use nondefault values, specify values for the port number, encryption key, or both. | Add and remove computers for synchronization
Specify which users will and will not be allowed to synchronize passwords. | Controlling password synchronization for user accounts
Ensure that the Password Synchronization configurations on all domain controllers in the domain are identical. |

Configuring UNIX systems

Step Reference

Install and configure the Password Synchronization single sign-on daemon (SSOD) on the NIS master server. Be sure to change the default encryption key in the sso.conf file to match the Password Synchronization encryption key set in previous steps before copying it to the server, and edit it to specify the following:

  • USE_NIS=1

  • NIS_UPDATE_PATH= Makefile_path, where Makefile_path is the path and name of the NIS makefile, such as /var/yp/Makefile

Install and configure the Password Synchronization pluggable authentication module (PAM) on all UNIX computers from which password changes are to be synchronized with Windows passwords. Typically, this would be any computer on which users would run yppasswd and any standalone computers (computers that do not belong to the domain).

Configure UNIX Computers for UNIX-to-Windows Synchronization

Copy the sso.conf file from the NIS master server to the /etc directory of each computer on which the Password Synchronization PAM module is installed.

On each NIS client on which you installed the Password Synchronization PAM module, replace the yppasswd binary file with a link to the passwd binary file, and then edit the /etc/nsswitch.conf file to change the passwd and shadow lines, as shown:

passwd:  files [NOTFOUND=continue] nis
shadow:  files [NOTFOUND=continue] nis

Start the Password Synchronization daemon on the NIS master server.

Start the Password Synchronization daemon


Checklist: Setting up Password Synchronization for use with an NIS domain (Server for NIS master server)

Checklist: Setting up Password Synchronization for use with an NIS domain (Server for NIS master server)

Configuring Windows systems

Step | Reference
Read about Password Synchronization. | Password Synchronization Concepts
Log on as a member of both the Schema Administrators and Enterprise Administrators groups. |
Install Password Synchronization on all domain controllers. | Install Password Synchronization
Change the encryption key. | Set the default encryption key
Change other settings, as needed. Be sure to select the Synchronize password changes from computers that run UNIX to computers that run Windows check box. | Configure Password Synchronization
Add UNIX computers with which passwords will be synchronized if they are not members of the Network Information Service (NIS) domain. For each computer, select the computer in the list, click Configure, clear the Synchronize password changes to check box, select the Synchronize password changes from check box, and then click OK. If you want to use nondefault values, you can also specify values for the port number, encryption key, or both. | Add and remove computers for synchronization
Ensure that the Password Synchronization configurations on all domain controllers in the domain are identical. |
Specify which users will and will not be allowed to synchronize passwords. | Controlling password synchronization for user accounts

Configuring UNIX systems

Step Reference

Install and configure the Password Synchronization pluggable authentication module (PAM) on all UNIX computers from which password changes are to be synchronized with Windows passwords. Typically, this would be any computer on which users would run yppasswd and any computers that do not belong to the NIS domain.

Configure UNIX Computers for UNIX-to-Windows Synchronization

Using a binary file-copy method such as File Transfer Protocol (FTP) to avoid corrupting CR/LF (carriage-return/line-feed) pairs, copy Sso.cfg from IDMU\Unix\Bins on the Windows Server 2003 R2 CD to the /etc directory of each computer on which the Password Synchronization PAM module is installed, and change its name to sso.conf. Open the file with a text editor, and then perform the following steps:

  1. Edit the following line to specify the encryption key. This value must match the default key specified on all domain controllers with which this computer will synchronize passwords:

    ENCRYPT_KEY= encryptionKey

  2. If you have changed the default port, edit the following line to specify the new port. This value must match the port number specified on all domain controllers with which this computer will synchronize passwords.

    PORT_NUMBER= portNumber

  3. Edit the following line to specify the computer running Server for NIS. If you have specified a nondefault port number or encryption key for the UNIX computer when configuring Password Synchronization on the Windows domain controller, specify that value where indicated; otherwise, leave the value blank:

    SYNC_HOSTS=( domainController[, portNumber [, encryptionKey]])

On each NIS client on which you installed the Password Synchronization PAM module, replace the yppasswd binary file with a link to the passwd binary file, and then edit the /etc/nsswitch.conf file to change the passwd and shadow lines, as shown:

passwd:  files [NOTFOUND=continue] nis
shadow:  files [NOTFOUND=continue] nis


Best practices for Password Synchronization

Best practices

  • Install Password Synchronization on appropriate domain controllers To ensure consistent synchronization of domain passwords with UNIX passwords, Password Synchronization must be installed on the primary domain controller and, in the case of a Windows 2000 domain, all domain controllers in a domain.

    • If you add a domain controller to a domain, you should install Password Synchronization on the new domain controller as soon as possible and configure it to match the other domain controllers.

    • If you need to remove Password Synchronization from any domain controller, you should demote the server to a member server before uninstalling Password Synchronization.

  • Ensure consistent password policies If you are providing only for one-way password synchronization, make sure that the password policy on the computer from which passwords will be synchronized is at least as restrictive in all areas as the policy on the computer to which passwords will by synchronized. For example, if you configure Windows-to-UNIX synchronization, the Windows password policy must be at least as restrictive as the policy of the UNIX computers with which it will synchronize passwords. If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Failure to ensure that password policies are consistent can result in synchronization failure when a user changes a password on the less restrictive system, or the password might be changed on the more restrictive system even though it does not conform to the system's policies.

    Also make sure that Windows users are aware of any special password restrictions on the UNIX systems with which their passwords will be synchronized. For example, some versions of UNIX support a maximum password length of eight characters. For maximum compatibility with the default Windows password policy and these UNIX limitations, passwords should be seven or eight characters long unless you are sure that all UNIX systems can support longer passwords.

  • Configure Password Synchronization to provide the maximum protection for your users' passwords

    Follow these recommendations to maintain optimal security:

    • Explicitly list the users whose passwords are to be synchronized To provide maximum control over which users can synchronize passwords, do not use the ALL keyword with the SYNC_USERS list in sso.conf on the UNIX host. Instead, you should explicitly list each user for whom password synchronization is allowed or blocked. On the Windows-based computer running Password Synchronization, create the PasswordPropAllow group and add the accounts of users whose passwords you want to synchronize. For more information, see Controlling password synchronization for user accounts.

    • Do not synchronize passwords for disabled UNIX accounts On some versions of UNIX, changing the password of a disabled user account activates that account. Consequently, if a user has a disabled account on a UNIX computer that is configured to synchronize passwords with a Windows-based computer, the user or an administrator can activate the UNIX account by changing the user's Windows password. To prevent this, use the PasswordPropDeny group to block synchronization for disabled UNIX accounts.

      Also, when an administrator disables a UNIX account, the administrator should use the SYNC_USERS entry in sso.conf to block password synchronization for the account.

    • Avoid synchronizing administrator passwords Do not synchronize passwords for members of the Windows Administrators groups or the passwords of UNIX superuser or root accounts.

    • Perform the Windows Server 2003 Service Pack 1 (SP1) compatibility check when selecting Enable Windows to NIS (AD) Password Sync in the Password Synchronization Properties dialog box, Configuration tab. To protect the security of user account passwords in your enterprise, it is strongly recommended that you allow Password Synchronization to identify all domain controllers in the forest that are not running Windows Server 2003 SP1 or later releases.

      Password Synchronization prompts you to allow the compatibility check when you select the Enable Windows to NIS (AD) Password Sync option. With Windows Server 2003 SP1, or a later release installed on all the domain controllers in a forest, the risk of exposing user password hashes to unauthorized viewers is greatly reduced. When Windows Server 2003 SP1 is not the minimum functional level of all the domain controllers in a forest, it is possible for any authenticated user on the domain to view the password hash for any UNIX user whose account has been migrated to Active Directory.

      In the event an unauthorized user breaks the password hash for a UNIX-based user account in Active Directory, the Windows-based password for the account is no longer secure.

    Also, when an administrator disables a UNIX account, the administrator should use the SYNC_USERS entry in sso.conf to block password synchronization for the account.

    Password Synchronization prompts you to allow the compatibility check when you select the Enable Windows to NIS (AD) Password Sync option. With Windows Server 2003 SP1, or a later release installed on all the domain controllers in a forest, the risk of exposing user password hashes to unauthorized viewers is greatly reduced. When Windows Server 2003 SP1 is not the minimum functional level of all the domain controllers in a forest, it is possible for any authenticated user on the domain to view the password hash for any UNIX user whose account has been migrated to Active Directory.

    In the event an unauthorized user breaks the password hash for a UNIX-based user account in Active Directory, the Windows-based password for the account is no longer secure.

When Password Synchronization is installed, members of the local Administrators group and the Domain Admins group are added to the PasswordPropDeny group, which prevents their passwords from being synchronized. If you add a user to either the Administrators or Domain Admins group, be sure to add the user to the PasswordPropDeny group as well.

Use the SYNC_USERS statement in the sso.conf file on all UNIX systems to prevent the passwords of superusers from being synchronized.

  • Do not use the default port number and encryption key If you use the default port number and encryption key, you make it possible for an attacker to set up an impostor UNIX host to capture passwords. You should protect the port number and encryption keys used to synchronize passwords as carefully as the passwords themselves.

  • Secure the sso.conf file The sso.conf file on each UNIX host contains important configuration information that could be used to compromise security. It is recommended that you set the mode bit mask of the file to 600.

  • Ensure that the directory identified by TEMP_FILE_PATH is properly protected The temporary files created on UNIX hosts by Password Synchronization contain information that could be used by an attacker to compromise system security. For this reason, you should ensure that any directory referenced by TEMP_FILE_PATH in sso.conf has read access only for the root account and cannot be accessed by any other users.

  • Ensure log files are appropriately protected On the UNIX host, Password Synchronization uses the syslogd daemon to log messages that result from synchronization operations. The resulting logs contain such information as the names of users whose passwords are being synchronized and with which computers, propagation errors, and so on. These log files should be protected to ensure that only administrators can read them.

  • Restart the Password Synchronization daemon after changing its configuration When you make changes to the Password Synchronization daemon configuration file (sso.conf), you must stop and restart the daemon to make sure that the configuration changes take effect.

  • Configure systems to handle user name case sensitivity correctly Unless you rigorously enforce a policy to ensure that Windows and UNIX user names match in both spelling and case, make sure that the CASE_IGNORE_NAME option in the sso.conf file is set to 1 (the default). UNIX user names are case sensitive; therefore, passwords might not synchronize properly if the user names do not match exactly because the Password Synchronization daemon is unable to associate the Windows user name with the corresponding UNIX user name.

  • Make sure that password file type and name are consistent When you configure the Password Synchronization daemon, make sure that the password file type (specified by USE_SHADOW) and path name (set by FILE_PATH) are appropriate for each other. For example, on most systems, if USE_SHADOW is set to 0 (to indicate that the passwd file is used for synchronization), then the FILE_PATH option should be set to /etc/passwd. However, if USE_SHADOW is set to 1 (to indicate that the shadow file is used instead), then the FILE_PATH option should be set to /etc/shadow. (On AIX systems, the path and name of the shadow file is /etc/security/passwd.)


This content might have been updated. For the most recent version, see the Windows Server 2003 R2 TechCenter Web site

How To ....

  • Use UNIX Components

  • Use Windows Components


Use UNIX Components

Use UNIX Components

  • Install the Password Synchronization daemon

  • Start the Password Synchronization daemon

  • Stop the Password Synchronization daemon

  • Configure UNIX Computers for UNIX-to-Windows Synchronization


Install the Password Synchronization daemon

To install the Password Synchronization daemon

  1. Copy the appropriate source binary file from IDMU\Unix\Bins on the Windows Server 2003 R2 CD to /usr/bin or /usr/local/bin on the UNIX computer, and change its name to ssod. The name of the source binary file depends on the version of UNIX you are using.

    • If the computer is running Hewlett-Packard HP-UX, the source binary file name is ssod.hpx.

    • If the computer is running Red Hat Linux, the source binary file name is ssod.rhl.

    • If the computer is running Sun Microsystems Solaris, the source binary file name is ssod.sol.

    • If the computer is running IBM AIX, the source binary file name is ssod.aix.

  2. Using a binary file-copy method such as File Transfer Protocol (FTP) to avoid corrupting CR/LF (carriage-return/line-feed) pairs, copy Sso.cfg from \Unix\Bins on the Windows Server 2003 R2 CD to /etc on the UNIX computer, and change its name to sso.conf.

  3. Open sso.conf with a text editor.

  4. If you have changed the default encryption key, edit the following line to specify the new default key. This value must match the default key specified on all domain controllers with which this computer will synchronize passwords:

    ENCRYPT_KEY= encryptionKey

  5. If you have changed the default port, edit the following line to specify the new port. This value must match the port number specified on all domain controllers with which this computer will synchronize passwords.

    PORT_NUMBER= portNumber

  6. Edit the following line to specify one domain controller in each Windows domain with which the computer is to synchronize passwords. If you have specified a nondefault port number or encryption key for the UNIX computer when configuring Password Synchronization on the Windows domain controllers, specify that value where indicated; otherwise, leave the value blank:

    SYNC_HOSTS=( domainController[, portNumber [, encryptionKey]]) ...

    Each entry in the list must be enclosed by parentheses (the "(" and ")" characters) and separated from the next entry by a blank space.

  7. If the computer is a Network Information Service (NIS) master server, and if you want passwords to be synchronized throughout the NIS domain, edit the following line as shown to enable NIS synchronization:

    USE_NIS=1

    Also, if required, edit the following line to specify the location of the NIS makefile:

    NIS_UPDATE_PATH= makefilePath

  8. Set the file permissions of sso.conf to read/write for the root user only, and deny access to all other users.

  9. If the computer is running Linux, copy /etc/pam.d/system-auth to /etc/pam.d/ssod.

Important

The sso.conf file contains encryption keys and other sensitive information. For this reason, it must be accessible only by system administrators.

Notes
  • This daemon program must be installed on the computer running UNIX to enable Password Synchronization to change users' passwords on that computer.
  • Password Synchronization supports synchronization with UNIX computers running any of the following operating systems:
  • Hewlett-Packard HP-UX version 11i

  • IBM AIX version 5L 5.2

  • Red Hat Linux versions 8 and 9

  • Sun Solaris version 8 running on x86-based computers and Scalable Processor Architecture (SPARC)–based computers, and Solaris version 9 running on SPARC–based computers

See Also

  • Understanding Password Synchronization
  • Using sso.conf to configure Password Synchronization on the UNIX computer
  • Start the Password Synchronization daemon
  • Install the pluggable authentication module (PAM) on AIX
  • Install the pluggable authentication module (PAM) on HP-UX
  • Install the pluggable authentication module (PAM) on Linux
  • Install the pluggable authentication module (PAM) on Solaris


Start the Password Synchronization daemon

  • Run the single sign-on daemon (SSOD).

Notes
  • There is no other method for this procedure.
  • The sso.conf file must be in the /etc/ directory.
  • If you see no errors, the daemon is running. If anything goes wrong during the initialization of the daemon, an error message is displayed on the console. Some errors might also be logged to the Syslog file.
  • If you want your service to start automatically, add the single sign-on daemon (SSOD) to your system startup files (typically Rc.local). This will start SSOD as root.

See Also

  • Install the Password Synchronization daemon
  • Understanding Password Synchronization


Stop the Password Synchronization daemon

  • Send the process a TERM signal as follows:

    kill –term pid

    where pid is the process identifier of the Password Synchronization single sign-on daemon (SSOD).

See Also

  • Understanding Password Synchronization


Configure UNIX Computers for UNIX-to-Windows Synchronization

Configure UNIX computers for UNIX-to-Windows synchronization

  • Install the pluggable authentication module (PAM) on AIX

  • Install the pluggable authentication module (PAM) on HP-UX

  • Install the pluggable authentication module (PAM) on Linux

  • Install the pluggable authentication module (PAM) on Solaris


Install the pluggable authentication module (PAM) on AIX

To install the pluggable authentication module (PAM) on AIX

  1. Copy pam_sso.aix from IDMU\Unix\Bins on the Windows Server 2003 R2 CD to /usr/lib/ on the UNIX computer, and change its name to pam_sso.aix.1.

  2. On the UNIX computer, log on as root, and then enter the following commands:

    chown root /usr/lib/pam_sso.aix.1 chmod 555 /usr/lib/pam_sso.aix.1

  3. If necessary, create the /etc/pam.conf file according to your network requirements, setting the owner to root and the base permissions to 644. For more information about creating the pam.conf file, see "Pluggable Authentication Modules" in System Management Guides: Security Guide in your AIX documentation.

    Sample pam.conf file

    #
# Authentication management
#
OTHER   auth     required       /usr/lib/security/pam_aix

#
# Account management
#
OTHER   account  required       /usr/lib/security/pam_aix

#
# Session management
#
OTHER   session  required       /usr/lib/security/pam_aix
  4. Open /etc/pam.conf with a text editor.

  5. In the Password management section, add the following line:

    passwd password required /usr/lib/security/pam_sso.aix.1

    Sample pam.conf file with this line added

    #
# Authentication management
#
OTHER   auth     required       /usr/lib/security/pam_aix

#
# Account management
#
OTHER   account  required       /usr/lib/security/pam_aix

#
# Session management
#
OTHER   session  required       /usr/lib/security/pam_aix

#
# Password management
#
passwd   password required       /usr/lib/security/pam_sso.aix.1
  6. Open /usr/lib/security/methods.cfg with a text editor and add the following lines at the end of the file:

    PAM: program = /usr/lib/security/PAM

    PAMfiles: options = auth=PAM,db=BUILTIN

  7. Open /etc/security/user with a text editor and add authentication information for the specific users whose passwords you want to synchronize. For example:

    user1: admin = false SYSTEM = PAMfiles[*] AND "compat" registry = PAMfiles

Notes
  • You can choose to change the default section of /etc/security/user to allow all users to synchronize their passwords. In this case, to restrict access to Password Synchronization, you can use the SYNC_USERS attribute in the /etc/sso.conf file to restrict access. For more information, see Using sso.conf to configure Password Synchronization on the UNIX computer.
  • To disable UNIX-to-Windows password synchronization, remove the entry in /etc/pam.conf that you added in step 5.

See Also

  • Understanding Password Synchronization
  • Implementing Password Synchronization


Install the pluggable authentication module (PAM) on HP-UX

To install the pluggable authentication module (PAM) on HP-UX

  1. Copy pam_sso.hpx from IDMU\Unix\Bins on the Windows Server 2003 R2 CD to /usr/lib/security on the UNIX computer, change its name to pam_sso.hp.1, and then set its file-mode bits to 544.

  2. On the UNIX computer, open /etc/pam.conf with a text editor.

  3. In the Password management section, locate the following line:

    other password required /usr/lib/security/libpam_unix.1

  4. Immediately following the line located in the previous step, add the following line:

    other password required /usr/lib/security/pam_sso.hp.1

Notes
  • To disable UNIX-to-Windows password synchronization, remove the entry in /etc/pam.conf that you added in step 4.
  • Before installing the pam_sso module, make sure that PAM support is properly installed and configured on the UNIX computer. The following file samples show a typical configuration. Actual contents of these files may differ, depending on your system configuration.
  • Sample HP-UX PAM configuration file
#
# PAM configuration
#
# Authentication management
#
login    auth required  /usr/lib/security/libpam_unix.1
su       auth required  /usr/lib/security/libpam_unix.1
dtlogin  auth required  /usr/lib/security/libpam_unix.1
dtaction auth required  /usr/lib/security/libpam_unix.1
ftp      auth required  /usr/lib/security/libpam_unix.1
OTHER    auth required  /usr/lib/security/libpam_unix.1
#
# Account management
#
login    account required       /usr/lib/security/libpam_unix.1
su       account required       /usr/lib/security/libpam_unix.1
dtlogin  account required       /usr/lib/security/libpam_unix.1
dtaction account required       /usr/lib/security/libpam_unix.1
ftp      account required       /usr/lib/security/libpam_unix.1
#
OTHER    account required       /usr/lib/security/libpam_unix.1
#
# Session management
#
login    session required       /usr/lib/security/libpam_unix.1
dtlogin  session required       /usr/lib/security/libpam_unix.1
dtaction session required       /usr/lib/security/libpam_unix.1
OTHER    session required       /usr/lib/security/libpam_unix.1
#
# Password management
#
login    password required      /usr/lib/security/libpam_unix.1
dtlogin  password required      /usr/lib/security/libpam_unix.1
dtaction password required      /usr/lib/security/libpam_unix.1
other    password required      /usr/lib/security/libpam_unix.1
other    password required      /usr/lib/security/pam_sso.hp.1

See Also

  • Understanding Password Synchronization
  • Implementing Password Synchronization


Install the pluggable authentication module (PAM) on Linux

To install the pluggable authentication module (PAM) on Linux

  1. Copy pam_sso.rhl from IDMU\Unix\Bins on the Windows Server 2003 R2 CD to /lib/security on the UNIX computer, and change its name to pam_sso.so.1.

  2. On the UNIX computer, copy /etc/pam.d/system-auth to /etc/pam.d/ssod.

  3. Open /etc/pam.d/system-auth with a text editor, and locate the following line:

    passwordrequired/lib/security/pam_cracklib.soretry=3

  4. After the line in the previous step, add the following line:

    password required /lib/security/pam_sso.so.1

  5. Locate and delete the following line:

    passwordrequired/lib/security/pam_deny.so

  6. Save the modified file.

Notes
  • These instructions apply to the typical Linux configuration. If you have configured PAM support differently, you might have to adjust these instructions to your specific configuration.
  • To disable UNIX-to-Windows password synchronization, remove the entry in /etc/pam.d/system-auth that you added in step 4.
  • Before installing the pam_sso module, make sure that PAM support is properly installed and configured on the UNIX computer. The following file samples show a typical configuration. Actual contents of these files may differ, depending on your system configuration.
  • Sample Linux PAM configuration file:
/etc/pam.d/passwd

#%PAM-1.0
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth

/etc/pam.d/ssod

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/pam_unix.so nullok use_authtok shadow
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

/etc/pam.d/system-auth

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    required      /lib/security/pam_sso.so.1
password    sufficient    /lib/security/pam_unix.so nullok use_authtok shadow
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

See Also

  • Understanding Password Synchronization
  • Implementing Password Synchronization


Install the pluggable authentication module (PAM) on Solaris

To install the pluggable authentication module (PAM) on Solaris

  1. Copy pam_sso.sol from the IDMU\Unix\Bins folder on the Windows Server 2003 R2 CD to the /usr/lib/security directory on the UNIX computer, and change its name to pam_sso.so.1.

  2. On the UNIX computer, open /etc/pam.conf with a text editor.

  3. In the Password management section, locate the following line:

    other password required /usr/lib/security/$ISA/pam_unix.so.1

  4. Immediately following the line located in the previous step, add the following line:

    other password required /usr/lib/security/$ISA/pam_sso.so.1

Notes
  • To disable UNIX-to-Windows password synchronization, remove the entry in /etc/pam.conf that you added in step 4.
  • Before installing the pam_sso module, make sure that PAM support is properly installed and configured on the UNIX computer. The following file samples show a typical configuration. Actual contents of these files may differ, depending on your system configuration.
  • Sample Solaris PAM configuration file
#
#ident  "@(#)pam.conf   1.14    99/09/16 SMI"
#
# Copyright (c) 1996-1999, Sun Microsystems, Inc.
# All Rights Reserved.
#
# PAM configuration
#
# Authentication management
#
login   auth required   /usr/lib/security/$ISA/pam_unix.so.1
login   auth required   /usr/lib/security/$ISA/pam_dial_auth.so.1
#
rlogin  auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
rlogin  auth required   /usr/lib/security/$ISA/pam_unix.so.1
#
dtlogin auth required   /usr/lib/security/$ISA/pam_unix.so.1
#
rsh     auth required   /usr/lib/security/$ISA/pam_rhosts_auth.so.1
other   auth required   /usr/lib/security/$ISA/pam_unix.so.1
#
# Account management
#
login   account requisite       /usr/lib/security/$ISA/pam_roles.so.1
login   account required        /usr/lib/security/$ISA/pam_unix.so.1
#
dtlogin account requisite       /usr/lib/security/$ISA/pam_roles.so.1
dtlogin account required        /usr/lib/security/$ISA/pam_unix.so.1
#
other   account requisite       /usr/lib/security/$ISA/pam_roles.so.1
other   account required        /usr/lib/security/$ISA/pam_unix.so.1
#
# Session management
#
other   session required        /usr/lib/security/$ISA/pam_unix.so.1
#
# Password management
#

other   password required       /usr/lib/security/$ISA/pam_unix.so.1
other  password required        /usr/lib/security/$ISA/pam_sso.so.1
dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1

#
# Support for Kerberos V5 authentication (uncomment to use Kerberos)
#
#rlogin auth optional   /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#login  auth optional   /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#dtlogin        auth optional   /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#other  auth optional   /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
#dtlogin        account optional /usr/lib/security/$ISA/pam_krb5.so.1
#other  account optional /usr/lib/security/$ISA/pam_krb5.so.1
#other  session optional /usr/lib/security/$ISA/pam_krb5.so.1
#other  password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass

See Also

  • Understanding Password Synchronization
  • Implementing Password Synchronization


Use Windows Components

Use Windows components

  • Install Password Synchronization

  • Configure Password Synchronization


Install Password Synchronization

To install Password Synchronization

  1. Click Start, click Control Panel, and then click Add or Remove Programs.

  2. Click Add/Remove Windows Components.

  3. When the Windows Components Wizard opens, fill the Active Directory Services check box.

  4. With Active Directory Services highlighted, click Details.

  5. When the Active Directory Services dialog box opens, fill the Identity Management for UNIX check box.

  6. With Identity Management for UNIX highlighted, click Details.

  7. When the Identity Management for UNIX dialog box opens, fill the Password Synchronization check box.

  8. Click OK.

    The Windows Components Wizard begins installing the Identity Management for UNIX components you selected.

  9. If you are prompted to locate files required for Password Synchronization installation, insert the Windows Server 2003 R2 product CD, or browse to the network location of your Windows Server 2003 R2 installation files.

Notes
  • To open Add or Remove Programs, click Start, point to Control Panel, and then click Add or Remove Programs.
  • Password Synchronization cannot be run from a network server. All files must be installed on the local computer.
  • You must be logged on to the computer as a member of both the Schema Administrators and Enterprise Administrators groups to install Password Synchronization. The Password Synchronization installation process verifies that users have both Schema Administrator and Enterprise Administrator access permissions before installation can progress.

See Also

  • Install the Password Synchronization daemon


Configure Password Synchronization

Configure Password Synchronization

  • Set default synchronization

  • Set the default encryption key

  • Set the default port

  • Add and remove computers for synchronization

  • Set computer-specific synchronization properties

  • Set auditing options


Set default synchronization

To set default synchronization

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Password Synchronization, and then click the Default tab.

  4. To allow password synchronization from UNIX-based computers to Windows-based computers, click Synchronize password changes from computers that run UNIX to computers that run Windows.

  5. To allow password synchronization from Windows-based computers to UNIX-based computers, click Synchronize password changes from computers that run Windows to computers that run UNIX.

  6. To save the new settings, click Apply.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • To perform this task in the command line environment, see psadmin.
  • These settings affect the default synchronization for UNIX hosts when they are added for synchronization. It does not affect computers that have already been added for synchronization.

See Also

  • Add and remove computers for synchronization
  • Password Synchronization administration
  • Connect to a computer you want to manage


Set the default encryption key

To set the default encryption key

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Password Synchronization, and then click the Default tab.

  4. In the Encryption key text box, type the key you want to use, or, to have the program produce a key for you, click New Key.

  5. To save the new settings, click Apply.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • To perform this task in the command line environment, see psadmin.
  • This setting affects the default encryption key for UNIX hosts when they are added for synchronization as well as the port used for UNIX-to-Windows synchronization. If you change this setting, you must edit the /etc/sso.conf file to specify the same encryption key on UNIX hosts that are configured for UNIX-to-Windows password synchronization with this computer.
  • For maximum security, you should use a key that is the maximum 21 characters in length.

See Also

  • Encryption key requirements
  • Add and remove computers for synchronization
  • Password encryption
  • Password Synchronization administration
  • Using sso.conf to configure Password Synchronization on the UNIX computer


Set the default port

To set the default port

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Password Synchronization, and then click the Default tab.

  4. To use a port other than 6677, in the Port number box, type the port number you want.

  5. To save the new settings, click Apply.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • This setting affects the default port number for UNIX hosts when they are added for synchronization as well as the port used for UNIX-to-Windows synchronization. If you change this setting, you must edit the /etc/sso.conf file to specify the same port on UNIX hosts that are configured for UNIX-to-Windows password synchronization with this computer.
  • For maximum security, use a port number other than the default (6677).
  • To perform this task in the command line environment, see psadmin.

See Also

  • Add and remove computers for synchronization
  • Password Synchronization administration
  • Using sso.conf to configure Password Synchronization on the UNIX computer
  • Connect to a computer you want to manage


Add and remove computers for synchronization

To add and remove computers for synchronization

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Password Synchronization.

  4. Click the Advanced tab, and then do one of the following:

    • To add a computer to the list of participating computers, in Computer name, type the name of the UNIX-based computer you want to add, and then click Add.

    • To remove a computer, in the Current computers list, click the UNIX-based computer you want to remove, and then click Remove.

  5. To save the new settings, click Apply.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • To perform this task in the command line environment, see psadmin.
  • In addition to adding a UNIX-based computer to the list, if you want to change the user's password on the UNIX computer when the corresponding Windows user's password is changed, you must install the Password Synchronization single sign-on daemon (SSOD) on the UNIX-based computer . If you want to change the Windows user's password when the corresponding UNIX-based computer user's password is changed, you must install the pluggable authentication module (PAM) on the UNIX-based computer.

See Also

  • Set computer-specific synchronization properties
  • Install the Password Synchronization daemon
  • Configure UNIX Computers for UNIX-to-Windows Synchronization
  • Password Synchronization administration
  • Connect to a computer you want to manage


Set computer-specific synchronization properties

To set computer-specific synchronization properties

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Password Synchronization, and then click the Advanced tab.

  4. In the Current computers list, click the one for which you want to set properties, and then click Configure.

  5. Set the properties you want to apply to the selected computer.

  6. To save the new settings, click Apply.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • To perform this task in the command line environment, see psadmin.
  • Before setting computer-specific synchronization properties in Password Synchronization, edit the sso.conf file on the UNIX-based computer to specify the same settings. For information about assigning computer-specific settings in the sso.conf file, see Install the Password Synchronization daemon.

See Also

  • Set default synchronization
  • Set the default encryption key
  • Set the default port
  • Password Synchronization administration
  • Connect to a computer you want to manage


Set auditing options

To set auditing options

  1. Open Identity Management for UNIX.

  2. If necessary, connect to the computer you want to manage.

  3. Click Password Synchronization, and then click the Default tab.

  4. To have information events as well as warnings and errors logged to Event Viewer, click Enable extensive logging.

  5. To save the new settings, click Apply.

Notes
  • To open Identity Management for UNIX, click Start, point to All Programs, point to Identity Management for UNIX, and then click Identity Management for UNIX.
  • To perform this task in the command line environment, see psadmin.
  • When the log file reaches the limit you set, logging stops and a note is entered in Event Viewer.

See Also

  • Password Synchronization administration
  • Connect to a computer you want to manage


Password Synchronization Concepts

This section provides background information about:

  • Understanding Password Synchronization

  • Administering Password Synchronization


Understanding Password Synchronization

Understanding Password Synchronization

Password Synchronization helps integrate Windows and UNIX networks by simplifying the process of maintaining secure passwords in both environments. Users are freed of the difficulty of maintaining separate passwords for their Windows and UNIX accounts or having to remember to change the password wherever it is used. With Password Synchronization, whenever a user's password is changed on a Windows-based computer or domain, the password can also be automatically changed on every UNIX host for which the user has an account. Password Synchronization can also be configured to change the user's Windows password when the user's UNIX password is changed.

This makes it possible to administer passwords from a single computer, which simplifies things for administrators as well as individual users. Password Synchronization is also flexible: administrators can exclude specific users and systems from being synchronized. Password Synchronization can synchronize passwords on stand-alone Windows-based computers (such as computers running Windows 2000 Server that do not belong to a domain) or for an entire Windows domain. Similarly, Password Synchronization can be used to manage passwords on individual UNIX hosts or on all computers in a Network Information Service (NIS) domain.

Password Synchronization propagates passwords securely by transmitting only encrypted passwords over TCP/IP sockets. This eliminates the need to use nonsecure methods (such as scripts) to administer passwords remotely. Passwords are also synchronized immediately. This means that, unlike methods such as rdist, which batches the password propagation, there is no appreciable delay between the time that a password is changed on one system and when it is changed on all other affected systems. This eliminates confusion and frustration for active users. Even more important, perhaps, it eliminates a potential security risk if a password needs to be changed to block a user's access to the network. To enhance network security even further, different encryption keys can be used for each Windows-based computer/UNIX host pair.

Password Synchronization is a combination of three software components:

  • The Password Synchronization service running on one or more Windows-based computers

  • The Password Synchronization daemon running on one or more UNIX computers

  • The Password Synchronization pluggable authentication module (PAM) installed on one or more UNIX computers.

When Password Synchronization is configured for Windows-to-UNIX synchronization and a password is changed on a Windows-based computer running Password Synchronization, the Password Synchronization service determines whether the user's password is to be synchronized on UNIX computers. If it is, the service encrypts the password and sends it to the Password Synchronization daemon on each computer with which the Windows-based computer is configured to be synchronized. The daemon then decrypts the password and changes the password on the UNIX host. If the UNIX host is an NIS master server and it is configured to do so, the daemon also runs make to propagate the password change throughout the NIS domain.

When Password Synchronization is configured for UNIX-to-WINDOWS synchronization, passwords that are changed on UNIX hosts are synchronized on Windows-based computers and domains. The Password Synchronization PAM module makes this possible by intercepting the password change request on the UNIX host, encrypting the password, and then sending the password change request to the Password Synchronization service running on the Windows-based computers with which it is configured to be synchronized.

For information about implementing Password Synchronization, see Implementing Password Synchronization.


Administering Password Synchronization

Administering Password Synchronization

This section contains information about:

  • Implementing Password Synchronization

  • Synchronizing passwords with an NIS domain

  • Password Synchronization administration

  • Password encryption

  • Encryption key requirements

  • Controlling password synchronization for user accounts

  • Using sso.conf to configure Password Synchronization on the UNIX computer


Implementing Password Synchronization

Implementing Password Synchronization

Password Synchronization changes a user's UNIX password whenever the user's password is changed on a Windows-based computer or domain. In addition, Password Synchronization and the affected UNIX hosts can be configured to change the user's Windows password whenever the UNIX password is changed.

Two-way password synchronization is supported on UNIX computers running any of the following operating systems:

  • Hewlett-Packard HP-UX version 11i, 32-bit environment

  • IBM AIX version 5L 5.2, 32-bit environment

  • Red Hat Linux versions 8 and 9, 32-bit environment

  • Sun Solaris version 8 running on x86-based computers and Scalable Processor Architecture (SPARC)–based computers, and Solaris version 9 running on SPARC–based computers. The 32-bit environment has been tested on SPARC-based computers.

For more information about how Password Synchronization works on Windows and UNIX computers, see Understanding Password Synchronization.

The remainder of this topic provides information about how to implement password synchronization on Windows and UNIX computers.

Installing Password Synchronization in Windows
You can use Password Synchronization to synchronize passwords between a Windows domain and one or more UNIX hosts, or you can use it to synchronize passwords between a stand-alone computer running Windows and one or more UNIX hosts. To synchronize local account passwords on a Windows-based computer, install Password Synchronization on that computer only. To synchronize Windows domain passwords, you must install Password Synchronization on all domain controllers for that domain. This will ensure that when a domain controller processes a password change request, the Password Synchronization service on that domain controller will be able to synchronize the new password with the appropriate UNIX hosts. For this reason, before you remove Password Synchronization from a domain controller, you should demote the domain controller to a member server to prevent password discrepancies between the Windows domain and the UNIX hosts. For information about installing Password Synchronization on Windows-based computers, see Install Password Synchronization.
Installing the Password Synchronization daemon on UNIX hosts
To allow synchronization of Windows passwords with UNIX hosts, you must install the Password Synchronization daemon on each UNIX host on which passwords are to be synchronized. For information about installing the daemon, see Install the Password Synchronization daemon. When Password Synchronization receives a request for a password change, it encrypts the password and sends it to all UNIX hosts that are to be synchronized with the Windows-based computer or domain. To process the password change request, the UNIX host must be running the Password Synchronization daemon. This daemon receives the request and changes the password on the UNIX host. In addition, if the UNIX host is a master Network Information Service (NIS) server, the Password Synchronization daemon runs make to rebuild the NIS passwd map so it can be replicated to subordinate (slave) servers in the NIS domain. The Password Synchronization daemon performs event logging through the syslogd daemon running on the UNIX host.
Installing the pluggable authentication module on UNIX hosts
Pluggable authentication modules (PAMs) allow a UNIX computer to support multiple authentication technologies. Password Synchronization uses this facility to provide UNIX-to-Windows password synchronization. To allow passwords on Windows-based computers or domains to be changed when users change their UNIX password, the Password Synchronization PAM module (pam_sso) must be installed on each UNIX host where users can change their passwords. Much like Password Synchronization running on a Windows-based computer, the Password Synchronization PAM module on a UNIX computer intercepts the password change request, encrypts the password, and then transmits the request to the appropriate Windows-based computers running Password Synchronization. Like the Password Synchronization daemon, the Password Synchronization PAM module performs event logging through the syslogd daemon running on the UNIX host. For information about configuring UNIX computers for UNIX-to-Windows synchronization, see Configure UNIX Computers for UNIX-to-Windows Synchronization.
Synchronizing passwords between Windows and NIS domains
In addition to synchronizing passwords between Windows-based computers and standalone UNIX hosts, you can also use Password Synchronization to provide one-way (Windows-to-UNIX) synchronization as well as two-way synchronization. For more information, see Synchronizing passwords with an NIS domain. For security reasons, it is recommended that you perform the Windows Server 2003 Service Pack 1 (SP1) compatibility check when selecting Enable Windows to NIS (AD) Password Sync in the Password Synchronization Properties dialog box, Configuration tab. For more information about the compatibility check, see Best practices for Password Synchronization.
Coordinating account names and password policies
The password policies on both systems must be similar. If the policy on one system is stronger (more restrictive) than the policy on the other system, Password Synchronization might fail to synchronize passwords, and the failure might not be reported. In addition, Password Synchronization can only synchronize the passwords of accounts with identical user names. Windows and UNIX administrators must ensure that the user names for the Windows and UNIX accounts of a given user match exactly (including case). If you are configuring Password Synchronization for one-way (Windows-to-UNIX) synchronization, you should consider disabling the ability of users to change passwords on the UNIX hosts that are to be synchronized with the Windows-based computers. Otherwise, if users change their UNIX passwords, their passwords will no longer be synchronized.


Synchronizing passwords with an NIS domain

Synchronizing passwords with an NIS domain

Using Password Synchronization, you can provide one-way (Windows-to-UNIX) and two-way password synchronization between Windows domains and Network Information Service (NIS) domains. You can do this regardless of whether the master server of the NIS domain is running on UNIX or on Windows (Server for NIS).

If the NIS master server is running UNIX, all that is required to provide one-way synchronization is to install Password Synchronization on all Windows-based computers (for example, on the domain controllers) from which you want to synchronize passwords, and then install the single sign-on daemon (SSOD) on the NIS master server. You then edit the sso.conf file on the NIS master server to do the following:

  • Set USE_NIS to 1

  • Set NIS_UPDATE_PATH to specify the location of the NIS makefile

This instructs the SSOD to run the makefile and push the changed maps whenever a password change request is received from the Windows domain. For more information and additional instructions, see Install the Password Synchronization daemon.

If Server for NIS is acting as the master server for the NIS domain, no action is required to provide one-way password synchronization because whenever a Windows user's password is changed, Server for NIS automatically updates the UNIX password for NIS clients. If you also need to synchronize passwords with UNIX computers that are not part of the NIS domain, you can install Password Synchronization on the Windows domain controllers and configure the UNIX computers as described earlier in this topic.

Providing UNIX-to-Windows synchronization is similar for both types of NIS domains, and is accomplished by performing the following operations:

  • If the NIS master server is running UNIX, set it up for one-way synchronization as described earlier in this topic.

  • Install Password Synchronization on all domain controllers. If the NIS master server is a UNIX computer, configure Password Synchronization on Windows for two-way synchronization with the master server. Finally, add each NIS client to the list of computers that Password Synchronization will synchronize with, being sure to enable UNIX-to-Windows synchronization and disabling Windows-to-UNIX synchronization. Windows-to-UNIX synchronization should be enabled only for the NIS master server. For more information about adding and configuring computers, see Add and remove computers for synchronization and Set computer-specific synchronization properties.

  • Install the Password Synchronization pluggable authentication module (PAM) on each NIS client, and then copy the sso.conf file from the master server to the /etc directory of those clients.

  • If the NIS master server is a Windows-based computer running Server for NIS, copy Sso.cfg to one of the NIS clients, set SYNC_HOSTS to specify the computer running Server for NIS as the Windows-based computer to synchronize passwords with, and then copy that file to the other UNIX clients. See Using sso.conf to configure Password Synchronization on the UNIX computer to learn more about settings in this file.

  • Configure each UNIX computer to allow users to use the yppasswd command to change their passwords. To do this, replace the yppasswd binary file on the UNIX computer with a link to the passwd binary file, and then edit the /etc/nsswitch.conf file to replace the passwd and shadow lines with the following:

    passwd:  files [NOTFOUND=continue] nis
shadow:  files [NOTFOUND=continue] nis
    After you do this, when a user runs the yppasswd command to change the user's password, it is actually the passwd binary file that is run to change the password. If the user's passwd entry is not found in the local passwd and shadow files, the NIS password is changed instead.


Password Synchronization administration

Password Synchronization administration

When you have installed Password Synchronization on the appropriate Windows–based computer, you can administer it with Password Synchronization administration (part of Identity Management for UNIX). You must have administrator privileges on the computer you want to administer.

You can use Password Synchronization administration to:

  • Select the server to be administered.

  • Set the default settings that apply to the entire configuration of UNIX-based computers defined for the Windows–based computer or domain. The settings determine what the Event Log displays, the maximum number of times to resend the failed password update, and the time the service waits before resending a password update that has failed.

  • Add or remove a UNIX-based computer from the list of computers designated to receive password updates.

  • Create or modify the configuration for the UNIX-based computer, including the custom settings (the default settings applied to that single computer) and the encryption settings for secure communication. The order in which the names of the UNIX hosts appear in the list determines their order in the registry and the order in which they are processed for password synchronization.


Password encryption

Password encryption

A Windows-based computer can send and receive updated passwords to and from a UNIX-based computer as encrypted text only. The Password Synchronization single sign-on daemon (SSOD) receives the encrypted password and decrypts it before requesting the password change on the UNIX host. Similarly, if Password Synchronization is configured to support UNIX-to-Windows synchronization, the pluggable authentication module (PAM) encrypts the password before sending it to Password Synchronization on the Windows-based computer, which then decrypts the password before requesting the password change on the Windows-based computer.

The password can be successfully decrypted only if Password Synchronization and the SSOD or PAM module use the same encryption key to encrypt and decrypt the password. Before installing the SSOD on any UNIX computer, you must first set the default encryption key. You must then specify the same key in the sso.conf file when you install the SSOD on each UNIX host. This will ensure that Password Synchronization and the SSOD on the UNIX hosts will use the same encryption key. For more information about setting the default encryption key, see Set the default encryption key. For information about installing and configuring the SSOD, see Install the Password Synchronization daemon.

For added security, you can specify an encryption key that is used only between a particular Windows-based computer and a UNIX host. For information about configuring Password Synchronization to use a computer-specific encryption key, see Set computer-specific synchronization properties. For information about setting the computer-specific encryption key on the UNIX computer, see Install the Password Synchronization daemon.


Encryption key requirements

Encryption key requirements

The encryption key must meet the following requirements:

  • It must be 16 to 21 characters long (21 is recommended).

  • It must contain characters from at least three of the following four groups:

    • Uppercase English letters (A–Z)

    • Lowercase English letters (a–z)

    • Westernized Arabic numerals (0–9)

    • Punctuation symbols ` ~ ! @ # $ % ^ & * _ – + = | \ { } [ ] : ; \ " ' < > . ?

  • It must not contain a left or right parentheses (that is a "(" or ")" character), a comma (,), or a blank space ( ).


Controlling password synchronization for user accounts

Controlling password synchronization for user accounts

You can control which users' passwords are synchronized by creating two local user groups: PasswordPropAllow and PasswordPropDeny. (Use the Windows User Manager to create these groups.)

In the PasswordPropAllow group, add the user names for which passwords should be synchronized. In the PasswordPropDeny group, add the user names for which passwords should not be synchronized.

Passwords are synchronized for users who are in PasswordPropAllow and are not in PasswordPropDeny.

If PasswordPropAllow does not exist, the effect is the same as if it did exist with all user names in it. If PasswordPropDeny does not exist, the effect is the same as if it did exist with no user names in it.

These rules apply to synchronization from Windows to UNIX and from UNIX to Windows. If a user's password cannot be synchronized from Windows to UNIX, it cannot be synchronized from UNIX to Windows.

The UNIX administrator can ensure that the passwords for certain users are never synchronized, even if synchronization is allowed by the Password Synchronization server. To ensure that a UNIX user account will never have its password synchronized with the Windows password, edit the sso.conf file to place the user name of the account, preceded by a minus sign (–), after SYNC_USERS=. For example, to ensure that the password of the root account is never synchronized with a Windows account by that name, make sure that the following line appears in sso.conf:

SYNC_USERS=–root


Using sso.conf to configure Password Synchronization on the UNIX computer

Using sso.conf to configure Password Synchronization on the UNIX computer

To change settings and customize how Password Synchronization works on a UNIX-based computer, you change settings in the sso.conf file. For information about installing the sso.conf file, see Install the Password Synchronization daemon.

The following table describes the values you can set in the sso.conf file.

Value Description

CASE_IGNORE_NAME

Specifies whether Password Synchronization will ignore differences in uppercase and lowercase letters in user names when it compares Windows and UNIX user names. To allow case-insensitive comparisons, set this entry to 1 (the default). To force Password Synchronization to use case-sensitive comparisons, set this entry to 0.

ENCRYPT_KEY

Specifies the default key used to encrypt passwords exchanged with Windows servers. You can use settings in the SYNC_HOSTS value to specify a different encryption key for a specific Windows server. For information about valid encryption keys, see Encryption key requirements.

FILE_PATH

Specifies the full path and name of the passwd or shadow file (such as /etc/passwd). This file must contain the encrypted passwords for users, and the type of file (passwd or shadow) must be the same as specified by USE_SHADOW. On AIX systems, the path and name of the shadow file is /etc/security/passwd.

IGNORE_PROPAGATION_ERRORS

When set to 1, specifies that the Password Synchronization PAM module is to ignore any error that occurs when a Windows password is being changed and to continue synchronization with other hosts specified in SYNC_HOSTS.

NIS_UPDATE_PATH

Specifies the full path to the NIS makefile. This value is ignored unless USE_NIS is set to 1.

PORT_NUMBER

Specifies the default number of the port on which the Password Synchronization daemon will listen for password changes from Windows servers. You can use settings in the SYNC_HOSTS value to specify a different port number for a specific Windows server.

SYNC_DELAY

Specifies the number of seconds the Password Synchronization PAM module will wait between synchronization attempts.

SYNC_HOSTS

Specifies the Windows servers or domain controllers with which passwords are to be synchronized. In addition, you can specify a port number or encryption key (or both) for a specific server. Enclose each entry in parentheses and separate items with a blank space. You can have multiple entries on separate lines, each of which cannot exceed 269 characters. The total list of servers or domain controllers is generated by concatenating all entries. For example:

SYNC_HOSTS=(Marketing)
SYNC_HOSTS=(Sales,ASDFhjkl4321ZyXw) (Accounting,6678)
SYNC_HOSTS=(Shipping,6678,ASDFhjkl4321ZyXw)

synchronizes passwords with the Marketing server using the default port and encryption key, with the Sales server using ASDFhjkl4321ZyXw as the encryption key, with the Accounting server using 6678 as the port number, and with the Shipping server using 6678 as the port number and ASDFhjkl4321ZyXw as the encryption key.

If you use server-specific port number or encryption key settings, you must use the same values to configure Password Synchronization on the Windows server, or the passwords will not be synchronized. For information about configuring Password Synchronization on the Windows server, see Configure Password Synchronization.

SYNC_RETRIES

Specifies the number of times that the Password Synchronization PAM module will attempt to synchronize a password change with a Windows server or domain controller.

SYNC_USERS

Specifies UNIX users whose passwords are to be synchronized. You can specify ALL to synchronize passwords for all users or NONE to disable password synchronization for users. You can also specify particular users. If you specify one or more users preceded by plus signs (+), only those users will have their passwords synchronized. If you specify one or more users preceded by minus signs (–), all users except the specified users will have their passwords synchronized. For example, to allow only users bobg and kimr to synchronize their passwords, specify:

SYNC_USERS=+bobg +kimr

To prevent only root and bobg from having their passwords synchronized, specify:

SYNC_USERS=–root –bobg

The minus sign always takes precedence, regardless of the order in which entries appear. For example, the following specifies that the password for user chrisa will not be synchronized:

SYNC_USERS=+chrisa –chrisa +chrisa

TEMP_FILE_PATH

Specifies the full path of the directory to be used to hold a temporary file while the passwd or shadow file is updated. This should be the same directory in which the passwd or shadow file is located. For security reasons, only the administrator should have access to this directory.

USE_NIS

Set to 0 if Password Synchronization is not synchronizing with an Network Information Service (NIS) domain; set to 1 if Password Synchronization is synchronizing with an NIS domain. If USE_NIS is set to 1, specify a valid path for NIS_UPDATE_PATH.

USE_SHADOW

Set to 0 if the passwd file is to be used for synchronization; set to 1 if the shadow file is to be used.


Troubleshooting Password Synchronization

Troubleshooting

What trouble are you having?

  • User cannot log on to UNIX system after changing Windows password

  • Passwords fail to synchronize in a Windows domain, seemingly at random

  • User's password is changed on some, but not all, computers

  • Error ID 4104 is recorded in the event log for a system account, which usually has a name ending with a dollar sign ($)

  • I cannot stop the single sign-on daemon (SSOD) using kill -TERM on Linux

User cannot log on to UNIX system after changing Windows password

Cause: Windows does not report a problem if an attempt to synchronize a UNIX password with a new Windows password fails.

Solution: Check the Windows event log to determine why the attempt to change the password on the UNIX system failed.

Passwords fail to synchronize in a Windows domain, seemingly at random

Cause: Password Synchronization is not configured identically on all domain controllers in the domain. As a result, if a nonconforming domain controller accepts a user's password change, it might not be able to change the password on UNIX computers.

Solution: Ensure that Password Synchronization is configured identically on all domain controllers, particularly host settings and default settings for encryption keys and ports.

User's password is changed on some, but not all, computers

Cause: Password policies are more restrictive on some computers, user names do not match between Windows and UNIX computers, or the user changed the password on a UNIX computer when two-way synchronization is not set up.

Solution: Ensure that password policies on Windows and UNIX computers that synchronize passwords are similar. Otherwise, if the user changes the password on the less restrictive computer, the more restrictive system might not accept the new password. Password policies that govern minimum and maximum length, character case and alphanumeric mix, expiration, and reuse must be as close as possible between Windows and UNIX computers that synchronize passwords. Also, Windows and UNIX system administrators must ensure that that user names, including case, are identical on the Windows and UNIX computers.

Error ID 4104 is recorded in the event log for a system account, which usually has a name ending with a dollar sign ($)

Cause: This error does not indicate a problem. It is logged when a backup domain controller or domain member server resets its secure channel with the domain. When this happens, the server password is also reset. Password Synchronization intercepts these password change requests; because they are for computer accounts rather than for user or group accounts, Password Synchronization logs error number 4104.

Solution: No corrective measures are necessary.

I cannot stop the single sign-on daemon (SSOD) using kill -TERM on Linux

Cause: This is a known limitation.

Solution: Use kill 9 SSOD_PID instead.


Command-line utility

Command-line Utility

The following command-line utility is available to administer Password Synchronization:

psadmin


psadmin

psadmin

NAME

psadmin - Windows command-line utility to manage Password Synchronization

SYNOPSIS

psadmin [computername] [common_option] [add | delete | list]
psadmin [computername] [common_option] config [config_option]

DESCRIPTION

The psadmin Windows command-line utility manages the Password Synchronization component of Identity Management for UNIX, either on a specified computer, or globally. The specific action that psadmin performs depends on the command argument you specify.

In addition to specific command arguments, psadmin accepts the following common options and arguments, represented by common_option in the command synopsis:

Term | Definition
-u username | The account name of the user whose password synchronization behavior you want to modify or view.
-p password | The password for the user account whose password synchronization behavior you want to modify or view.
-? | Displays usage information for the command.

The following configuration options are accepted by psadmin:

Term Definition

-comp name

Computer to which configuration options are applied. If -comp is unspecified, Password Synchronization modifies the default configuration settings. If -comp is the only option specified, then Password Synchronization configuration of the specified computer is displayed.

-enable direction

Specifies the direction of password synchronization. The variable direction can contain one of the following values:

WintoUnix: Synchronize password changes from computers that run Windows operating systems to computers that run UNIX operating systems.

UnixToWin: Synchronize password changes from computers that run UNIX operating systems to computers that run Windows operating systems.

BothDir: Enable two-way password synchronization.

-key keyvalue

Sets the encryption and decryption key for the computer specified by -comp. If keyvalue is random, Password Synchronization uses a random encryption key.

-port number

Sets the port number for the specified computer.

-retry number

Specifies the number of retries allowed. Because this option is a global setting, it can be used only when -comp is not used.

-interval secs

Specifies the elapsed time period, in seconds, between retries. Because this option is a global setting, it can be used only when -comp is not used.

-log [yes | no]

Enables or disables logging. Because this option is a global setting, it can be used only when -comp is not used.

-?

Displays psadmin usage and arguments.

The following command arguments are accepted by psadmin:

Term | Definition
add computername | Adds the specified computer to the list of computers participating in password synchronization.
delete computername | Deletes the specified computer from the list of computers participating in password synchronization.
list | Displays the list of computers participating in Password Synchronization.

See Also

  • Configure Password Synchronization


Accessibility Features of Identity Management for UNIX

Products in the Windows Server 2003 family include a number of accessibility features that can improve display, sound, mouse, and keyboard settings for users who are blind, have motion disabilities, or are deaf or hard of hearing. Many accessibility features are also useful to people without disabilities.

Accessibility Features and Options

Because Identity Management for UNIX tasks can be completed using either a Windows-based interface or shell commands, accessibility options are available for both computing environments.

Accessibility Features and Options for Windows-based Tools in Identity Management for UNIX

For more information about accessibility features and options, see Accessibility for People with Disabilities on the Microsoft Windows Server 2003 TechCenter.

Because the Windows-based management tool for Identity Management for UNIX is a Microsoft Management Console (MMC) 3.0 snap-in, Identity Management for UNIX shares applicable MMC 3.0 accessibility features. For more information about accessibility in MMC, see Accessibility for MMC.

Accessibility Features and Options for the Command-line Environment

For information about keyboard shortcuts that can provide greater accessibility to users of command-line and UNIX-based shell computing environments, refer to the Help and release notes provided with the Utilities and Software Development Kit (SDK) for UNIX-based Applications installation package, available for download from the Microsoft Web site.