harklib@protonmail.com wrote:

Hi,

I am in the process of migrating away from our ancient Oracle DSEE7 directory servers to OpenLDAP 2.4.44-23.el7_9.x86_64. One problem I'm experiencing when importing entries with attribute values encoded in base64 is:

adding new entry "cn=LastName,ou=People,dc=cs,dc=university,dc=edu"
ldap_add: Invalid syntax (21)
   additional info: gecos: value #0 invalid per syntax

dn: cn=nis,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: nis
olcAttributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY 
caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

In this example, the "gecos" attribute has the first name "Jérémie", e.g., "gecos:: SsOpcsOpbWll". When I decode it using `base64 -d` it decodes just fine. Why can I not import this base64 encoded value, and others, using ldapadd? I'm binding as olcRootDN which has the appropriate permission, manage, as far as I can tell but have also used SASL EXTERNAL--same results.

Do I need to decode these values in my LDIF file first? I've scoured the internet and the archives here, so forgive me if I've missed a glaringly obvious thread.

The IA5 syntax only allows plain ASCII characters, not accented characters. This has nothing to do with the fact that the value was base64 encoded (although clearly the value got encoded because it is not printable in plain ASCII).

Your DSEE7 server accepted these values because DSEE did not schema validation on any of its data, thus letting you store non-compliant garbage in your directory. You're going to need to clean up your data before importing into OpenLDAP. Either by changing values to be schema compliant, or by using attributes from your own custom schema definitions to accomodate the values you're working with.

Another note, I've used `./dsconf export --no-repl [...]` to avoid the DSEE7 sync-repl operational cruft. I still had some cleaning up to do, but I still don't understand why the base64 values are a hard stop.

Thanks in advance, Brian