Linux and Unix LDAP clients and RFC2307 support

Quite often when one tries to migrate data from a directory server to another, small differences are discovered that prevent a direct and smooth migration. One of the most common issues when migrating from OpenLDAP or other Linux centric directory server to OpenDJ is around the schema for NIS, or the RFC 2307.

Before we dive into the core of the problem, let’s describe the symptoms:

Part of migrating from one directory to another consist of exporting the data to a common textual format, most likely LDIF, and import it in the new server. If you try to import some data in OpenDJ and it rejects entries as invalid with messages like the one just below, then you’ve just hit a schema issue with RFC 2307.

LDAP: error code 65 – Entry cn=MyGroup,ou=groups,dc=example,dc=com violates the Directory Server schema configuration because it does not include a structural objectclass.  All entries must contain a structural objectclass

Why a schema issue ?

Well, RFC 2307, “An Approach for Using LDAP as a Network Information Service” was published as an experimental RFC in 1998. As Unix vendors started to use it, they found a few issues which were addressed in an internet draft nicknamed rfc2307bis (the latest version can be found here). Solaris and HP-UX started to use this later schema, while Linux sticked to the official RFC.

One of the main difference between the RFC and the internet draft, is the PosixGroup object class definition that was changed from Structural to Auxiliary, hence the failure to import an entry defined with the RFC 2307 schema into a server supporting the rfc2307bis schema.

So what to do if I want to successfully import my data ?

There are 2 options : Fix the data to be compliant with rfc230bis schema or configure OpenDJ schema to be strictly RFC2307 compliant.

Fixing the data is quite simple, but requires basic knowledge of LDIF.

Since in rfc2307bis the posixGroup is Auxiliary, the entries are missing a Structural object class to be valid. The simplest way to fix that is to add the namedObject Structural object class.

dn: cn=MyGroup,ou=Groups,dc=example,dc=com
cn: MyGroup
objectClass: top
objectClass: posixGroup
objectClass: namedObject
gidNumber: 1001
description: My Group
memberUid: 1
memberUid: 10

Make sure you change all group definition and you can now import the data to OpenDJ.

Linux pam_ldap has full support for RFC2307bis. You just need to update the /etc/pam_ldap.conf file with the following line :

nss_schema rfc2307bis

Now, if you prefer to remain strictly compliant with RFC 2307, you need to change the schema of the OpenDJ server. Basically, you just need to stop the server, remove the 04-rfc2307bis.ldif file from the config/schema/ directory (save it in case you need it later) and add in the config/schema/ directory, the 04-rfc2307.ldif file. You can now import the data in OpenDJ.

This 04-rfc2307.ldif file is not part of the current distribution of OpenDJ, but we will add it pretty soon, however not as the default schema.

OpenAM – The Book

For many years, I’ve been working in collaboration with the Sun access management product team,  as it started working on the Directory Server Access Management Edition (DSAME) product that years later became Sun Access Manager and OpenSSO. And now that I’m at ForgeRock, I have the pleasure to keep working with some members of that team, on OpenAM, the continuation of the OpenSSO open source project.

My knowledge of the product is rather shallow as I’ve worked on several case studies or issues related to customers and LDAP directory servers, but I never had a chance to deploy a service for production use or even extensive testing.

So when I learnt that Packt Publishing was releasing a book on “OpenAM”, writen by Indira Thangasamy, an ex-colleague of mine and manager of the Quality Assurance team, I asked if I could get a copy for review, which Packt kindly agreed to.

I haven’t finished the book yet, as it’s over 250 pages of content, covering all aspects of the OpenAM software, from its history, its components and services, to its integration with Google Apps or SalesForce… But from what I’ve read (about 2/3 of the book), I can say that the book is easy to read and well organized. It helps a beginner to grasp the concepts and starts using the product, thanks to the detailed explanations and diagrams. As the chapters advance and dive into specific technical areas, Indira uses real-world examples and simple code or commands, followed by detailed description to illustrate what OpenAM does or does not, giving a comprehensive picture of the fully featured product.

Some of the features of OpenAM are not covered in the book, like Federation or the most recent Entitlement Services or Secure Token Services. I hope they will be covered in a revised edition or may be another book, as these features are becoming more used and important to enterprise security and access management.

In summary, if you’re about to, or have just started to engage on a project with OpenAM, this book will help you understand the technology and ease your ramping up. But even for the more experienced users of OpenAM, the book contains full of details, tips and example that will save you time and make you more efficient.

You can find the book on Pack-Publishing web site or Amazon.

Securing JBoss JMX console with OpenDS

Steve Millidge, founder of C2B2, has just published a nice and illustrated step by step tutorial for securing JBoss JMX console with LDAP and more specifically the OpenDS directory server. Similar steps could be used to secure all the different subsystems in JBoss, as illustrated in this already 2 years old tutorial about JBoss Portal, OpenSSO and OpenDS.

Technorati Tags: , , , , , ,