Migrating and Managing Standard and Nonstandard Maps

Migration is handled in one of two ways, depending on whether the map being migrated has an equivalent in Active Directory Domain Services (AD DS). For standard maps such as passwd, group, and hosts, that have an equivalent AD DS 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 AD DS, 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 nonstandard 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 AD DS, 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.

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, provide the user with the temporary password, and then instruct the user to change the Windows password as soon as possible. When the user changes the Windows password, the new password is propagated to UNIX-based NIS clients the next time 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 AD DS is set to the existing UNIX password, and the Windows password remains unchanged.

Whenever a user's Windows password is changed, the password in the NIS passwd map stored in AD DS 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 is changed; the Windows password does not change. As a result, UNIX and Windows passwords differ.

	Note
	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” in the Identity Management for UNIX Help.

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

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 as the key field. Verify that the key is not part of the value.

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 not part of the value..

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 AD DS, 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.

AD DS 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 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.

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.

Data for group maps for Server for NIS are managed by using 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.

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 by using this snap-in.

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