Article

(View Disclaimer)

Back in June of 2007, I wrote a migration guide for NetWare to OES1. While there are similarities between the OES1 and OES2, there are also major differences. For the sake of a complete HowTo on migration, I have included those similarities here so the reader does not have to jump between multiple documents. What is not covered in this article are the enhancements you can apply, such as AutoYaST, to increase the efficiency of your own migration experience.

Please make modifications to the data, where noted, to reflect your own organization's structure.

Other resources

Novell Open Enterprise Server 2 Migration Best Practices Guide
http://www.novell.com/communities/node/2758/novell-open-enterprise-server-2-best-practices-migration-guide

Overview

The services to be migrated include:

• Data – User and other shared
• DNS/DHCP
• ZENWorks – Applications and policies
• Backup – RSYNC
• After the migration is completed and tested, decommission of existing NetWare servers

The steps to perform the migration are listed here:

1. Preparing your current environment.
2. Installation of OES Linux to a new server following specific instructions to ensure proper NSS volume creation under EVMS management.
3. Securing the new OES Linux server.
4. LDAP authentication for local user access.
5. Data migration.
6. DNS/DHCP migration.
7. ZENWorks Desktop Management v7 SP1 - Optional.
8. RSYNC modification - Optional.
9. NetWare Server Decommission.
10. Workstations.

1. Preparing your Environment

OES2 installs eDirectory 8.8.2 and can affect other applications in your environment. To see a list of which Novell applications are compatible with eDirectory 8.8 and which are not, look here.

If you have a version of ZENWorks prior to 7 SP1, I would suggest upgrading to this version prior to introducing eDirectory 8.8 into your tree. eDirectory 8.8 does not replicate attributes of prior versions of ZENWorks.

OES2 migration will migrate versions of NetWare from 5.1 and later. For purposes of this article, we will be migrating NetWare 6.5 SP6.

2. OES2 Linux Installation and Configuration

With the release of SuSE Linux Enterprise Server 10 SP1 and OES2, Novell has separated the two products and OES2 Linux is a separate CD. This means that when you do your OES2 installation, you will add this CD to the installation of SLES 10 SP1. OES2 can be installed either during the SLES 10 SP1 installation or added to the server at a later time.

This portion does NOT walk all the way through an OES Installation. It is intended to specify critical changes that must be made to the default installation of OES Linux to ensure the migration is transparent to the user.

Adding OES2 to the Installation

When you begin your new installation, you choose your language and you will be presented with the following screen. Click New Installation and click “Include Add-On Products from Separate Media.” Choose CD on the next screen and YaST will prompt you for your OES2 CD.

Click to view.

Partitioning

1. When the installation reaches the Installations Settings screen, delete the recommended partitions and the partition table on the system disk so that the device can be marked to use EVMS as the volume manager instead of LVM.
1. In the list of Installation Settings, select Partitioning.
2. In the Partitioning menu, select Create Custom Partition Setup, then click Next.
3. Select Custom Partition - for Experts, then click Next to open the Expert Partitioner options.
4. Select Expert > Delete Partition Table and Disk Label, then click Yes twice to continue through the Warning advisories.
   This deletes the recommended partitions and the partition table on the system disk.
2. Create a primary partition on the system disk to use as the boot partition.
1. Click Create.
2. From the list of devices, select the device you want to use for the boot partition, ex: /dev/sda, then click OK.
3. Select Primary Partition, then click OK.
4. Select Format, then select the native Linux file system you want to use, such as Ext3.
5. In Size (End Value) field, specify 300 MB.
6. Set the mount point to /boot.
7. Click OK.
   The partition appears as a logical device in the devices list, ex: /dev/sda1.
3. Create a second primary partition on the system disk to use for your swap and system volumes as follows:
1. Click Create.
2. From the list of devices, select the device you want to use for the second primary partition, ex: /dev/sda, then click OK.
3. Select Primary Partition, then click OK.
4. Select Do Not Format, then select Linux LVM (0x8E) from the list of file system IDs.
5. In Size (End Value field), set the cylinder End value to the size of your disk minus what you want to use for swap., ex: 12GB
4. Leave unpartitioned space available.
5. Click OK.
   The partition appears as a logical device in the devices list, ex: /dev/sda2.
