Sympa ldap search escapes chars incorrect

[renesepp]

AD dn view: OU=Asekantsleri vv (kõrgharidus, teadus ja,OU=....
tcpdump network capture to see how sympa escapes chars:
OU=Asekantsleri vv \28k\303\265rgharidus\5C, teadus ja,OU=...
Error:

Unable to perform LDAP operation: 0000208F: LdapErr: DSID-0C090787, comment: Error processing name, data 0, v1db1

As you can see the appearance after \5C is not correctly escaped. I know its bad that AD tree contains "," chars.
So maybe bug?

[ikedas]

Hi @renesepp,

Can you show us datasource setting (e.g. include_ldap_query) of Sympa?

[renesepp]

include_ldap_2level_query
name ad_group_globalad[% param.0 %]
host ad_server
port 3268
use_ssl no
ssl_version tls
suffix1 DC=sise
filter1 (&(cn=[% param.0 %])(objectClass=group))
attrs1 member
select1 all
timeout1 60
scope1 sub
suffix2 [attrs1]
filter2 (objectClass=person)
attrs2 mail
select2 first
scope2 base
timeout2 10

[ikedas]

Hi @renesepp,

So what parameter is assigned to [% param.0 %]?

And I want to clarify about packet dump: By which party (Sympa or AD) and when (in conversation between them) it was sent?
Additionally if possible, could you show corresponding hex dump along with text of DN (mixing escape is complicating)?

[renesepp]

Hi @ikedas,

1. source_parameter(group name)
2. Sympa, 2 level query I think

Sympa sent to AD

10.1.220.3=Sympa
10.1.7.100=AD

10.1.220.3 -> 10.1.7.100 LDAP 378 searchRequest(210) "CN=Example User,OU=Teadusosakond,OU=Asekantsleri vv \28k\303\265rgharidus\5C, teadus ja,OU=Kantsleri vastutusvaldkond,OU=Haridus- ja Teadusministeerium,OU=Haridus- ja Teadusministeeriumi valitsemisala,OU=Kasutajad,DC=riik,DC=sise" baseObject

AD server responded to Sympa

10.1.7.100 -> 10.1.220.3 LDAP 169 searchResDone(210) invalidDNSyntax (0000208F: LdapErr: DSID-0C090787, comment: Error processing name, data 0, v1db1) [3 results]

Hex dump of the searchRequest

0000 00 09 0f 09 02 26 00 50 56 93 50 b8 08 00 45 00
0010 01 6c 6b e2 40 00 40 06 d6 40 0a 01 dc 03 0a 01
0020 07 64 ca c2 0c c4 83 67 ff 85 f0 e1 d5 b6 80 18
0030 01 22 f8 c7 00 00 01 01 08 0a 8e 2f 96 69 10 c7
0040 50 34 30 82 01 34 02 02 00 d2 63 82 01 2c 04 81
0050 e2 43 4e 3d 4d 61 72 69 61 20 52 65 69 6e 66 65
0060 6c 64 74 2c 4f 55 3d 54 65 61 64 75 73 6f 73 61
0070 6b 6f 6e 64 2c 4f 55 3d 41 73 65 6b 61 6e 74 73
0080 6c 65 72 69 20 76 76 20 5c 32 38 6b c3 b5 72 67
0090 68 61 72 69 64 75 73 5c 35 43 2c 20 74 65 61 64
00a0 75 73 20 6a 61 2c 4f 55 3d 4b 61 6e 74 73 6c 65
00b0 72 69 20 76 61 73 74 75 74 75 73 76 61 6c 64 6b
00c0 6f 6e 64 2c 4f 55 3d 48 61 72 69 64 75 73 2d 20
00d0 6a 61 20 54 65 61 64 75 73 6d 69 6e 69 73 74 65
00e0 65 72 69 75 6d 2c 4f 55 3d 48 61 72 69 64 75 73
00f0 2d 20 6a 61 20 54 65 61 64 75 73 6d 69 6e 69 73
0100 74 65 65 72 69 75 6d 69 20 76 61 6c 69 74 73 65
0110 6d 69 73 61 6c 61 2c 4f 55 3d 4b 61 73 75 74 61
0120 6a 61 64 2c 44 43 3d 72 69 69 6b 2c 44 43 3d 73
0130 69 73 65 0a 01 00 0a 01 02 02 01 00 02 01 00 01
0140 01 00 a0 2e a3 15 04 0b 6f 62 6a 65 63 74 43 6c
0150 61 73 73 04 06 70 65 72 73 6f 6e a2 15 a4 13 04
0160 02 63 6e 30 0d 81 06 40 6c 69 73 74 2e 82 03 2e
0170 65 65 30 06 04 04 6d 61 69 6c

[ikedas]

@renesepp,

I got it. Sympa seems badly escaping result of the first level LDAP search operation at this line in Sympa/List.pm:

$escaped_attr =~ s/([\\\(\*\)\0])/sprintf "\\%02X", ord($1)/eg;

Can you remove (or comment out) the line above and check if AD won't complain?

---

Note: Above is first-aid treatment specific to reporter's case: In case that value of suffix2 parameter is "[attr1]". Complete fix may be done in other day.

[renesepp]

@ikedas

Seems to fix the issue after commenting out above line you mentioned.

[ikedas]

@renesepp, thanks for confirming. As I wrote, we may need some time for complete fix.

[ikedas]

Will fixed in the next beta, maybe 6.2.31b.1