If you plan to migrate from Sun Directory Server (Sun DS v5 to Sun DSEE v7,
including ODSEE 11gR1) to OpenLDAP 2.4 or later, here're a few non exhaustive
tips to keep in mind:
- Sun directory server versions up to 6.x don't enforce any attribute value
checking, as opposed to OpenLDAP. So, expect some work on your data before
being able to import them in OpenLDAP. Typically, if you had mail attribute
values containing forbidden characters (like "ç" for example) in Sun DS, you'll
have to modify your Sun DS LDIF export file and replace "ç" by "c" in each mail
attribute value, before being able to import it in OpenLDAP. In the same
manner, if you have illegal DN values for attributes like "manager" or
"uniquemember", OpenLDAP will refuse them and they must be fixed before you try
to import your data in OpenLDAP.
- Sun legacy attributes such like nsaccountlock don't exist in a standard
OpenLDAP schema. When nsaccountlock is FALSE, it just means the account is not
locked out, so you can just safely remove such attributes in the corresponding
LDIF entries of the OpenLDAP database. On the contrary, Sun directory server
locked accounts have a value of TRUE for the nsaccountlock attribute. In such a
case, if you want to keep the account locked in OpenLDAP, this should be
replace by: "pwdAccountLockedTime;pwd-userpassword: 000001010000Z"
And of course, you first need to include the password policy overlay and
schema in OpenLDAP to be able to use that kind of feature.
- Empty valued attributes are forbidden in OpenLDAP, and thus, the
corresponding attributes must be removed before being imported in OpenLDAP.
- "passwordexpirationtime: 19700101000000Z" should be replaced by
"pwdChangedTime: 19700101000000Z"
- If passwordexpirationtime is different from 19700101000000Z, the
corresponding value for pwdChangedTime must be set accordingly with your
password policy. Those attribute names are self explanatory to understand how
the value must be computed for each LDIF entry.
- The real nightmare comes with ACI's since there's no standard
implementation of LDAP access rights. Each directory vendor uses its own
syntax, its own implementation, and its own evaluation algorithm. So, there may
be different ways to translate the access rights for a a Sun directory server
to OpenLDAP. One could simply try to reproduce the same rules, which limits the
risks but may not be optimized, since OpenLDAP works differently. Another way
would be to rethink the access rights globally, understand what was done and
how OpenLDAP works to achieve the same result, in a possibly more efficient
way. At least, I would recommand to use (and include in the main OpenLDAP
config file) several files to clarify the access rights, and ease their
management. Also, I would think of using the OpenLDAP "break" directive, which
can help to mimic the Sun DS ACI's evaluation process.