6. Modify the volume management type from LVM to EVMS for the second primary partition you created in Step 3 as follows:
1. At the bottom of the page, click EVMS.
   Available partitions for EVMS appear as devices under /dev/evms, such as /dev/evms/sda2.
2. In the EVMS Configurator, select the LVM partition created in Step 3, then click Create Container.
3. In the Create EVMS Container dialog box, select the partition, specify the container name (such as system), then click Add Volume to create the lvm/system container, where system is the container name.
4. Click OK.
   The EVMS Configurator displays the lvm/system container you just created, its size, and free space.
7. Create the swap volume in the lvm/system container as follows:
1. Select lvm/system, then click Add.
2. In the Create Logical Volume dialog box, select Format, then select Swap from the File System drop-down menu.
3. Specify swap as the volume name.
4. Specify the size of the swap volume as 2 GB.
5. Specify the mount point as swap.
6. Click OK.
8. Create the system volume in the lvm/system container as follows:
1. Select lvm/system, then click Add.
2. In the Create Logical Volume dialog box, select Format, then select the file system to use from the File System drop-down menu, such as Ext3.
3. In the Volume Name field, specify a volume name, such as sys.
4. Specify the Size of the system volume as the remaining space available in the lvm/system partition by clicking Max.
5. Specify the mount point as / (root volume).
6. Click OK.
9. Click Next to return to the list of devices.

Below is an example of the physical and logical devices you should see.

Device	Size	F	Type	Mount	Start	End	Used By
/dev/sda	149 GB		ST34001A		0	19456
/dev/sda1	300 MB	F	Linux native	/boot	0	38
/dev/sda2	20.0 GB		Linux LVM		39	2649	EVMSlvm/system
/dev/evms/lvm/system/sysx	14.9 GB	F	EVMS	/	-	-
/dev/evms/lvm /system/swap	2.0 GB	F	EVMS	swap	-	-

10. Click Next to return to the Installation Settings page.
11. From the Installations Settings screen, click Software > Details, then select the following software options – These are the basic options I chose for my use. You can modify this depending on your needs.
    

    Basic Runtime System
    YaST
    Graphical Base System
    Linux Tools
    Authentication Server (NIS, LDAP, Kerberos)
    Basic Sound Libraries and Tools
    Gnome System
    Novell eDirectory
    Novell iManager
    Novell Linux User Management
    Novell iPrint
    Novell NetStorage
    Novell NSS
    Novell NCP Server
    Novell Backup Services (SMS)
    Novell Health Monitoring
    
    

    Select Search and in the search field, type Locate and then search. On the right side, “findutils-locate” will appear. Also add DHCP Server and RSYNC, if desired. Click Accept.

12. Scroll down the list and select the TimeZone for this server's location and then click Runlevel. Select Runlevel 3 – No GUI on console.
13. Continue with the OES installation.
    
    IMPORTANT: After the install is complete, make sure to perform the mandatory post-install configuration of the related system settings to ensure that the system device functions properly under EVMS. Otherwise, the system fails to boot properly.

After the Install

After the OES installation is complete, you must perform the following tasks to ensure that the system device functions properly under EVMS:

Disable boot.lvm and boot.md

Disable boot.lvm and boot.md so they do not run at boot time. EVMS now handles the boot.

1. In YaST, click System > Runlevel Editor > Expert Mode.
2. Select boot.lvm.
3. Click Set/Reset > Disable the Service.
4. Select boot.md.
5. Click Set/Reset > Disable the Service.
6. Click Finish, then click Yes.
   Do not reboot the server yet!
   Enable the boot.evms Service
   The boot.evms service should be enabled automatically after the install, but you should verify that it is enabled.
1. In YaST, click System > Runlevel Editor > Expert Mode.
2. Select boot.evms.
3. Click Set/Reset > Enable the Service.
   The B runlevel option is automatically selected.
4. Click Finish, then click Yes.
   Do not reboot the server yet!

Edit the /etc/init.d/boot.evms Script

