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 Thu, 26 Jul 2007 10:51:46 GMT
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 <apacheds.users@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 <elecharny@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 <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
>
>
>
>
>
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Mime
View raw message