Discussion:
Copy data form one ldap to another but the data seems difrent ( Entrust Attributes )
Add Reply
g***@gmail.com
2018-07-31 17:46:31 UTC
Reply
Permalink
Raw Message
Hi,

Currently I'm coping two attributes from one directory to another (entrustRoamFileEncInfo & entrustRoamingProfile).

When i copy this attributes and check the content on both servers on the new server is not right and running the test against the application the application fails to read the attributes, at least seems to be an encoding problem.

This attributes are set as a binary on all the connectors, also all the connectors are configured as "charset: ISO-8859-1" and all the LDAP instances also have "charset: ISO-8859-1".

Anyone could give me a hint on how to handle this attributes?

Regards,
j***@gmail.com
2018-08-01 08:11:00 UTC
Reply
Permalink
Raw Message
When writing the attributes, you could try to explicitly mark them as binary by appending ;binary to the attribute name. That is, instead of using the attribute name "entrustRoamFileEncInfo" you would use the name "entrustRoamFileEncInfo;binary".
Franzw
2018-08-01 12:21:32 UTC
Reply
Permalink
Raw Message
Post by j***@gmail.com
When writing the attributes, you could try to explicitly mark them as binary by appending ;binary to the attribute name. That is, instead of using the attribute name "entrustRoamFileEncInfo" you would use the name "entrustRoamFileEncInfo;binary".
TDI continues to amaze me ;-)

Is this documented somewhere - I have taken a look in the APIDOC and the formal documentation - but I cannot find this solution documented anywhere ?

Regards
Franz Wolfhagen
j***@gmail.com
2018-08-03 03:43:07 UTC
Reply
Permalink
Raw Message
Post by Franzw
TDI continues to amaze me ;-)
Is this documented somewhere - I have taken a look in the APIDOC and the formal documentation - but I cannot find this solution documented anywhere ?
Regards
Franz Wolfhagen
I was reading https://docs.oracle.com/javase/jndi/tutorial/ldap/misc/attrs.html

This paragraph is what gave me the idea:
----
The LDAP v3 allows options to be appended to an attribute name. Each option is preceded by a semicolon character (";"). Options are like attribute subclassing. That is, an attribute named without the option is treated as the superclass of an attribute named with an option. The only option defined by the protocol is binary ( indicated by using the string ";binary"), which means that the attribute's value should be transmitted in binary format (regardless of its actual syntax). This option is reserved for transmitting ASN.1 encoded data (such as certificates: "caCertificate;binary"). Servers that support attribute subclassing may support identification of the attribute without its binary option, but it is best always to include the binary option in the attribute name.
Franzw
2018-08-03 12:06:24 UTC
Reply
Permalink
Raw Message
Post by j***@gmail.com
Post by Franzw
TDI continues to amaze me ;-)
Is this documented somewhere - I have taken a look in the APIDOC and the formal documentation - but I cannot find this solution documented anywhere ?
Regards
Franz Wolfhagen
I was reading https://docs.oracle.com/javase/jndi/tutorial/ldap/misc/attrs.html
----
The LDAP v3 allows options to be appended to an attribute name. Each option is preceded by a semicolon character (";"). Options are like attribute subclassing. That is, an attribute named without the option is treated as the superclass of an attribute named with an option. The only option defined by the protocol is binary ( indicated by using the string ";binary"), which means that the attribute's value should be transmitted in binary format (regardless of its actual syntax). This option is reserved for transmitting ASN.1 encoded data (such as certificates: "caCertificate;binary"). Servers that support attribute subclassing may support identification of the attribute without its binary option, but it is best always to include the binary option in the attribute name.
I certainly learned something new there :-) I had not thought of this being a JNDI feature...

That said - TDI uses its own way of regarding attributes binary - I do not really believe that the problem is lying outside the different TDS versions and their content.

I would like to see examples of the attributes dumped from the TDSes via db2ldif of ldapsearch -L (the first is preferred). That should reveal what the TDS thinks it has stored...

Regards
Franz Wolfhagen
g***@gmail.com
2018-08-03 15:40:59 UTC
Reply
Permalink
Raw Message
Post by Franzw
Post by j***@gmail.com
Post by Franzw
TDI continues to amaze me ;-)
Is this documented somewhere - I have taken a look in the APIDOC and the formal documentation - but I cannot find this solution documented anywhere ?
Regards
Franz Wolfhagen
I was reading https://docs.oracle.com/javase/jndi/tutorial/ldap/misc/attrs.html
----
The LDAP v3 allows options to be appended to an attribute name. Each option is preceded by a semicolon character (";"). Options are like attribute subclassing. That is, an attribute named without the option is treated as the superclass of an attribute named with an option. The only option defined by the protocol is binary ( indicated by using the string ";binary"), which means that the attribute's value should be transmitted in binary format (regardless of its actual syntax). This option is reserved for transmitting ASN.1 encoded data (such as certificates: "caCertificate;binary"). Servers that support attribute subclassing may support identification of the attribute without its binary option, but it is best always to include the binary option in the attribute name.
I certainly learned something new there :-) I had not thought of this being a JNDI feature...
That said - TDI uses its own wa-y of regarding attributes binary - I do not really believe that the problem is lying outside the different TDS versions and their content.
I would like to see examples of the attributes dumped from the TDSes via db2ldif of ldapsearch -L (the first is preferred). That should reveal what the TDS thinks it has stored...
Regards
Franz Wolfhagen
Hi franz, running some test i manage to find that this is a problems caused by TDI, seems like at some point before write on the LDIF file after being read the attributes lose the correct encoding and regard i say to the parser that all the attributes must be writed on ISO-8859-1(Try using UTF-8 but as far as i now this data must be ISO-8859-1 when is parsed on a ldif) when the bulkload cmd read this information is not read correctly of at least the charset is not right.

To make my point, when i download this information using jXplorer on the current LDAP i see this type of characters: �, after y load this information on the new version they are load like this: ?.

Right now we are looking for some options for this, but if you have any idea of what could be the source of this problem let me know.
g***@gmail.com
2018-08-01 15:15:41 UTC
Reply
Permalink
Raw Message
Post by j***@gmail.com
When writing the attributes, you could try to explicitly mark them as binary by appending ;binary to the attribute name. That is, instead of using the attribute name "entrustRoamFileEncInfo" you would use the name "entrustRoamFileEncInfo;binary".
I will try this, but, this is not what the LDAP connector does when you indicate to the connector that is an binary attribute?
g***@gmail.com
2018-08-01 15:58:20 UTC
Reply
Permalink
Raw Message
Post by j***@gmail.com
When writing the attributes, you could try to explicitly mark them as binary by appending ;binary to the attribute name. That is, instead of using the attribute name "entrustRoamFileEncInfo" you would use the name "entrustRoamFileEncInfo;binary".
i Try this and doesn't work, i get the same result, this could be a LDAP problem? but i already check if this is a DB2 charset problem but! DB" and the instance have the same charset on both sides.
Loading...