1. Open the /etc/init.d/boot.evms script in a text editor.
2. Add the following lines to the Stop section:
   

   mount -n -o remount,rw /
   echo -en "\nDeleting devices nodes"
   rm -rf /dev/evms
   mount -n -o remount,ro /
   
   

   The Stop section looks like this after the edit:

   stop)
           echo -n "Stopping EVMS"
           mount -n -o remount,rw /
           echo -en "\nDeleting devices nodes"
           rm -rf /dev/evms
           mount -n -o remount,ro /
           rc_status -v
           ;;
   		
   		

3. Save the file.
   Finally! Reboot the Server
7. Now reboot the server to activate post-install configuration settings.

Verify the System Services

After the post-install configuration is complete and you have rebooted the server, make sure the server is operating as expected.

Create NSS Volume

From the command prompt, type nssmu to start the NSS Management Utility.
Select Pools, press Insert and create a new Pool. Call it VOL or whatever your standard dictates. Designate all the free space to it.

Select Apply and the Escape back to the main menu.

Select Volumes, press Insert and create a new volume. Name it VOL1 (for example) and place it in the pool you created earlier. Designate all the space to this volume and select apply.

Select the volume and press F4 to update eDirectory, otherwise you won't see the new volume in the tree. Press Esc to exit the utility.

3. Securing the New OES Linux Server

These recommendations are optional and should be used as, at least, a guide to securing your server. Refer to your organization's security policies regarding hardening your servers.

GRUB Boot Loader

Password protect the boot loader to prevent editing of the boot environment or passing kernel level commands to the system at boot time. Use the md5crypt command within GRUB to encrypt a password. Then use this hash to edit the menu.lst file and insert the password line as shown below.

Be sure NOT to use the same password as root or any other user password on the system. If you “fat finger” the password without testing it first you will not be able to make changes to the boot process upon boot up!

# grub

  GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word,
 TAB lists possible command completions. Anywhere else TAB lists 
 the possible completions of a device/filename. ]

grub> md5crypt

Password: *******
Encrypted: $1$vUYoM$OAxm9NVNUBsCeP1dl50

grub>quit


vi /boot/grub/menu.lst

color white/blue black/light-gray
default 0
timeout 8

password --md5 $1$vUYoM$OAxm9NVNUBsCeP1dl50
title linux
  kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 vga=795
  
  

BIOS

Password protect changes to the BIOS to prevent changing the boot order of the device. In production booting from CD or floppy should be disabled.

Tuning Network Kernel Parameters

There are a few parameters that can be applied to the kernel through the proc file system to improve protection of the server.

Modify /etc/sysconfig/sysctl to add these options along with the default configuration options.

net.ipv4.ip_forward = 0 -- Disables IP forwarding.
net.ipv4.conf.all.accept_source_route = 0 -- Disables source routing.
net.ipv4.tcp_syncookies = 1 -- TCP syn flood protection parameter.
net.ipv4.tcp_max_syn_backlog = 4096 Additional TCP syn flood protection.
net.ipv4.conf.all.rp_filter = 1 Enables anti-spoofing protection.
net.ipv4.conf.all.send_redirects = 0 Disables the sending of ICMP redirects.
net.ipv4.conf.all.accept_redirects = 0 Disables receipt of ICMP redirects.
net.ipv4.conf.default.accept_redirects = 0 Disables ICMP redirects for newly activated.

Warning Banners

Include this warning message for all direct methods of connection to the server.

/etc/motd Add this banner to this file

/etc/issue Add this banner to this file also. Below is an example that you can use.

Change My Company to your Organization - It's lengthy, but you know the legal guys..

My Company owns this computer system and restricts access and use to authorized persons only. Use of and/or access to this system and/or any information obtained via this system is subject to My Company policies and procedures governing such use and access. Unauthorized or improper use of or access to this system, or any portion of it, either directly or indirectly, or any attempt to deny service to authorized users or to alter, damage, or destroy information, or otherwise to interfere with the system or its operation, is strictly prohibited. Any party using or accessing, or attempting to use or access, this system without express authority from My Company may be subject to severe disciplinary action and/or civil and criminal penalties in accordance with applicable state and federal law (including, but not limited to, the Computer Fraud and Abuse Act of 1986 and the Electronic Communications Privacy Act). My Company representatives may monitor and record use and access for quality assurance, security, privacy compliance, regulatory compliance i.e. HIPAA, Sarbanes Oxley, and performance, except as prohibited by law. Any person who uses or accesses this system expressly consents to such monitoring and recording. My Company or its representatives may furnish information obtained by its monitoring and recording activity to law enforcement officials if such monitoring and recording reveals possible evidence of unlawful activity.

