SUSE Conversations


YaST – Manual Migration From OpenLDAP to eDirectory on SLES



By: palaniappan1

August 7, 2009 11:44 am

Reads:288

Comments:0

Rating:0

This AppNote provides information on how to migrate YaST from OpenLDAP to eDirectory manually on SLES 9 or SLES 10, making sure that LDAP based applications do not break. SLES offers eDirectory to be used as an alternate to OpenLDAP. But applications already using LDAP on SLES would break unless there is a provision to migrate the existing data from OpenLDAP to eDirectory.

Contents:

Topics: Migrating schema, data and applications from OpenLDAP to eDirectory
Audience: network administrators, consultants, integrators
Level: intermediate
Prerequisite Skills: Familiarity with LDAP, YaST, SLES
Operating System: SLES 9, SLES 10, SLES 11
Tools: yast2, ldapconfig, ice, iManager

Introduction

SLES contains OpenLDAP as the default directory. SLES offering from Novell, makes eDirectory available to the customers. Hence, with SLES, the administrator would have an option to use eDirectory as the default directory. Since there are some SLES applications that can use LDAP directory, there would be a need to have the existing data in OpenLDAP migrated to eDirectory. The existing documentation of SLES can be referred to get information on eDirectory installation for various scenarios. Once the data is migrated to eDirectory, minor configuration changes might be needed to make the various directory enabled SLES applications work with eDirectory.

Wherever there is a mention of “SLES Applications” or “targeted applications”, it refers to YaST.

Scope of this document

The focus of this document covers the scenarios, where the OpenLDAP server has some data, which needs to be migrated to eDirectory. This activity is needed to prevent any breakage in LDAP based applications as part of the upgrade to eDirectory/SLES.

Scenarios not covered in this scope

Any scenarios where there are some applications other than YaST which are installed that use LDAP, and for which OpenLDAP schema has been extended, are not covered by this document. Though all the issues arising out of such scenarios would not be addressed here, this document may be used as a set of broader guidelines about how to go about this migration.

Migrating from OpenLDAP to eDirectory

Migration from one directory to another usually involves two steps. First schema is migrated, and then the data conforming to that schema is migrated.

YaST does not use LDAP compulsorily. This can be configured not to use LDAP at all. Hence, this step is performed only when OpenLDAP schema has been extended for YaST.

OpenLDAP schema gets extended when an application is configured for the first time to use LDAP. This extension is not reverted back if the configuration for the application changes from “Use LDAP” to “Do not use LDAP”.

Though there are multiple options to do the full migration, we take the following approach:

  1. Extend eDirectory schema with posixAccount schema
  2. Extend eDirectory schema with YaST schema

For this approach to work, eDirectory should be running. Also we’ll do this over the secure socket layer, which we recommend users to use. Prior to do this, we need the trusted root certificate (say, TrustedRootCertificate.der, which can me imported through iManager or ConsoleOne) of the server to which we are going to connect.

The default LDAP configuration for eDirectory includes “Require TLS for Simple Binds with Password=yes”. In order to successfully execute the following commands, this configuration needs to be changed to “no” temporarily. It can be done using the following command:

ldapconfig -w <password> -a <admin fdn in eDirectory format> -s "Require TLS for Simple Binds with Password=<yes/no>"

Example:

ldapconfig -w secret -a admin.acme -s "Require TLS for Simple Binds with Password=no"

Extending eDirectory schema with posixAccount schema

To extend the eDirectory schema with the posixAccount schema with the fields necessary for creating posix compliant user accounts, e.g. User ID (UID), primary group (GID), shell, home folder etc., import the schema from LDIF file to eDirectory, execute the following command:

ice -v -e <name of ldif file for errors> -S SCH -f <the nds schema file> -c -D LDAP -p <destination ldap port> -d <fdn of admin for destination in LDAP format> -w <password> -L <the trusted root certificate of the eDirectory server>

Example:

ice -v -e errorlog.ldif -S SCH -f /opt/novell/eDirectory/lib/nds-schema/rfc2307-usergroup.sch -c -D LDAP -p 636 -d cn=admin,dc=acme -w secret -L /home/export/TrustedRootCertificate.der

Extending eDirectory schema with YaST schema

To extend the eDirectory schema with the YaST schema to create the attributes that YaST need such as SID, hashed password etc, we need to import the YaST schema from the LDIF file by executing the following command.

ice -v -e <name of ldif file for errors> -S LDIF -f <the YaST nds schema file> -c -D LDAP -p <destination ldap port> -d <fdn of admin for destination in LDAP format> -w <password> -L <the trusted root certificate of the eDirectory server>

