From users-return-5072-apmail-directory-users-archive=directory.apache.org@directory.apache.org Fri Feb 1 15:53:00 2013 Return-Path: X-Original-To: apmail-directory-users-archive@www.apache.org Delivered-To: apmail-directory-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C039D004 for ; Fri, 1 Feb 2013 15:53:00 +0000 (UTC) Received: (qmail 2130 invoked by uid 500); 1 Feb 2013 15:53:00 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 1875 invoked by uid 500); 1 Feb 2013 15:52:59 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 1812 invoked by uid 99); 1 Feb 2013 15:52:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2013 15:52:57 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pdemitrio@scoop-gmbh.de designates 209.85.212.177 as permitted sender) Received: from [209.85.212.177] (HELO mail-wi0-f177.google.com) (209.85.212.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2013 15:52:47 +0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so744983wib.4 for ; Fri, 01 Feb 2013 07:52:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=0pePb5IFbTvhAWvAIYllYGy1H6QsBqD/Ff30TRDJkao=; b=h83Q6ttONJS+c10ln6dEsWPuaflI0REA8c51xm5lDy56dxwx85mLgh6jy94mWvvPAU xhDMOPB33Cf5dqhLyeikboB+T+0r2CR5UTtrQ6nVf6aC0GEug2jdR7oLiaqnoFAhiBvo +j6tnzOrVXnItSfw7bzhdt1eGP6L3Z6SX2nEKgtHn4t5VK+dzxR5F04GiFFCGVfLogJA pyFiNE71TWDPLvwucDy2LzvNUqb168G77qugB9fkqVtY9dLDHB1vA28xUZxd31ToY/f4 KEJLM852DxPcUEfjwvIA6Mr1TeUSI2Ad2MD68a/PcallX+or96S6JgMeuISqxjV6qzUC PfvA== MIME-Version: 1.0 X-Received: by 10.194.90.242 with SMTP id bz18mr2975616wjb.24.1359733946481; Fri, 01 Feb 2013 07:52:26 -0800 (PST) Received: by 10.194.170.170 with HTTP; Fri, 1 Feb 2013 07:52:26 -0800 (PST) In-Reply-To: <510BD688.6050409@gmail.com> References: <510A3CF0.8080102@gmail.com> <2BE7E81B77921F43A6A273C2DF2FA6A43CD7B983AA@IBSMBX.ibs-ag.com> <2BE7E81B77921F43A6A273C2DF2FA6A43CD7B98443@IBSMBX.ibs-ag.com> <2BE7E81B77921F43A6A273C2DF2FA6A43CD7B984A9@IBSMBX.ibs-ag.com> <2BE7E81B77921F43A6A273C2DF2FA6A43CD7B985BA@IBSMBX.ibs-ag.com> <510B9450.40601@gmail.com> <510BD688.6050409@gmail.com> Date: Fri, 1 Feb 2013 16:52:26 +0100 Message-ID: Subject: Re: [ApacheDS] Error 56 From: Patricio Demitrio To: users@directory.apache.org, elecharny@apache.org Content-Type: multipart/mixed; boundary=047d7bfd0016de7e6804d4abba5a X-Gm-Message-State: ALoCoQk4qX1So6826WFi+s9OScBuBmCHR/oLYf7qT8GCMoRhfHBa3BxPCdNqPCsT1b0Di86wTZWH X-Virus-Checked: Checked by ClamAV on apache.org --047d7bfd0016de7e6804d4abba5a Content-Type: multipart/alternative; boundary=047d7bfd0016de7e5d04d4abba58 --047d7bfd0016de7e5d04d4abba58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I captured the operation using wireshark, I have no idea if this is useful or not. I'm attaching two files (wireshark format and plain text, both have same content). And here is an answer from a developer of openam, I'm copying it since maybe it helps. ----------- This error message is now coming out of LDAP authentication module, and not from the UMUserChangePassword page.. The LDAP authentication module grabs the existing password and creates a MODIFY request: remove userpassword: currentvalue add userpassword: newvvalue Looks like this is not really handled by Apache DS for some reason, which is quite strange. The other way is to simply run one operation of: replace userpassword: newvalue but this could be only done by a privileged user (who can reset passwords for arbitrary users). On Fri, Feb 1, 2013 at 3:51 PM, Emmanuel L=C3=A9charny wrote: > There is somethong *extremelly* weird... > > The userPassword value you are trying to modify is : > > e1NTSEF9NGx1QXphMkw...tM2F3SHFZN0E9PQ=3D=3D > > which once decoded gives : > > {SSHA}4luAza2L+0Xyut...VVm3awHqY7A=3D=3D > > and now, the password value is a base64 value, which makes no sense... > > Something in OpenAM should encode the real SSHA salted password in > base64, then add {SSHA) into the value, and try to remove this value > from the server. > > I would expect the real value to be : > > {SSHA}=C3=A2[=E2=82=AC=C3=8D=C2=AD=E2=80=B9=C3=BBE...Vm=C3=9A=C3=80z=CB= =9C=C3=AC > > instead... > > Is it possible that you capture the PDU being exchanged between OpenAM > and ApacheDS using wireshark ? > > > -- > Regards, > Cordialement, > Emmanuel L=C3=A9charny > www.iktek.com > > --047d7bfd0016de7e5d04d4abba58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, I captured the operation using wireshark, I have no id= ea if this is useful or not. I'm attaching two files (wireshark format = and plain text, both have same content).

And here is an = answer from a developer of openam, I'm copying it since maybe it helps.=

-----------
=C2=A0This error message is now comingout of LDAP authentication module, = and not from the UMUserChangePassword
page..The LDAP authentication module gra= bs the existing password and creates a
MODIFY request:=
remove userpassword: curr= entvalue
add userpasswor= d: newvvalue
Looks like th= is is not really handled by Apache DS for some reason,
which is quite = strange. The other way is to simply run one operation of:
replace userpassword: newvalue
but this could = be only done by a privileged user (who can reset
passwords for arbitrary users).


O= n Fri, Feb 1, 2013 at 3:51 PM, Emmanuel L=C3=A9charny <= ;elecharny@gmail.c= om> wrote:
There is somethong *extremelly* weird...

The userPassword value you are trying to modify is :

e1NTSEF9NGx1QXphMkw...tM2F3SHFZN0E9PQ=3D=3D

which once decoded gives :

{SSHA}4luAza2L+0Xyut...VVm3awHqY7A=3D=3D

and now, the password value is a base64 value, which makes no sense...

Something in OpenAM should encode the real SSHA salted password in
base64, then add {SSHA) into the value, and try to remove this value
from the server.

I would expect the real value to be :

{SSHA}=C3=A2[=E2=82=AC=C3=8D=C2=AD=E2=80=B9=C3=BBE...Vm=C3=9A=C3=80z=CB=9C= =C3=AC

instead...

Is it possible that you capture the PDU being exchanged between OpenAM
and ApacheDS using wireshark ?


--
Regards,
Cordialement,
Emmanuel L=C3=A9charny
www.iktek.com


--047d7bfd0016de7e5d04d4abba58-- --047d7bfd0016de7e6804d4abba5a--