Copy the /etc/issue file to /etc/issue.net

For SSH connections edit the /etc/ssh/sshd_config file. Below is the what needs to be changed to point the banner at the /etc/issue.net file.

# vi /etc/ssh/sshd_config

??.
# no default banner path
Banner /etc/issue.net
#VerifyReverseMapping no

# override default of no subsystems

SSH configuration

In addition to setting a banner as above, it should be restricted to version 2 of the protocol only. SSH version 1 has some inherent weaknesses and so should be avoided. Edit this file and make the changes listed in Bold. Most settings are fairly self explanatory. No hosts should be automatically trusted through the rhosts types of authentication or even with a machine based certificate as with the RSA variants. Root should not be allowed direct access. For administration, you should connect to the machine as a regular user and then SU to root for additional needed rights.

#Port 22
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::
SyslogFacility AUTH
#
#LoginGraceTime 600
PermitRootLogin no
#StrictModes yes
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in 
        /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
PermitEmptyPasswords no

Further Securing Remote Login

In addition to the restrictions made on SSH, we should also further disable remote interactive login for root in case, mistakenly or maliciously, telnet or some other method of tty access was enabled again. Modify the /etc/securetty file. All lines except the TTY1 should be commented out. This is needed for console access. SSH is running its own daemon and is not affected by these settings.

# This file contains the device names of tty lines (one per line,
# without leading /dev/) on which root is allowed to login.
#
tty1
#tty2
#tty3
#tty4
#tty5
#tty6
# for devfs:
#vc/1
#vc/2
#vc/3
#vc/4
#vc/5
#vc/6

Now this file should be protected by executing the following:

chown root:root /etc/securetty 

chmod 400 /etc/securetty 

this makes it so that only root can read the file and nobody can write to it, even root, until root chmod's the file with more permissions again.

Modification to /etc/inittab

/etc/inittab has several settings in it that should be hardened. Disable Ctrl-Alt-Delete from shutting down the server, edit the default run level, protect the server even in Single User mode, and disable extra console login daemons (Ctrl-Alt-Fx) to further protect console access. See the settings made in Bold.

# The default runlevel is defined here
id:3:initdefault:

# First script to be executed, if not booting in emergency (-b) mode
si::bootwait:/etc/init.d/boot
# what to do in single-user mode
ls:S:wait:/etc/init.d/rc S
~~:S:wait:/sbin/sulogin

# what to do when CTRL-ALT-DEL is pressed. Comment to disable.
#ca::ctrlaltdel:/sbin/shutdown -r -t 4 now
The "3" in the id:3:initdefault line designates that the default run level is level 3 which does not load the GUI. The GUI can be loaded as necessary with the "startx" command but should not remain loaded or load by default on the server.

The line beginning with "~~:S" is the command for what to do in single user mode. (i.e. typing "single" as a boot parameter in grub -- which now requires password access anyway). Change the "respawn" command to "wait." This will prompt for the root password before continuing.

The "ca::ctrlaltdel:/sbin/shutdown --r --t4 now" line is the command to execute when Ctrl-Alt-Delete is pressed. This should be commented out as shown to disable this functionality and prevent someone with physical access from shutting down the machine without a valid login.

Xwindows - GUI protections

Although X-windows is not loading by default on the server, this could be changed easily by an administrator and it is available to load manually by changing run levels or typing "startx" at the console prompt. Therefore, implement the following extra safeguards:

Disable XDMCP
Remote machines should not be able to get an X terminal login window. Edit the following lines in /etc/X11/xdm/Xaccess to prepend them with a "!" as shown.

!*   #NO host can get a login window
!*   CHOOSER BROADCAST  #NO indirect host can get a chooser

Disable listening on port 6000

This prevents the X system from listening for X events from remote machines. Local X access at the console is not affected. Edit the config file /etc/X11/xdm/Xservers as shown below adding the "-nolisten tcp" switch to this line.