Download the nds-yast.schema file here.

Example:

ice -v -e errorlog.ldif -S LDIF -f /home/nds-yast.schema -c -D LDAP -p 636 -d cn=admin,dc=acme -w secret -L /home/export/TrustedRootCertificate.der

Once you see no errors, we can validate YaST once with OpenLDAP itself.

Validating YaST against OpenLDAP

Before stopping OpenLDAP and configuring with eDirectory, it is recommended to test YaST against OpenLDAP. For this purpose there might be a need for some generic configuration changes and some application specific ones. This section describes the generic modifications in LDAP Client.

  1. Start yast2 and click on “Network Services”.
  2. Click on “LDAP Client” to launch the LDAP Client Configuration window.
  3. For the field “Address of LDAP Servers”, enter the correct IP Address and the port separated by colon.

    For example, if its local machine, and eDirectory is listening on port 1389, configure the value “127.0.0.1:1389″ for this field.
  4. In the “Advanced Configuration” window, configure appropriate value for “Administrator DN” field. For our example, this value would be “cn=admin,dc=acme”.
  5. Click “Next” to come back to the “LDAP Client Configuration” window and click “Finish” to save and exit.

In the following sections we describe how to ensure that YaST that was using OpenLDAP before migration, continues to work with eDirectory.

Ensuring that YaST works properly with eDirectory

Open iManager and login to the eDirectory server which needs to be connected.

Create users and add needed extensions

  1. First create an OU in the tree (say, Users )
  2. Within this OU, create a group (say, eDirectoryUsers)
  3. Under the Schema section, click “Object Extensions”
  4. Select the group you created above and click OK
  5. Click Add, select posixGroup and click OK
  6. Enter a group number that’s not in use on the Linux server in the popped up window and click OK, and OK again

    You should now see posixGroup listed as an extension

  7. Create a user (say, testuser) in the OU you created earlier and set a password (no need to enter a simple password)
  8. Click OK to save the user
  9. Click on “Object Extensions”
  10. Choose the user you have just created and add the posixAccount extension
  11. Enter /home/username (/home/testuser here) in the ‘homeDirectory’ field
  12. Enter the group number you used above in ‘gidNumber ‘ and enter a unique user ID number in the ‘uidNumber’ field and click OK, and OK again

You should now see posixAccount listed as an extension.

We will create the home folder later.

Configure Linux services for LDAP authentication

  1. Start yast2 and click on “Network Services” in the left pane.
  2. Click on “LDAP Client” to launch the LDAP Client Configuration window.
  3. For the field “Address of LDAP Servers”, enter the correct IP Address and the port separated by colon.
  4. Enter the OU created earlier in the ‘LDAP Base DN’ field
  5. Select ‘LDAP TLS/SSL’
  6. Click on the button “Advanced Configuration…” in LDAP Client Configuration window.
  7. In the “Advanced Configuration” window, configure appropriate value for “Administrator DN” field. For our example, this value would be “cn=admin,dc=acme”.
  8. Ensure “File Server” and “Enable LDAP Users to Log In” fields are selected
  9. Click on the button “Next” to come back to the “LDAP Client Configuration” window.
  10. Click on button “Finish” in “LDAP Client Configuration” window.
  11. As root edit the file /etc/ldap.conf/ and check the host and base statements match your eDirectory server
  12. Uncomment the rootbinddn section and change the username to your administrator. Save the file and quit
  13. Create a file called /etc/ldap.secret and put your admin password in it. Change the permissions of the file to root read only, chmod 600 /etc/ldap.secret

    SLES should now authenticate to eDirectory…

    Try logging in using ssh using the above created user.

Conclusion

Thus we can easily migrate YaST from OpenLDAP to eDirectory, making sure that LDAP based applications do not break. Though SLES offers eDirectory to be used as an alternate to OpenLDAP, applications like YaST which use LDAP on SLES would break unless there is a provision to migrate the existing data from OpenLDAP to eDirectory. This document will help in this case.

References:

  1. iManager Help – http://www.novell.com/documentation/imanager25/index.html?page=/documentation/imanager25/imanager_admin_25/data/bu04qdu.html
  2. YaST Help – http://forgeftp.novell.com//yast/doc/SLES10/autoinstall/
  3. LDAP Tools Help – http://developer.novell.com/documentation/cldap/index.html?page=/documentation/cldap/ltoolenu/data/hevgtl7k.html
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , , ,
Categories: SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (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.

Comment

RSS