directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [TwixEncoder] :: delivers different PDUs for same search result on different operating systems
Date Wed, 25 Jul 2007 17:11:18 GMT
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 <apacheds.users@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

Mime
View raw message