:0 local /usr/X11R6/bin/X :0 vt07 -nolisten tcp

Restrict cron and at

Cron and at daemons run processes on the system as root so access to them as well as the crontab command and files so that malicious code can't be "scheduled." The binaries are also world executeable and SUID to root so they can be dangerous. Restrict access to them with the following steps.

1. Create cron.allow and at.allow files
   These files will restrict access to cron to only the users listed in the files. All others will be denied. The only user in the list should be root. These files don't exist by default so you can create them with the echo command as follows. Delete any deny files. (/var/spool/cron/deny)

# echo root > /etc/cron.allow
# echo root > /etc/at.allow

2. Modify permissions on cron/at related files
   Since all cron and at files are read and written to by processes that are SUID root, normal users on the system will not ever need to have direct access to the files so they should be secured to prevent tampering.

# chown -R root:root /etc/cron* /var/spool/cron
# chmod -R go-rwx /etc/cron* /var/spool/cron

4. LDAP Authentication Through eDirectory

Managing and maintaining passwd files can be a real beating. To make life easier, especially if you have a number of OES2 Linux servers about, configure local authentication to use LDAP and eDirectory, then simply add designated users/admins, to the LUM group and they'll have local access. Also, root and other predefined local accounts are not affected. Follow the steps below.

1. 1.Type yast at the command line

Select the "Network/Advanced" section and then > LDAP client.
Select "Use LDAP".

Add the LDAP server in the server field and the search base of where users are located. For example:

Base DN: o=[org]

 Addresses of LDAP Servers: my-edir-serv.mydomain.com
 
 Select LDAP TLS/SSL. 

 Select “Advanced Configuration”

 User Map: o=[org]

 Password Map: o=[org]

 Group Map: dc=[org]

 Password Change Protocol: nds

	Group member Attribute: member

Select “Administration Settings” from the top of the box.

	Configuration Base DN: o=[org]
	Administration DN: o=[org]

Select “Accept”

Save your changes with by clicking Finish.

2. 2.Edit the file /etc/nsswitch.conf and modify the following lines:
   

   passwd:		compat nam
   	group:		compat nam
   
   	passwd_compat: 	ldap	files
   	group_compat:	ldap	files
   	
   	

OES2 Migration

With the release of OES2 Linux, there are a number of migration utilities that have simplified the process. There are both Command Line and GUI versions that function basically the same and you can use to your own preference.

5. Data Migration

We will be migrating user data to a server that is in the same eDirectory tree and in the same container. We will use the GUI utility for presentation purposes.

From the OES2 Linux server, run YaST, select Open Enterprise Server and File Migration Utility.

Click to view.

Select Create New Project.
Specify the path to where you want the project file to be saved, or click Browse and select the path.
Click Forward.

Click to view.

Enter the Source Server (NetWare) IP address and the admin equivalent account in LDAP format and password. Ensure that Authenticate using SSL is checked.

Click Forward.

Click to view.

Click Add and select the Source and Target volumes you wish to migrate. Note: if you do not choose, the first volume on the list will be migrated.

Click Forward.

Click to view.

This screen is helpful if you can't migrate all the data at one time and have to finish the migration at a later date. Or if there are certain files you do not wish to be migrated, like Mpegs or a user's vast music collection.

If you have no changes to the default, click Forward.

Click to view.

This is your summary screen. Verify your migration setting and when you are satisfied, click Migrate.

Click to view.

Progress screen shows you the actual migration of the data. Once complete, you can view the log to see details. Click Close.

ACLs are also migrated with this utility.

6. DNS/DHCP

The migration of DNS and DHCP is much improved with OES2 and much, much simpler. I will try to explain the process, since there's not a lot of steps involved.

DNS

• Ensure that DNS is not running on the NetWare server.
• Login to iManager.
• Click DNS and then DNS Server Management.
• From the drop-down menu, select Move DNS Server and click OK.
• Select the DNS Server name from the drop-down list. This will be the OES2 Linux Server.
• Use the Object Selector to select the NCP (NetWare) server that will be migrated.
• Click Move.

All primary zones associated with old DNS server will be migrated.

DHCP

Start YaST, select Open Enterprise Server and Migrate Novell DHCP Server.

