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.