On (09/12/13 00:59), Howard Chu wrote: > Lukas Slebodnik wrote: >> On (07/12/13 08:37), Howard Chu wrote: >>> lslebodn(a)redhat.com wrote: >>>> Full_Name: Lukas Slebodnik >>>> Version: 2.4.38 >>>> OS: Fedora >>>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz >>>> Submission from: (NULL) (209.132.186.34) >>> >>> Fixed now in git master. >> >> Thank you. >> >> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me >> I was right that ApacheDS send wrong response. >> Could you confirm this statement? because I am not expert in ldap protocol >> and I would like to file a bug to ApacheDS upstream. > > The hex dumps you included were a bit difficult to read. I couldn't > tell what was sent from the server vs the client and what the message > boundaries were. It is output directly from wireshark. Indented lines represent response from server. ldap_communication_without_PP.hexdump ---------------------------------------------------------------------------- 00000000 30 5f 02 01 01 60 3b 02 01 03 04 2a 63 6e 3d 57 0_...`;. ...*cn=W 00000010 69 6c 6c 69 61 6d 20 42 75 73 68 2c 6f 75 3d 70 illiam B ush,ou=p 00000020 65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65 eople,dc =example 00000030 2c 64 63 3d 73 6b 80 0a 6a 61 68 6f 64 61 2e 31 ,dc=sk.. jahoda.1 00000040 32 33 a0 1d 30 1b 04 19 31 2e 33 2e 36 2e 31 2e 23..0... 1.3.6.1. 00000050 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 4.1.42.2 .27.8.5. 00000060 31 1 ^^^^^^^^ client 00000000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a.. ...... ^^^^^^^^ server 00000061 30 05 02 01 02 42 00 0....B. ^^^^^^^^ client ---------------------------------------------------------------------------- > If you can reproduce the behavior using e.g. > ldapwhoami -d7 that would be more legible. output from command ldapwhoami is in the attached file screenlog.2 but it loks like ApacheDS does not support LDAP_EXOP_WHO_AM_I.

> Meanwhile you can refer to draft-behera-ldap-password-policy for the > specification of the response control. The control value is mandatory > for this control. If I read draft "6.2. Response Control" correctly, http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 response can be sequence of "PasswordPolicyResponseValue". I think that sequence means "0 or more values"

In theory, there needn't be any password policy response value after control type. In this case, either my patch or your patch are wrong. Did I miss something? The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is the BER encoding of the following type:

PasswordPolicyResponseValue ::= SEQUENCE { warning [0] CHOICE { ...snip... } OPTIONAL, error [1] ENUMERATED { ...snip... } OPTIONAL } Thank you very much for response. LS