Article

(View Disclaimer)

Introduction
Preparing the LDAP Server
Building the Base LDAP Structure
Exporting Active Directory Data and Importing it into the LDAP Server
Securing LDAP for Import into eDirectory
Importing LDAP Data into eDirectory
Example Scripts and .conf Files
Conclusion

Introduction

If you Google "Active Directory Migrate eDirectory" you'll find many links on how to migrate eDirectory to Active Directory, but next to nothing going the other way! Although I'm a big fan of Identity Manager, I looked into how I could migrate my AD accounts to eDirectory. OpenLDAP is the key, and this AppNote explains how you do it.

We'll going to need a couple of additional applications to accomplish this:

• Berkley db-4.3.29-15.2
• openldap2-2.3.19-18.7 - Server
• pwdump2 - http://www.doubleupsoftware.com/files/pwdump2.zip
• ActivePerl - http://downloads.activestate.com/ActivePerl/Window...

Preparing the LDAP Server

First, you need to configure slapd to get ready for the AD dump.

1. Edit /etc/openldap/slapd.conf

2. Find the following line:

include /etc/openldap/schema/core.schema

3. Add this after:

include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema

4. Go to the line that starts with "suffix" and change to your AD structure:

suffix "dc=[basedn],dc=com"

5. Change the line that starts "rootdn" to your AD structure:

rootdn "cn=Manager,dc=[basedn],dc=com"

6. Save the file and exit.

7. Start slapd.

Building the Base LDAP Structure

1. Place the following into a file called base.ldif, and modify to your organization's needs.

dn: dc=[basedn],dc=com
objectclass: dcObject
objectclass: organization
o: [Your  Company]
dc: basedn
NOTE: The above line value for ?basedn? should match the first line's value for ?basedn?.
dn: cn=Manager,dc=[basedn],dc=com
objectclass: organizationalRole
cn: Manager

2. Import the file into LDAP.

ldapadd -x -D "cn=Manager,dc=[basedn],dc=com" -W -f base.ldif

Exporting Active Directory Data and Importing it into the LDAP Server

1. On a Windows domain controller, login as administrator.

2. Copy the Perl script samdump.pl and pwdump2 files to a temp directory.

3. Open a cmd window and change to the c:/temp directory.

4. Enter the following commands to extract the AD Users:

c:\temp\pwdump2.exe > passwd.txt
samdump.pl ?b dc=[basedn],dc=com passwd.txt users.ldif

You should now have a file (users.ldif) with all of your users in it.

5. Copy this file to your SLES server in the /root/ directory (for security).

6. Go back to your SLES server and import the AD users into the LDAP directory by entering the following command:

ldapadd -x -D "cn=Manager,dc=[basedn],dc=com" -W -f /root/users.ldif

At this point, all of your AD users, including their password hash, are in LDAP. Now you need to secure LDAP for eDirectory communication.

Securing LDAP for Import into eDirectory

1. Secure LDAP by encrypting your "rootpw" in your slapd.conf. We'll use "slappasswd" to do this.

slappasswd -s yourpassword

Here's the output:

{SSHA}i+RR9IAmrGDC0+RogacHrKNqUHVP1w7p

2. Copy that line and insert it into your slapd.conf (see the example).

3. Restart slapd.

If you do not have a CA, OES Linux creates one by default; or, you can create one as shown below.

4. Change directories to where you want to maintain these certificates - e.g., /etc/apache2/ssl.crt/

5. Create the certificates. We'll use the commands below:

openssl genrsa -des3 -out ca.key 1024
openssl req -new -x509 -days 999 -key ca.key -out ca.crt
openssl genrsa -des3 -out serverldap.key 1024
openssl req -new -key serverldap.key -out serverldap.csr 

6. Move the certificates into their own directory:

mkdir -p ldapca/private
cp ca.key ldapca/private/cakey.pem
cp ca.crt ldapca/cacert.pem
mkdir ldapca/newcerts
touch ldapca/index.txt
echo "01" > ldapca/serial 
openssl ca -policy policy_anything -in serverldap.csr -out / server.cert

7. To allow TLS-enabled connections add the following lines to /etc/openldap/slapd.conf, making sure to use the path to your new certificates:

TLSCertificateFile /path_to_your_certificates/serverldap.crt
TLSCertificateKeyFile /path_to_your_certificates/serverldap.key
TLS_REQCERT allow
Restart slapd

8. Add the following lines to /etc/openldap/ldap.conf ...

URI ldap://127.0.0.1
TLS_CACERT /path_to_your_certificates/serverldap.cert
TLS_KEY /path_to_your_certificates/serverldap.key
TLS_REQCERT allow

Importing LDAP data into eDirectory

1. Log in to iManager.

Click to view.

Figure 1 - iManager login

2. Expand eDirectory Maintenance and select the Import Convert Export Wizard.

Click to view.

Figure 2 - Running the ICE wizard

3. Select Migrate Data Between Servers.

4. Check "Run in Verbose Mode" and "Log Failed Records" (nothing's perfect ...)

5. Click Next.

6. Enter the IP/DNS name of the LDAP server and specify the secure LDAP port (636).

Click to view.

Figure 3 - Server data for ICE

7. Check Authenticated login and enter root and the password you set up earlier.

8. Click Next.

9. Specify the Base DN to search in the source tree and the extent of depth you want the search to go.

Click to view.

Figure 4 - Specifying the Base DN

10. Click Next.

11. Enter the IP/DNS name of the destination tree (eDirectory) and secure LDAP port of that server.

12. Check Authenticated Login and specify the FDN admin equivalent account and password.

Click to view.

Figure 5 - Destination tree data

13. Click Next.

14. Specify the container you want the objects placed.

15. Click Start to begin.

Verifying that Users were Imported

1. At the top of the iManager screen, next to Roles and Tasks, click View Objects and browse to the container you imported your users.

2. Click one of those users and select Modify Object.

Click to view.

Figure 6 - Modifying the user object

There it is - just like we had it in Active Directory.

Click to view.

Figure 7 - Modify Object screen

Note that this method does not migrate ACL's or user groups.

Example Scripts and .conf Files

Below are the scripts and example conf files you need.

# Start of /etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
TLSCertificateFile /path/to/server.cert
TLSCertificateKeyFile /path/to/server.key
TLS_REQCERT allow
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

database mydb
suffix "dc=myorg,dc=com"
rootdn "cn=Manager,dc=myorg,dc=com"
rootpw {SSHA}i+RR9IAmrGDC0+RogacHrKNqUHVP1w7p
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/share/openldap/ldapdata
# Indices to maintain
index objectClass eq
use strict;
use Getopt::Std;
use vars qw/ $opt_u $opt_g $opt_d $opt_s $opt_b $gidNumber $homeDirectoryBase $loginShell $basedn/;
# End of /etc/openldap/slapd.conf

samdump.pl

#!/usr/bin/perl
#samdump.pl

if (!getopts('uig:d:s:b:'))
{
	print "samdump: converts Win SAM dump to ldif\n";
	print "usage: [-b 	basedn] pwdump-file\n";
	 
	exit;
}
	$gidNumber = 100;
	$homeDirectoryBase = "/home/";
	$loginShell = "/bin/bash";

if ( $opt_b ) {
	$basedn = $opt_b;
} else {
	$basedn = "dc=Users,dc=net";
}

while ( <> ) {
	my ($name, $uidNumber, $lanmgr_hash, $nt_hash, $account_flags, 	$lchange_time, $remainder) = split /:/, $_;
	next if $name =~ /\$$/; 
	print "dn: uid=$name,$basedn\n";
	print "objectclass: top\n"; 
	print "objectclass: account\n"; 
	print "objectclass: posixAccount\n"; 
	#posixAccount MUST
	print "cn: $name\n";
	print "uid: $name\n";
	print "uidNumber: $uidNumber\n";
	print "gidNumber: $gidNumber\n";
	#print "homeDirectory: $homeDirectoryBase$name\n";
	#posixAccount MAY
	print "userPassword: {lanman}$lanmgr_hash\n";
	#print "loginShell: $loginShell\n";
	print "\n";
}
# End of samdump.pl

Conclusion

It can be done. Not that I would recommend this procedure when there are much simpler and less painful methods, like Identity Manager, or when OES2 is released, Domain Services for Windows.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.