You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Markus Pohle <ap...@webunity.de> on 2007/07/25 14:27:02 UTC
[TwixEncoder] :: delivers different PDUs for same search result on
different operating systems
Hi list-users,
I do have problem with my content management system working with
apacheds on a windows 2003 server installation.
My content management system (coremmedia 2005) tries to identify each
user by ldap request against apacheds 1.5.x ldap server.
What I found out is, that the ldap request against an apacheds-1.5.x on
a windows 2003 server system isnt successful, while the same request
against a centos 4.3 or fedora 7 apacheds-1.5.x installation is successful.
How did I find that out? Well, I configured my CMS to connect against
apacheds-1.5.x on a windows 2003 server, where apacheds logs are in
debug mode. Then I tried to load CMS startpage, which is not successful.
Then I did the same with CMS connected against apacheds-1.5.x running on
centos 4.3 with logfiles in debug mode. Now the startpage was loaded.
I then searched thru the logfiles and found out the following:
- the search request from CMS is always the following:
[19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] -
Decoded LdapMessage : LdapMessage
message Id : 2
Search Request
Base Object : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
Scope : whole subtree
Deref Aliases : deref Always
Size Limit : no limit
Time Limit : no limit
Types Only : false
Filter : '(&(objectClass=inetOrgPerson)(uid=Jeder))'
Attributes : uid, mail, sn, cn, givenname, objectClass
Control
Control type : '2.16.840.1.113730.3.4.2'
Criticality : 'false'
[19:48:34] DEBUG
[org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
LdapMessage <2, SEARCH_REQUEST> from Twix to Snickers.
[19:48:34] DEBUG
[org.apache.directory.server.ldap.support.SearchHandler] - Message
received: SearchRequest
baseDn : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
filter : '(& (objectClass=inetOrgPerson) (uid=Jeder) ) '
scope : whole subtree
typesOnly : false
no limit
Time Limit : no limit
Deref Aliases : deref Always
attributes : 'uid', 'mail', 'sn', 'cn', 'givenname', 'objectClass'
- the search result is the same on both systems:
[19:48:34] DEBUG
[org.apache.directory.shared.ldap.codec.TwixTransformer] - Transformed
message : LdapMessage
message Id : 2
Search Result Entry
Object Name :
'0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
Attributes
Attributes
Attribute id : 'uid', Values : ['Jeder']
Attribute id : 'sn', Values : ['Jeder']
Attribute id : 'cn', Values : ['Jeder']
Attribute id : 'objectClass', Values :
['organizationalPerson', 'person', 'inetOrgPerson', 'top']
[19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
Encoding this LdapMessage : LdapMessage
message Id : 2
Search Result Entry
Object Name :
'0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
Attributes
Attributes
Attribute id : 'uid', Values : ['Jeder']
Attribute id : 'sn', Values : ['Jeder']
Attribute id : 'cn', Values : ['Jeder']
Attribute id : 'objectClass', Values :
['organizationalPerson', 'person', 'inetOrgPerson', 'top']
But the next line in debug log which contains the Encoded PDU differs
from windows 2003 server to centos43.
The windows 2003 encoded PDU looks like this:
[19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
Encoded PDU : 0x30 0x81 0xAD 0x02 0x01 0x02 0x64 0x81 0xA7 0x04 0x32
0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x63 0x6E 0x3D 0x75
0x73 0x65 0x72 0x
73 0x2C 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55 0x4E 0x47
0x2C 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53 0x48 0x4F 0x4C
0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0E 0x04 0x03 0x75 0x69 0x64 0x31
0x07 0x04 0x05
0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x73 0x6E 0x31 0x07 0x04
0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07
0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
0x65 0x63 0x74 0x4
3 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69
0x7A 0x61 0x74 0x69 0x6F 0x6E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E
0x04 0x06 0x70 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
0x4F 0x72 0x67 0
x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
The centos43 encoded PDU looks like this:
[10:26:02] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
Encoded PDU : 0x30 0x81 0xB0 0x02 0x01 0x02 0x64 0x81 0xAA 0x04 0x35
0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x20 0x63 0x6E 0x3D
0x75 0x73 0x65 0x
72 0x73 0x2C 0x20 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55
0x4E 0x47 0x2C 0x20 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53
0x48 0x4F 0x4C 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0D 0x04 0x02 0x73
0x6E 0x31 0x07
0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x06 0x70 0x65
0x72 0x73 0x6F 0x6E 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69 0x7A 0x61
0x74 0x69 0x6F 0x6
E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65
0x72 0x30 0x0E 0
x04 0x03 0x75 0x69 0x64 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65 0x72
Putting this two PDU strings in a small program that converts that hex
strings to readable char string delivers the following:
Windows 2003 Server:
0°dª5uid=Jeder, cn=users, dc=VERWALTUNG,
dc=DOUGLASHOLDING0q0
sn1Jeder0A objectClass12personorganizationalPerson
inetOrgPersontop0 cn1Jeder0uid1Jeder
CentOs 4.3:
0d§2uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING0q0uid1Jeder0
sn1Jeder0
cn1Jeder0A objectClass12organizationalPersonperson
inetOrgPersontop
My question is: what makes the difference? Where is the mistake? Where
is my mistake? What can I do? Is it a bug?
Any tips and hints are really appreciated. If neccessary, I can send
server.xml and logfiles from both servers, or whatever is needed.
Thanks in advance,
Markus
Re: [TwixEncoder] :: delivers different PDUs for same search result on different operating systems
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Markus,
the underlying OS won't add spaces in the DN ! Even if you dislike
Windows, this OS is not bad up to the point to add spaces just after a
comma... There should be something different.
I need some more info : can you try to inject a LDIF file into both
LDAP server with a new entry, and check if the result is the same when
requesting this entry ?
Now, the LDAP spec says that DN are considered equals if each or its
RDN is equal, using its specific MatchingRule . But first, the DN must
be normalized, which means all spaces before or after ',' and '+' are
to be removed, and all special chars are to be escaped.
Doing a straight string comparizon is not good at all, because we keep
the user provided data into the server (meaning that if you inject the
DN
"Dc=My OwN Do MaIn , dC = ORg", you will get it as is
when searching for this entry). This is a standard behavior, and you
can expect every LDAP server to give you back the DN you have
injected. However, if you do a search with 'dc=my won domain, dc=org",
the server will return the same entry.
Emmanuel
On 7/26/07, Markus Pohle <ap...@webunity.de> wrote:
>
> Hi Emmanuel,
>
> first of all thx for your reply!
>
> I did all my tests with the same apacheds-1.5.1-snapshot and testet
> ads first with 1.5.0_10 jdk and then did the test again with ads
> running with 1.6.0 jdk to be sure that there is no influence caused by
> the jdk.
>
> What I can say is, from within my tests, that the jdk version seems
> not to be relevant.
>
> What is relevant, from within my tests, seems to be the host operating
> system on which ads-1.5.1-snapshot is running.
>
> Here is, in your reply to me, a little mistake:
> On all unix-like operating systems I tested (with jdk 5/6) there are
> never whitespace in the returning DN. But on the windows based
> operating systems I tested there are whitespace in the returning DN.
>
> So the operating system on which ADS runs seems to have influence on
> what the returning PDU is.
>
> My question is: is this a bug in ADS? What can make ADS deliver
> different PDU for same ldap request? What can I do, except for your
> hint to use JNDI methods to do the comparison?
>
> TIA
> Markus
>
>
> Zitat von Emmanuel Lecharny <el...@gmail.com>:
>
> > Hi Markus,
> >
> > when I analyze both dump, what I can say is that the PDU lengths are
> > different. The first one (windows) has this DN :
> > uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
> > The second one, Cent OS, contains spaces :
> > uid=Jedel, cn=users, dc=VERWALMUNG, dc=DOUGLASHOLDING
> >
> > This is why you have different lengths (3 bytes, as we have three spaces).
> >
> > As you may use different JVMs on those two servers, the attributes
> > order may vary too. Which JVM are you using ?
> >
> > Here are the decoded messages :
> > on windows :
> > 0x30 0x81 0xAD
> > 0x02 0x01 0x02
> > 0x64 0x81 0xA7
> > 0x04 0x32
> > uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
> > 0x30 0x71
> > 0x30 0x0E
> > 0x04 0x03
> > uid
> > 0x31 0x07
> > 0x04 0x05
> > Jeder
> > 0x30 0x0D
> > 0x04 0x02
> > sn
> > 0x31 0x07
> > 0x04 0x05
> > Jeder
> > 0x30 0x0D
> > 0x04 0x02
> > cn
> > 0x31 0x07
> > 0x04 0x05
> > Jeder
> > 0x30 0x41
> > 0x04 0x0B
> > objectClass
> > 0x31 0x32
> > 0x04 0x14
> > organizationalPerson
> > 0x04 0x06
> > person
> > 0x04 0x0D
> > inetOrgPerson
> > 0x04 0x03
> > top
> >
> > on CentOS :
> > 0x30 0x81 0xB0
> > 0x02 0x01 0x02
> > 0x64 0x81 0xAA
> > 0x04 0x35
> > uid=Jeder, cn=users, dc=VERWALMUNG, dc=DOUGLASHOLDING
> > 0x30 0x71
> > 0x30 0x0D
> > 0x04 0x02
> > sn
> > 0x31 0x07
> > 0x04 0x05
> > Jeder
> > 0x30 0x41
> > 0x04 0x0B
> > objectClass
> > 0x31 0x32
> > 0x04 0x06
> > Person
> > 0x04 0x14
> > organizationalPerson
> > 0x04 0x0D
> > inetOrgPerson
> > 0x04 0x03
> > top
> > 0x30 0x0D
> > 0x04 0x02
> > cn
> > 0x31 0x07
> > 0x04 0x05
> > Jeder
> > 0x30 0x0E
> > 0x04 0x03
> > uid
> > 0x31 0x07
> > 0x04 0x05
> > Jeder
> >
> > One hypothesis is that you injected the last DN with spaces, which
> > should not be a pb at all, as spaces around ',' are to be ignored. Of
> > course, if you simply compare the resulting DN as strings, then you
> > will have a pb. You should use some of the JNDI methods to do those
> > comparisons (Name class)
> >
> > Hope it helps
> >
> > On 7/25/07, Markus Pohle <ap...@webunity.de> wrote:
> >> Hi list-users,
> >>
> >> I do have problem with my content management system working with
> >> apacheds on a windows 2003 server installation.
> >>
> >> My content management system (coremmedia 2005) tries to identify each
> >> user by ldap request against apacheds 1.5.x ldap server.
> >>
> >> What I found out is, that the ldap request against an apacheds-1.5.x on
> >> a windows 2003 server system isnt successful, while the same request
> >> against a centos 4.3 or fedora 7 apacheds-1.5.x installation is successful.
> >>
> >> How did I find that out? Well, I configured my CMS to connect against
> >> apacheds-1.5.x on a windows 2003 server, where apacheds logs are in
> >> debug mode. Then I tried to load CMS startpage, which is not successful.
> >> Then I did the same with CMS connected against apacheds-1.5.x running on
> >> centos 4.3 with logfiles in debug mode. Now the startpage was loaded.
> >>
> >> I then searched thru the logfiles and found out the following:
> >>
> >> - the search request from CMS is always the following:
> >>
> >> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] -
> >> Decoded LdapMessage : LdapMessage
> >> message Id : 2
> >> Search Request
> >> Base Object : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
> >> Scope : whole subtree
> >> Deref Aliases : deref Always
> >> Size Limit : no limit
> >> Time Limit : no limit
> >> Types Only : false
> >> Filter : '(&(objectClass=inetOrgPerson)(uid=Jeder))'
> >> Attributes : uid, mail, sn, cn, givenname, objectClass
> >> Control
> >> Control type : '2.16.840.1.113730.3.4.2'
> >> Criticality : 'false'
> >>
> >> [19:48:34] DEBUG
> >> [org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
> >> LdapMessage <2, SEARCH_REQUEST> from Twix to Snickers.
> >> [19:48:34] DEBUG
> >> [org.apache.directory.server.ldap.support.SearchHandler] - Message
> >> received: SearchRequest
> >> baseDn : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
> >> filter : '(& (objectClass=inetOrgPerson) (uid=Jeder) ) '
> >> scope : whole subtree
> >> typesOnly : false
> >> no limit
> >> Time Limit : no limit
> >> Deref Aliases : deref Always
> >> attributes : 'uid', 'mail', 'sn', 'cn', 'givenname', 'objectClass'
> >>
> >> - the search result is the same on both systems:
> >>
> >> [19:48:34] DEBUG
> >> [org.apache.directory.shared.ldap.codec.TwixTransformer] - Transformed
> >> message : LdapMessage
> >> message Id : 2
> >> Search Result Entry
> >> Object Name :
> >> '0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
> >> Attributes
> >> Attributes
> >> Attribute id : 'uid', Values : ['Jeder']
> >> Attribute id : 'sn', Values : ['Jeder']
> >> Attribute id : 'cn', Values : ['Jeder']
> >> Attribute id : 'objectClass', Values :
> >> ['organizationalPerson', 'person', 'inetOrgPerson', 'top']
> >>
> >> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
> >> Encoding this LdapMessage : LdapMessage
> >> message Id : 2
> >> Search Result Entry
> >> Object Name :
> >> '0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
> >> Attributes
> >> Attributes
> >> Attribute id : 'uid', Values : ['Jeder']
> >> Attribute id : 'sn', Values : ['Jeder']
> >> Attribute id : 'cn', Values : ['Jeder']
> >> Attribute id : 'objectClass', Values :
> >> ['organizationalPerson', 'person', 'inetOrgPerson', 'top']
> >>
> >> But the next line in debug log which contains the Encoded PDU differs
> >> from windows 2003 server to centos43.
> >>
> >> The windows 2003 encoded PDU looks like this:
> >>
> >> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
> >> Encoded PDU : 0x30 0x81 0xAD 0x02 0x01 0x02 0x64 0x81 0xA7 0x04 0x32
> >> 0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x63 0x6E 0x3D 0x75
> >> 0x73 0x65 0x72 0x
> >> 73 0x2C 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55 0x4E 0x47
> >> 0x2C 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53 0x48 0x4F 0x4C
> >> 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0E 0x04 0x03 0x75 0x69 0x64 0x31
> >> 0x07 0x04 0x05
> >> 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x73 0x6E 0x31 0x07 0x04
> >> 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07
> >> 0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
> >> 0x65 0x63 0x74 0x4
> >> 3 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69
> >> 0x7A 0x61 0x74 0x69 0x6F 0x6E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E
> >> 0x04 0x06 0x70 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
> >> 0x4F 0x72 0x67 0
> >> x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
> >>
> >> The centos43 encoded PDU looks like this:
> >>
> >> [10:26:02] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
> >> Encoded PDU : 0x30 0x81 0xB0 0x02 0x01 0x02 0x64 0x81 0xAA 0x04 0x35
> >> 0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x20 0x63 0x6E 0x3D
> >> 0x75 0x73 0x65 0x
> >> 72 0x73 0x2C 0x20 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55
> >> 0x4E 0x47 0x2C 0x20 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53
> >> 0x48 0x4F 0x4C 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0D 0x04 0x02 0x73
> >> 0x6E 0x31 0x07
> >> 0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
> >> 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x06 0x70 0x65
> >> 0x72 0x73 0x6F 0x6E 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69 0x7A 0x61
> >> 0x74 0x69 0x6F 0x6
> >> E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
> >> 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
> >> 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65
> >> 0x72 0x30 0x0E 0
> >> x04 0x03 0x75 0x69 0x64 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65 0x72
> >>
> >>
> >> Putting this two PDU strings in a small program that converts that hex
> >> strings to readable char string delivers the following:
> >>
> >> Windows 2003 Server:
> >> 0 ° d ª 5uid=Jeder, cn=users, dc=VERWALTUNG,
> >> dc=DOUGLASHOLDING0q0
> >> sn1 Jeder0A objectClass12 person organizationalPerson
> >> inetOrgPerson top0 cn1 Jeder0 uid1 Jeder
> >>
> >> CentOs 4.3:
> >> 0  d §
> >> 2uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING0q0 uid1
> >> Jeder0
> >> sn1 Jeder0
> >> cn1 Jeder0A objectClass12 organizationalPerson person
> >> inetOrgPerson top
> >>
> >>
> >> My question is: what makes the difference? Where is the mistake? Where
> >> is my mistake? What can I do? Is it a bug?
> >>
> >> Any tips and hints are really appreciated. If neccessary, I can send
> >> server.xml and logfiles from both servers, or whatever is needed.
> >>
> >> Thanks in advance,
> >> Markus
> >>
> >>
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
>
>
>
>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [TwixEncoder] :: delivers different PDUs for same search
result on different operating systems
Posted by Markus Pohle <ap...@webunity.de>.
Hi Emmanuel,
first of all thx for your reply!
I did all my tests with the same apacheds-1.5.1-snapshot and testet
ads first with 1.5.0_10 jdk and then did the test again with ads
running with 1.6.0 jdk to be sure that there is no influence caused by
the jdk.
What I can say is, from within my tests, that the jdk version seems
not to be relevant.
What is relevant, from within my tests, seems to be the host operating
system on which ads-1.5.1-snapshot is running.
Here is, in your reply to me, a little mistake:
On all unix-like operating systems I tested (with jdk 5/6) there are
never whitespace in the returning DN. But on the windows based
operating systems I tested there are whitespace in the returning DN.
So the operating system on which ADS runs seems to have influence on
what the returning PDU is.
My question is: is this a bug in ADS? What can make ADS deliver
different PDU for same ldap request? What can I do, except for your
hint to use JNDI methods to do the comparison?
TIA
Markus
Zitat von Emmanuel Lecharny <el...@gmail.com>:
> Hi Markus,
>
> when I analyze both dump, what I can say is that the PDU lengths are
> different. The first one (windows) has this DN :
> uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
> The second one, Cent OS, contains spaces :
> uid=Jedel, cn=users, dc=VERWALMUNG, dc=DOUGLASHOLDING
>
> This is why you have different lengths (3 bytes, as we have three spaces).
>
> As you may use different JVMs on those two servers, the attributes
> order may vary too. Which JVM are you using ?
>
> Here are the decoded messages :
> on windows :
> 0x30 0x81 0xAD
> 0x02 0x01 0x02
> 0x64 0x81 0xA7
> 0x04 0x32
> uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
> 0x30 0x71
> 0x30 0x0E
> 0x04 0x03
> uid
> 0x31 0x07
> 0x04 0x05
> Jeder
> 0x30 0x0D
> 0x04 0x02
> sn
> 0x31 0x07
> 0x04 0x05
> Jeder
> 0x30 0x0D
> 0x04 0x02
> cn
> 0x31 0x07
> 0x04 0x05
> Jeder
> 0x30 0x41
> 0x04 0x0B
> objectClass
> 0x31 0x32
> 0x04 0x14
> organizationalPerson
> 0x04 0x06
> person
> 0x04 0x0D
> inetOrgPerson
> 0x04 0x03
> top
>
> on CentOS :
> 0x30 0x81 0xB0
> 0x02 0x01 0x02
> 0x64 0x81 0xAA
> 0x04 0x35
> uid=Jeder, cn=users, dc=VERWALMUNG, dc=DOUGLASHOLDING
> 0x30 0x71
> 0x30 0x0D
> 0x04 0x02
> sn
> 0x31 0x07
> 0x04 0x05
> Jeder
> 0x30 0x41
> 0x04 0x0B
> objectClass
> 0x31 0x32
> 0x04 0x06
> Person
> 0x04 0x14
> organizationalPerson
> 0x04 0x0D
> inetOrgPerson
> 0x04 0x03
> top
> 0x30 0x0D
> 0x04 0x02
> cn
> 0x31 0x07
> 0x04 0x05
> Jeder
> 0x30 0x0E
> 0x04 0x03
> uid
> 0x31 0x07
> 0x04 0x05
> Jeder
>
> One hypothesis is that you injected the last DN with spaces, which
> should not be a pb at all, as spaces around ',' are to be ignored. Of
> course, if you simply compare the resulting DN as strings, then you
> will have a pb. You should use some of the JNDI methods to do those
> comparisons (Name class)
>
> Hope it helps
>
> On 7/25/07, Markus Pohle <ap...@webunity.de> wrote:
>> Hi list-users,
>>
>> I do have problem with my content management system working with
>> apacheds on a windows 2003 server installation.
>>
>> My content management system (coremmedia 2005) tries to identify each
>> user by ldap request against apacheds 1.5.x ldap server.
>>
>> What I found out is, that the ldap request against an apacheds-1.5.x on
>> a windows 2003 server system isnt successful, while the same request
>> against a centos 4.3 or fedora 7 apacheds-1.5.x installation is successful.
>>
>> How did I find that out? Well, I configured my CMS to connect against
>> apacheds-1.5.x on a windows 2003 server, where apacheds logs are in
>> debug mode. Then I tried to load CMS startpage, which is not successful.
>> Then I did the same with CMS connected against apacheds-1.5.x running on
>> centos 4.3 with logfiles in debug mode. Now the startpage was loaded.
>>
>> I then searched thru the logfiles and found out the following:
>>
>> - the search request from CMS is always the following:
>>
>> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] -
>> Decoded LdapMessage : LdapMessage
>> message Id : 2
>> Search Request
>> Base Object : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
>> Scope : whole subtree
>> Deref Aliases : deref Always
>> Size Limit : no limit
>> Time Limit : no limit
>> Types Only : false
>> Filter : '(&(objectClass=inetOrgPerson)(uid=Jeder))'
>> Attributes : uid, mail, sn, cn, givenname, objectClass
>> Control
>> Control type : '2.16.840.1.113730.3.4.2'
>> Criticality : 'false'
>>
>> [19:48:34] DEBUG
>> [org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
>> LdapMessage <2, SEARCH_REQUEST> from Twix to Snickers.
>> [19:48:34] DEBUG
>> [org.apache.directory.server.ldap.support.SearchHandler] - Message
>> received: SearchRequest
>> baseDn : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
>> filter : '(& (objectClass=inetOrgPerson) (uid=Jeder) ) '
>> scope : whole subtree
>> typesOnly : false
>> no limit
>> Time Limit : no limit
>> Deref Aliases : deref Always
>> attributes : 'uid', 'mail', 'sn', 'cn', 'givenname', 'objectClass'
>>
>> - the search result is the same on both systems:
>>
>> [19:48:34] DEBUG
>> [org.apache.directory.shared.ldap.codec.TwixTransformer] - Transformed
>> message : LdapMessage
>> message Id : 2
>> Search Result Entry
>> Object Name :
>> '0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
>> Attributes
>> Attributes
>> Attribute id : 'uid', Values : ['Jeder']
>> Attribute id : 'sn', Values : ['Jeder']
>> Attribute id : 'cn', Values : ['Jeder']
>> Attribute id : 'objectClass', Values :
>> ['organizationalPerson', 'person', 'inetOrgPerson', 'top']
>>
>> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
>> Encoding this LdapMessage : LdapMessage
>> message Id : 2
>> Search Result Entry
>> Object Name :
>> '0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
>> Attributes
>> Attributes
>> Attribute id : 'uid', Values : ['Jeder']
>> Attribute id : 'sn', Values : ['Jeder']
>> Attribute id : 'cn', Values : ['Jeder']
>> Attribute id : 'objectClass', Values :
>> ['organizationalPerson', 'person', 'inetOrgPerson', 'top']
>>
>> But the next line in debug log which contains the Encoded PDU differs
>> from windows 2003 server to centos43.
>>
>> The windows 2003 encoded PDU looks like this:
>>
>> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
>> Encoded PDU : 0x30 0x81 0xAD 0x02 0x01 0x02 0x64 0x81 0xA7 0x04 0x32
>> 0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x63 0x6E 0x3D 0x75
>> 0x73 0x65 0x72 0x
>> 73 0x2C 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55 0x4E 0x47
>> 0x2C 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53 0x48 0x4F 0x4C
>> 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0E 0x04 0x03 0x75 0x69 0x64 0x31
>> 0x07 0x04 0x05
>> 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x73 0x6E 0x31 0x07 0x04
>> 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07
>> 0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
>> 0x65 0x63 0x74 0x4
>> 3 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69
>> 0x7A 0x61 0x74 0x69 0x6F 0x6E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E
>> 0x04 0x06 0x70 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
>> 0x4F 0x72 0x67 0
>> x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
>>
>> The centos43 encoded PDU looks like this:
>>
>> [10:26:02] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
>> Encoded PDU : 0x30 0x81 0xB0 0x02 0x01 0x02 0x64 0x81 0xAA 0x04 0x35
>> 0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x20 0x63 0x6E 0x3D
>> 0x75 0x73 0x65 0x
>> 72 0x73 0x2C 0x20 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55
>> 0x4E 0x47 0x2C 0x20 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53
>> 0x48 0x4F 0x4C 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0D 0x04 0x02 0x73
>> 0x6E 0x31 0x07
>> 0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
>> 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x06 0x70 0x65
>> 0x72 0x73 0x6F 0x6E 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69 0x7A 0x61
>> 0x74 0x69 0x6F 0x6
>> E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
>> 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
>> 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65
>> 0x72 0x30 0x0E 0
>> x04 0x03 0x75 0x69 0x64 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65 0x72
>>
>>
>> Putting this two PDU strings in a small program that converts that hex
>> strings to readable char string delivers the following:
>>
>> Windows 2003 Server:
>> 0 ° d ª 5uid=Jeder, cn=users, dc=VERWALTUNG,
>> dc=DOUGLASHOLDING0q0
>> sn1 Jeder0A objectClass12 person organizationalPerson
>> inetOrgPerson top0 cn1 Jeder0 uid1 Jeder
>>
>> CentOs 4.3:
>> 0  d §
>> 2uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING0q0 uid1
>> Jeder0
>> sn1 Jeder0
>> cn1 Jeder0A objectClass12 organizationalPerson person
>> inetOrgPerson top
>>
>>
>> My question is: what makes the difference? Where is the mistake? Where
>> is my mistake? What can I do? Is it a bug?
>>
>> Any tips and hints are really appreciated. If neccessary, I can send
>> server.xml and logfiles from both servers, or whatever is needed.
>>
>> Thanks in advance,
>> Markus
>>
>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
Re: [TwixEncoder] :: delivers different PDUs for same search result on different operating systems
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Markus,
when I analyze both dump, what I can say is that the PDU lengths are
different. The first one (windows) has this DN :
uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
The second one, Cent OS, contains spaces :
uid=Jedel, cn=users, dc=VERWALMUNG, dc=DOUGLASHOLDING
This is why you have different lengths (3 bytes, as we have three spaces).
As you may use different JVMs on those two servers, the attributes
order may vary too. Which JVM are you using ?
Here are the decoded messages :
on windows :
0x30 0x81 0xAD
0x02 0x01 0x02
0x64 0x81 0xA7
0x04 0x32
uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING
0x30 0x71
0x30 0x0E
0x04 0x03
uid
0x31 0x07
0x04 0x05
Jeder
0x30 0x0D
0x04 0x02
sn
0x31 0x07
0x04 0x05
Jeder
0x30 0x0D
0x04 0x02
cn
0x31 0x07
0x04 0x05
Jeder
0x30 0x41
0x04 0x0B
objectClass
0x31 0x32
0x04 0x14
organizationalPerson
0x04 0x06
person
0x04 0x0D
inetOrgPerson
0x04 0x03
top
on CentOS :
0x30 0x81 0xB0
0x02 0x01 0x02
0x64 0x81 0xAA
0x04 0x35
uid=Jeder, cn=users, dc=VERWALMUNG, dc=DOUGLASHOLDING
0x30 0x71
0x30 0x0D
0x04 0x02
sn
0x31 0x07
0x04 0x05
Jeder
0x30 0x41
0x04 0x0B
objectClass
0x31 0x32
0x04 0x06
Person
0x04 0x14
organizationalPerson
0x04 0x0D
inetOrgPerson
0x04 0x03
top
0x30 0x0D
0x04 0x02
cn
0x31 0x07
0x04 0x05
Jeder
0x30 0x0E
0x04 0x03
uid
0x31 0x07
0x04 0x05
Jeder
One hypothesis is that you injected the last DN with spaces, which
should not be a pb at all, as spaces around ',' are to be ignored. Of
course, if you simply compare the resulting DN as strings, then you
will have a pb. You should use some of the JNDI methods to do those
comparisons (Name class)
Hope it helps
On 7/25/07, Markus Pohle <ap...@webunity.de> wrote:
> Hi list-users,
>
> I do have problem with my content management system working with
> apacheds on a windows 2003 server installation.
>
> My content management system (coremmedia 2005) tries to identify each
> user by ldap request against apacheds 1.5.x ldap server.
>
> What I found out is, that the ldap request against an apacheds-1.5.x on
> a windows 2003 server system isnt successful, while the same request
> against a centos 4.3 or fedora 7 apacheds-1.5.x installation is successful.
>
> How did I find that out? Well, I configured my CMS to connect against
> apacheds-1.5.x on a windows 2003 server, where apacheds logs are in
> debug mode. Then I tried to load CMS startpage, which is not successful.
> Then I did the same with CMS connected against apacheds-1.5.x running on
> centos 4.3 with logfiles in debug mode. Now the startpage was loaded.
>
> I then searched thru the logfiles and found out the following:
>
> - the search request from CMS is always the following:
>
> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixDecoder] -
> Decoded LdapMessage : LdapMessage
> message Id : 2
> Search Request
> Base Object : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
> Scope : whole subtree
> Deref Aliases : deref Always
> Size Limit : no limit
> Time Limit : no limit
> Types Only : false
> Filter : '(&(objectClass=inetOrgPerson)(uid=Jeder))'
> Attributes : uid, mail, sn, cn, givenname, objectClass
> Control
> Control type : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
>
> [19:48:34] DEBUG
> [org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
> LdapMessage <2, SEARCH_REQUEST> from Twix to Snickers.
> [19:48:34] DEBUG
> [org.apache.directory.server.ldap.support.SearchHandler] - Message
> received: SearchRequest
> baseDn : 'cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING'
> filter : '(& (objectClass=inetOrgPerson) (uid=Jeder) ) '
> scope : whole subtree
> typesOnly : false
> no limit
> Time Limit : no limit
> Deref Aliases : deref Always
> attributes : 'uid', 'mail', 'sn', 'cn', 'givenname', 'objectClass'
>
> - the search result is the same on both systems:
>
> [19:48:34] DEBUG
> [org.apache.directory.shared.ldap.codec.TwixTransformer] - Transformed
> message : LdapMessage
> message Id : 2
> Search Result Entry
> Object Name :
> '0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
> Attributes
> Attributes
> Attribute id : 'uid', Values : ['Jeder']
> Attribute id : 'sn', Values : ['Jeder']
> Attribute id : 'cn', Values : ['Jeder']
> Attribute id : 'objectClass', Values :
> ['organizationalPerson', 'person', 'inetOrgPerson', 'top']
>
> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
> Encoding this LdapMessage : LdapMessage
> message Id : 2
> Search Result Entry
> Object Name :
> '0.9.2342.19200300.100.1.1=jeder,2.5.4.3=users,0.9.2342.19200300.100.1.25=verwaltung,0.9.2342.19200300.100.1.25=douglasholding'
> Attributes
> Attributes
> Attribute id : 'uid', Values : ['Jeder']
> Attribute id : 'sn', Values : ['Jeder']
> Attribute id : 'cn', Values : ['Jeder']
> Attribute id : 'objectClass', Values :
> ['organizationalPerson', 'person', 'inetOrgPerson', 'top']
>
> But the next line in debug log which contains the Encoded PDU differs
> from windows 2003 server to centos43.
>
> The windows 2003 encoded PDU looks like this:
>
> [19:48:34] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
> Encoded PDU : 0x30 0x81 0xAD 0x02 0x01 0x02 0x64 0x81 0xA7 0x04 0x32
> 0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x63 0x6E 0x3D 0x75
> 0x73 0x65 0x72 0x
> 73 0x2C 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55 0x4E 0x47
> 0x2C 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53 0x48 0x4F 0x4C
> 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0E 0x04 0x03 0x75 0x69 0x64 0x31
> 0x07 0x04 0x05
> 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x73 0x6E 0x31 0x07 0x04
> 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07
> 0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
> 0x65 0x63 0x74 0x4
> 3 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69
> 0x7A 0x61 0x74 0x69 0x6F 0x6E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E
> 0x04 0x06 0x70 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
> 0x4F 0x72 0x67 0
> x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
>
> The centos43 encoded PDU looks like this:
>
> [10:26:02] DEBUG [org.apache.directory.shared.ldap.codec.TwixEncoder] -
> Encoded PDU : 0x30 0x81 0xB0 0x02 0x01 0x02 0x64 0x81 0xAA 0x04 0x35
> 0x75 0x69 0x64 0x3D 0x4A 0x65 0x64 0x65 0x72 0x2C 0x20 0x63 0x6E 0x3D
> 0x75 0x73 0x65 0x
> 72 0x73 0x2C 0x20 0x64 0x63 0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55
> 0x4E 0x47 0x2C 0x20 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53
> 0x48 0x4F 0x4C 0x44 0x49 0x4E 0x47 0x30 0x71 0x30 0x0D 0x04 0x02 0x73
> 0x6E 0x31 0x07
> 0x04 0x05 0x4A 0x65 0x64 0x65 0x72 0x30 0x41 0x04 0x0B 0x6F 0x62 0x6A
> 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x31 0x32 0x04 0x06 0x70 0x65
> 0x72 0x73 0x6F 0x6E 0x04 0x14 0x6F 0x72 0x67 0x61 0x6E 0x69 0x7A 0x61
> 0x74 0x69 0x6F 0x6
> E 0x61 0x6C 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x0D 0x69 0x6E 0x65 0x74
> 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x04 0x03 0x74 0x6F 0x70
> 0x30 0x0D 0x04 0x02 0x63 0x6E 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65
> 0x72 0x30 0x0E 0
> x04 0x03 0x75 0x69 0x64 0x31 0x07 0x04 0x05 0x4A 0x65 0x64 0x65 0x72
>
>
> Putting this two PDU strings in a small program that converts that hex
> strings to readable char string delivers the following:
>
> Windows 2003 Server:
> 0 ° d ª 5uid=Jeder, cn=users, dc=VERWALTUNG,
> dc=DOUGLASHOLDING0q0
> sn1 Jeder0A objectClass12 person organizationalPerson
> inetOrgPerson top0 cn1 Jeder0 uid1 Jeder
>
> CentOs 4.3:
> 0  d § 2uid=Jeder,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING0q0 uid1 Jeder0
> sn1 Jeder0
> cn1 Jeder0A objectClass12 organizationalPerson person
> inetOrgPerson top
>
>
> My question is: what makes the difference? Where is the mistake? Where
> is my mistake? What can I do? Is it a bug?
>
> Any tips and hints are really appreciated. If neccessary, I can send
> server.xml and logfiles from both servers, or whatever is needed.
>
> Thanks in advance,
> Markus
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com