Appendix F: Migrating Digital Identity Information to Active Directory

Article
12/05/2007

Note: This appendix assumes that rationalization of users and groups has already been accomplished.

The method you use for migrating your digital identity information will depend primarily on the initial state of your environment. Below are possible examples that may depict your environment:

Users have accounts in both the UNIX and the Microsoft® Windows® environments. The user account names are the same in both environments.
Users have accounts in both the UNIX and the Windows environments. The user account names are different in the separate environments.
Users have accounts in only the Windows or UNIX environments or only a small number of users have accounts in both environments.
In addition to any of the above, UNIX users may have multiple accounts in the UNIX environment in order to access different resources.

The main ways to migrate the user information are:

Manually migrate the user account data.
Migrate user account data with scripts.
Use a migration tool.
Use another method such as a pluggable authentication module (PAM) to assist with migration.

Regardless of the method by which users are migrated, you may want to determine if you want to set the “User must change password at next logon” flag for new user accounts and if you want the accounts to be enabled. Keep in mind that you might not be able to migrate the password for the user and may need to give him or her a new password.

Note The information in this appendix is primarily for the custom solutions included in this guide. For information about how the commercial solutions in Volume 2 of this guide handle migrating digital identify information to Active Directory, see:

"Managing Digital Identities" in Volume 2: Chapter 2, "Using Quest Software VAS to Develop, Stabilize, Deploy, Operate, and Evolve End State 2."
"How DirectControl Imports Existing UNIX Accounts into Active Directory" and "Importing Existing UNIX Accounts into Active Directory" in Volume 2: Chapter 3, "Using Centrify DirectControl Develop, Stabilize, Deploy, Operate, and Evolve End State 2."

Manually Migrating User Account Data

Users can be migrated manually from UNIX and Linux to the Active Directory® directory service using the Active Directory Users and Computers MMC snap-in. If Active Directory holds authorization data as well, then the UNIX Attributes tab created by Windows Services for UNIX can be used to add their UNIX attributes. However, with large numbers of users, this becomes impractical.

Migrating User Account Data with Scripts

There are three steps involved in migrating the user information: extracting, massaging, and importing the data.

UNIX users who will use Active Directory only for authentication data need no special attributes in Active Directory. They can be migrated in the same way that standard Windows users are migrated. A script can be used to pull a list of user names from local UNIX passwd files, a Network Information Service (NIS) database, or other authentication database. Authentication data from most sources will be the same in terms of the data that needs to be extracted. In most cases, it will not be possible to extract the existing password from the data store. If that is the case, all that is needed is a list of user names from the old data store and then knowledge of the standard attributes that are set for Windows users. If there are no existing scripts for importation of Windows users, such scripts must be created. An import file containing the list of user names from UNIX and whatever attributes must be set for a standard Windows user must be created. A tool such as ldifde can be used to import the data.

In order to use Active Directory for authorization of UNIX users, additional attributes about the users must be extracted from the existing databases for migration into Active Directory. These attributes include: UID, GID, home directory, shell, and group membership.

Extracting Data

The method of extraction depends on the current location of your authentication and authorization data.

In general, there is no way to move the password hash from the existing authentication store to Active Directory. It may be possible to extract the hash of the password, but it normally isn’t possible to import it into Active Directory. If you can extract the actual password from the current authentication store, then that can be used to create an account in Active Directory with that password.

Extracting Data from Local Files

This is just a matter of collecting the local files from the computers. The files will have one line per user (/etc/passwd) and one line per group (/etc/group). They will contain standard UNIX users and groups that should not be imported into Active Directory.

Extracting Data from NIS

The easiest method to extract data from NIS is to use the getent command and specify the command-line option passwd or group:

# getent passwd
# getent group

These commands output data in a format similar to that of the local files that can then be handled for massaging and importing just as you would for local file data. Be aware that these commands will output the list of users and groups from the NIS database along with the user and group information from the local files on the computer on which the command is run.

Extracting Data from an Existing Kerberos Server

Most Key Distribution Center (KDC) implementations include a tool to dump the principal data from the database to a file. The standard MIT implementation, upon which several native implementations are based, includes the kdb5_util utility for this purpose. This tool, when used with the "dump" option, creates a text output file containing all principals and all information about these principals. The file is not of an appropriate structure to be imported into Active Directory as is. The "dump" option in kdb5_util contains a -verbose switch that outputs the name of each principal to the screen while writing the data about the principals to a file. If you want only a list of principal names for migration into Active Directory, you can capture this screen output to a second file. The following command will do this using the /bin/bash shell (commands vary by shell):

# kdb5_util dump -verbose /tmp/dumpfile > /tmp/dumpnames 2>&1

UNIX KDCs do not store authorization data. If you want to migrate the authorization data from your UNIX environment to Active Directory, you must also extract data from your authorization data store for migration.

Extracting Data from an Existing LDAP Data Store