In the source server, put the NetWare server, in the target, OES2 Linux server.

In the DN for DHCP Server to be Migrated field, put the full DN for the source server.

Click Accept to start.

When complete, a message will pop up indicating success.

If there were any errors, you can examine the /var/log/dhcp-migration.log file on the OES2 Linux server. I recommend you look in any case, just to be sure.

7. ZENWorks Desktop Management v7 SP1 - Optional

Insert the ZDM 7 SP1 CD in the new server and browse to the mount point from the command line.

(/media/cdrom)

Copy the file, silent.properties to /root/.

Edit the file and modify the following lines:

INSTALL_REMOTE_MANAGEMENT=true
INSTALL_APPLICATION_MANAGEMENT=true
INSTALL_APPLICATION_MANAGEMENT_DATABASE=true
INSTALL_WORKSTATION_IMPORT_SERVER=true
INSTALL_ZDM_AGENT=true

Remove Comment from:

TREE_NAME=MY_COMPANY_TREE

SHOULD_EXTEND_SCHEMA=true
USER_SUPPLIED_SERIAL_NUMBER=[Enter your Activation Code Here]
ConfigureAction.ZDM_FORCE_CONFIGURE=true

Save the file and change directories to /media/cdrom

Type the following to install ZDM7 on your server:

./setup -f /root/silent.properties

When complete, dismount the CD.

In ConsoleOne, edit each NAL object to reflect the new path to the files on OES2 Linux Volume.

8. RSYNC - Optional

Migrating RSYNC is fairly uneventful accept for granting the proper POSIX acls to the NSS file mounts instead of default eDirectory acls.

Here is what needs to be changed and/or added and where.

On your main RSYNC Server, in the SYS:SYSTEM directory, there are several NCF files beginning with RS_. These files have numbers following the prefix that corresponds to a time that the file is executed. Find which file has the branch server reference in it and change that file to reflect the following:

Current:

rsync -vprtuz –stats –delete –volume=VOL1:
NETWARE_SERVER_NAME::NETWARE_SERVER_NAMEUsers /BACKUP/Branch_name/Users –timeout=360 –bwlimit=256

New:

rsync -vprtuz –stats –delete –volume=VOL1: 
OES2_SERVER_NAME::OES2_SERVER_NAMEUsers /BACKUP/Branch_name/Users –timeout=360 –bwlimit=256

Change the NETWARE_SERVER_NAME to OES2_SERVER_NAME in the file for that branch you are migrating.

On the new OES Linux server, edit the file /etc/rsyncd.conf

Make the following changes:

uid = admin
gid = root
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
slp refresh = 300

[OES-ServernameUsers]
	path = /media/nss/VOL1/users
	comment = (Branch name) Users
	read only = no
	chroot = no
	timeout = 60

[OES-ServernameShare]
	path = /media/nss/VOL1/share
	comment = (Branch name) Share
	read only = no
	chroot = no
	timeout = 60
	
	

Save this file and exit.

9. Decommission NetWare server

In ConsoleOne, remove the R/W replica from the NetWare Server.

Right-Click the Container Object for the branch and select Properties.

Click the Login Script Tab and change any reference to the NetWare server to reflect the OES Server –
i.e., MAP ROOT U:=NNETWARE_SERVER/VOL1:USERS/%1 to MAP ROOT U:=OES_SERVER_NAME/VOL1:USERS/%1

From the console of the NetWare server, type NWCONFIG and press Enter.

Select Directory Options|Remove Directory Services from this server

Press Enter on the warning and Yes to remove Directory Services. Choose .Root. as the reference point. Authenticate and complete the removal. Exit NWCONFIG and type EDIT C:\AUTOEXEC.BAT. REMark out the statement to load server.exe. Save the file and exit EDIT.

Down the Netware Server and power it off.

In ConsoleOne, remove any objects not removed by nwconfig relating to that server.

10. Workstations

The only changes that need to be made on the workstations is, if you specify a Preferred Server, it will need to be changed to reflect the new OES2 Linux Server.

Conclusion

Open Enterprise Server 2 has many improvements for migration from NetWare AND Windows to OES2 Linux, including tree to tree migration. And with OES2 SP1, Domain Services for Windows will add to the migration possibilities.

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.