From an old upstream thread https://www.redhat.com/archives/freeipa-users/2012-January/msg00197.html
When we query the remote LDAP server those are are processed into an internal IPA entry, thus passes through our schema parser and converted into the appropriate data type. The default type is unicode. If the incoming attribute is binary we fail completely.
The blacklist options don't help because those are processed after we have the entries.
Simo had a suggestion where we query only for and migrate certain attributes.
With the patches I posted a couple days ago (http://www.redhat.com/archives/freeipa-devel/2013-February/msg00426.html), an attribute value is not converted to Python type (and back) until it is accessed. This means that values of attributes which IPA knows nothing about are never converted, which might fix this issue. I will investigate if that is so.
I did some additional testing on this last night and wasn't able to reproduce it with IPA 3.0. It is easily reproducable with 2.2
What I did was this:
So this may already be addressed, though testing this specific scenario with migration and your new LDAP patches would probably be useful.
I have tested your scenario on IPA from current master, without and with my patches, and both work fine.
I have also tested a scenario where a directory string attribute of a user contains invalid UTF-8 value, which I think matches the ticket description better. In this case, migration to IPA without my patches fails miserably with an internal error. Migration to IPA with my patches (plus a small patch to use my new code in LDAPClient.add_entry as well) fails with an invalid syntax error, but only for the single user (overall it succeeds), which is IMHO far better result.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=924008
Metadata Update from @rcritten: - Issue assigned to jcholast - Issue set to the milestone: FreeIPA 3.2 - 2013/03
Login to comment on this ticket.