Tools associated with LDAP data store implementations vary, but each implementation should offer an option to dump the authentication and/or authorization data to a file.

Massaging Data

You may need to modify, or “massage,” the data extracted from your authentication and authorization systems. For example, you may want to:

Remove root, UNIX service accounts, and any other users or groups you don’t want migrated.
Reformat the collected data into the form that your import tool can use.
Confirm that rationalization has been successfully completed and that there are no duplicate UIDs and GIDs.

Importing Data

Migrating large numbers of UNIX and Linux users to Active Directory is best achieved using scripts. It is possible to write your own scripts using:

A Windows script that uses ldp.exe.
A Windows script that uses ADSI procedures.
A UNIX or Linux script that uses the LDAP client tools.
A Perl script that uses the CPAN LDAP Perl module (Net::LDAP) on any platform.
A Perl script that uses the CPAN ADSI Perl module for Microsoft Win32® platforms.

Other tools, including ldifde, exist that can be used to import data from a flat file.

PADL provides a set of Perl scripts for LDAP data migration that can also be helpful. See the following “PADL Migration Tools” section.

Using Migration Tools

Packaged migration tools are available for some commercial solutions. In addition, PADL provides an open source migration tool in the form of Perl scripts. Migration tool options include:

Windows Services for UNIX 3.5
PADL LDAP migration tools

Windows Services for UNIX 3.5

Microsoft Windows Services for UNIX 3.5 includes a tool to import NIS data. It supports importation of many types of NIS data including passwd (users) and group data. The import file used by this tool is a plain text file containing data in the structure used for UNIX passwd and group files. If your data is stored in another form, you must massage it to generate an input file of the correct form. See the above “Extracting Data” and “Massaging Data” sections.

The import process will reject duplicate records, so you must complete rationalization before importing. The tool provides a feature to make a review of the import data for errors and duplicates prior to importing the data.

When importation is complete, the user accounts will exist in the cn=users,cn=domain container in the container you specified during the importation (for example, cn=users,cn=example,ou=unix,dc=example,dc=com). These users are hidden in Active Directory Users and Computers and can be viewed there only when the Advanced option is set. The user accounts are initially disabled. Before these users can log on UNIX, the user passwords must be set to a known value and the accounts enabled. Users imported in this way have a sufficient number of attributes populated in Active Directory to allow for UNIX login. However, you may wish to supplement this tool with a process or tool to populate standard Active Directory user fields.

Warning: The current implementation of the Windows Services for UNIX NIS migration tool does not populate the correct attributes in Active Directory to allow UNIX users to retrieve group information on login. The correct fields must be populated manually or with a script after importation completes.

The script to put data in the correct group field can be implemented in one of two ways:

Read the group information from the extracted information from the NIS server and populate the correct group field.
Read the group information from the field that the Windows Services for UNIX field populates and copy or move it to the correct field.

For example, scripts using Windows Services for UNIX, see the following article: “Creating Windows Users from an NIS Database Using Microsoft Windows Services for UNIX v3.5,” available at
https://www.microsoft.com/technet/interopmigration/unix/sfu/crwunix.mspx.,

PADL Migration Tools

PADL has provided a set of Perl scripts for migrating UNIX and Linux user accounts to an LDAP database. These scripts can be obtained from the PADL Web site at https://www.padl.com. The scripts are designed to be used with an LDAP directory containing the schema from RFC 2307, “An Approach for Using LDAP as a Network Information Service.” To use these scripts with an Active Directory schema that has been extended using the Windows Services for UNIX 3.5 schema, you must modify the scripts by changing the RFC 2307 attributes and object classes to the relevant attributes and object classes in Windows Services for UNIX 3.5.

In addition to migrating user account information, the PADL LDAP migration tools can also migrate other UNIX and Linux information, including the information stored in the following configuration files: aliases, hosts, fstab, networks, services, protocols, rpc, and netgroup. These files are a subset of the files supported by the Windows Services for UNIX schemas. As with the user account information, the attributes and object classes used by the PADL migration scripts are RFC 2307-compliant. If you want to use these scripts, you must modify them to use the attributes and object classes from the Windows Services for UNIX 3.5 schema.

To use the PADL scripts, you must have Perl installed. You must also have installed and configured the UNIX and Linux LDAP libraries and tools.

Using PAM for Migration

One method of performing a migration is to put a special migration pluggable authentication module (PAM) in place. The concept behind PAM is that when a user logs in, a PAM module being called has access to the user password. This PAM module can then check if the user already exists in Active Directory and, if not, add the user using his or her current password.

PAM can also be extended to read the user’s UNIX attributes and populate Active Directory with them if needed.

This method is transparent to users and allows them to be added to Active Directory using their current passwords.

An example of a patch to a pam_ldap module is described in the following article, “PAM_LDAP module patch,” which is available at
https://www.iem.pw.edu.pl/~wielebap/ldap/pam_ldap/pam_ldap_doc.pdf.