Return-Path: 
 <users-return-85481-apmail-httpd-users-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-users-archive@www.apache.org
Received: (qmail 66185 invoked from network); 20 Jan 2009 00:07:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 20 Jan 2009 00:07:03 -0000
Received: (qmail 40504 invoked by uid 500); 20 Jan 2009 00:06:51 -0000
Delivered-To: apmail-httpd-users-archive@httpd.apache.org
Received: (qmail 40487 invoked by uid 500); 20 Jan 2009 00:06:51 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help: <mailto:users-help@httpd.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@httpd.apache.org>
List-Post: <mailto:users@httpd.apache.org>
List-Id: <users.httpd.apache.org>
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 40478 invoked by uid 99); 20 Jan 2009 00:06:51 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jan 2009 16:06:51 -0800
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [218.225.124.146] (HELO nc04ws2002.sys.yzk.co.jp)
 (218.225.124.146)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jan 2009 00:06:43 +0000
Received: from nc02ws1076.sys.yzk.co.jp (unknown [192.244.194.76])
	by nc04ws2002.sys.yzk.co.jp (Postfix) with SMTP id 99B9814180E9
	for <users@httpd.apache.org>; Tue, 20 Jan 2009 09:06:22 +0900 (JST)
Received: from nc02ws1064.sys.yzk.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.sys.yzk.co.jp (Postfix) with ESMTP id 39C2835002D
	for <users@httpd.apache.org>; Tue, 20 Jan 2009 09:06:17 +0900 (JST)
Received: from edsrd1.yzk.co.jp (unknown [10.1.151.25])
	by nc02ws1064.sys.yzk.co.jp (Postfix) with ESMTP id 2EC63350021
	for <users@httpd.apache.org>; Tue, 20 Jan 2009 09:06:17 +0900 (JST)
Received: from [10.1.157.122] ([10.1.157.122]:4940)
	by edsrd1.yzk.co.jp with [XMail 1.22 ESMTP Server]
	id <S5117E4> for <users@httpd.apache.org> from <mcqueen-c@edsrd1.yzk.co.jp>;
	Tue, 20 Jan 2009 09:06:16 +0900
Message-ID: <49751578.4000704@edsrd1.yzk.co.jp>
Date: Tue, 20 Jan 2009 09:06:16 +0900
From: Craig McQueen <mcqueen-c@edsrd1.yzk.co.jp>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: users@httpd.apache.org
References: <4950593E.6080308@edsrd1.yzk.co.jp>
 <1404e5910812221926y4aeea9bcv7504aa625c2f4954@mail.gmail.com>
In-Reply-To: <1404e5910812221926y4aeea9bcv7504aa625c2f4954@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------000203040908080506040700"
X-WAuditID: 0901200906170000021893
X-Virus-Checked: Checked by ClamAV on apache.org
Subject: Re: [users@httpd] LDAP authorisation with Unicode in the Base DN

--------------000203040908080506040700
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Eric Covener wrote:
> On Mon, Dec 22, 2008 at 10:21 PM, Craig McQueen
> <mcqueen-c@edsrd1.yzk.co.jp> wrote:
>   
>> I'm trying to do LDAP authorisation with an Active Directory server, and the
>> "Base DN" has Japanese characters in it. This should be no problem, but I
>> can't get it to work.
>>
>> The Base DN is something like:
>> OU=裾野,OU=管理,DC=edsrd00,DC=local
>> The corresponding LDAP URL is something like:
>> AuthLDAPURL
>> "ldap://server:389/OU=\e8\a3\be\e9\87\8e,OU=\e7\ae\a1\e7\90\86,DC=edsrd00,DC=local?sAMAccountName?sub?(objectClass=*)"
>> NONE
>>
>> I think it has the Japanese characters specified in proper RFC 2255 format.
>> So I think there is a problem in the LDAP authentication module in properly
>> sending the queries with UTF-8 content in the base DN. The error.log file
>> says "[ldap_search_ext_s() for user failed][No Such Object]" which seems to
>> indicate that the LDAP server isn't getting a valid base DN.
>>
>> Any insights on this?
>>     
> packet trace would tell you what was put in the wire compared to a
> working command-line search.
>   
I finally got a chance to check this out with Wireshark. I found that
the Apache server is just putting the URI on the wire as given,
backslashes and numbers and all. So I guess it's not parsing the
backslash codes as RFC 2255 specifies.

Does this mean I should submit a bug report?

Regards,
Craig McQueen


--------------000203040908080506040700
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-2022-JP"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eric Covener wrote:
<blockquote
 cite="mid:1404e5910812221926y4aeea9bcv7504aa625c2f4954@mail.gmail.com"
 type="cite">
  <pre wrap="">On Mon, Dec 22, 2008 at 10:21 PM, Craig McQueen
<a class="moz-txt-link-rfc2396E"
 href="mailto:mcqueen-c@edsrd1.yzk.co.jp">&lt;mcqueen-c@edsrd1.yzk.co.jp&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I'm trying to do LDAP authorisation with an Active Directory server, and the
"Base DN" has Japanese characters in it. This should be no problem, but I
can't get it to work.

The Base DN is something like:
OU=裾野,OU=管理,DC=edsrd00,DC=local
The corresponding LDAP URL is something like:
AuthLDAPURL
<a class="moz-txt-link-rfc2396E"
 href="ldap://server:389/OU=%5Ce8%5Ca3%5Cbe%5Ce9%5C87%5C8e,OU=%5Ce7%5Cae%5Ca1%5Ce7%5C90%5C86,DC=edsrd00,DC=local?sAMAccountName?sub?%28objectClass=*%29">"ldap://server:389/OU=\e8\a3\be\e9\87\8e,OU=\e7\ae\a1\e7\90\86,DC=edsrd00,DC=local?sAMAccountName?sub?(objectClass=*)"</a>
NONE

I think it has the Japanese characters specified in proper RFC 2255 format.
So I think there is a problem in the LDAP authentication module in properly
sending the queries with UTF-8 content in the base DN. The error.log file
says "[ldap_search_ext_s() for user failed][No Such Object]" which seems to
indicate that the LDAP server isn't getting a valid base DN.

Any insights on this?
    </pre>
  </blockquote>
  <pre wrap=""><!---->packet trace would tell you what was put in the wire compared to a
working command-line search.
  </pre>
</blockquote>
<font face="Tahoma">I finally got a chance to check this out with
Wireshark. I found that the Apache server is just putting the URI
on the wire as given,
backslashes and numbers and all. So I guess it's not parsing the
backslash codes as RFC 2255 specifies.<br>
<br>
Does this mean I should submit a bug report?<br>
<br>
Regards,<br>
Craig McQueen<br>
<br>
</font>
</body>
</html>

--------------000203040908080506040700--