From users-return-4742-apmail-directory-users-archive=directory.apache.org@directory.apache.org Fri Jun 22 20:55:14 2012 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 01B769D87 for ; Fri, 22 Jun 2012 20:55:14 +0000 (UTC) Received: (qmail 60270 invoked by uid 500); 22 Jun 2012 20:55:13 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 60207 invoked by uid 500); 22 Jun 2012 20:55:13 -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 60198 invoked by uid 99); 22 Jun 2012 20:55:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2012 20:55:13 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [62.153.167.38] (HELO postserver.ibs-ag.de) (62.153.167.38) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2012 20:55:07 +0000 Received: from postserver.ibs-ag.de (localhost [127.0.0.1]) by postserver.ibs-ag.de (Postfix) with ESMTP id 3A27A9F4EB for ; Fri, 22 Jun 2012 22:54:53 +0200 (CEST) Received: from IBSCAX1.ibs-ag.com (unknown [192.168.14.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postserver.ibs-ag.de (Postfix) with ESMTPS id 38FC59F430 for ; Fri, 22 Jun 2012 22:54:53 +0200 (CEST) Received: from IBSMBX.ibs-ag.com ([fe80::78e3:9c63:57ee:7d20]) by IBSCAX1.ibs-ag.com ([192.168.14.11]) with mapi; Fri, 22 Jun 2012 22:54:46 +0200 From: To: Date: Fri, 22 Jun 2012 22:54:45 +0200 Subject: RE: 2 issues with Password policy response warnings / types Thread-Topic: 2 issues with Password policy response warnings / types Thread-Index: Ac1Qq3LoEG52hFOwTtWGo/y7Aq2LeQADcF0w Message-ID: <2BE7E81B77921F43A6A273C2DF2FA6A43CC55B34DA@IBSMBX.ibs-ag.com> References: <2BE7E81B77921F43A6A273C2DF2FA6A43CC55B31D4@IBSMBX.ibs-ag.com> <4FE3A2CC.9090706@gmail.com> <2BE7E81B77921F43A6A273C2DF2FA6A43CC55B34AB@IBSMBX.ibs-ag.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Thanks that's great!=09 Carlo Accorsi -----Original Message----- From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] On Behalf Of= Kiran Ayyagari Sent: Friday, June 22, 2012 3:15 PM To: users@directory.apache.org Subject: Re: 2 issues with Password policy response warnings / types take a look at the class org.apache.directory.shared.asn1.ber.tlv.IntegerDecoder On Sat, Jun 23, 2012 at 12:39 AM, wrote: > OK, Thank you very much for the clarification. =A0I really thought I had = it right. > Last question on this. =A0In the case where the length after the 0x80 is = > 1. As below, where the length is 2. > > 30, 9, a0, 4, 80, 2, 0, d0, 81, 1, 2, > Do you know how to decode the int value? =A0 I'm looking for 208, which i= s =A00xd0 but not sure what to do with the other 0x00 byte? > > We're trying to untwist these messages on our own. If there's a class in = the project that's already doing this please lead us to it. > > > Thank you. > > Regards, > Carlo Accorsi > -----Original Message----- > From: Emmanuel L=E9charny [mailto:elecharny@gmail.com] > Sent: Thursday, June 21, 2012 6:40 PM > To: users@directory.apache.org > Subject: Re: 2 issues with Password policy response warnings / types > > Le 6/21/12 8:24 PM, Carlo.Accorsi@ibs-ag.com a =E9crit : >> Hi, we're deep into testing the password policy and we came across=20 >> this situation. =A0Using =A0DS built from the trunk version 1349996 >> >> Short description. In the ASN.1 response: >> When the password is expiring in 60 seconds , the three bytes should=20 >> be =A0-128, 0, 60 =A0instead they are -128, 1, 60 > No. The second byte is the length of the next field. Controls are=20 > encoded using BER encoding, which means every PDU is encoded to=20 > containg a type, a length and a value (TLV). Here, the type is 0x80=20 > for timeBeforeExpiration and 0x81 for graceLoginsRemaining. As soon as=20 > you have an integer type, then the L byte is something between 1 and=20 > 4, > *never* 0. > > So 0x80 0x01 0x3C is correct. >> When 4 grace logins remain, the three bytes should be =A0-128, 1, 4=20 >> instead they are -127, 1, 4 > Again, graceLogin is encoded 0x81 (-127) per the specification =A0: > > SEQUENCE { > =A0 =A0 =A0 warning =A0 [0] CHOICE OPTIONAL { > =A0 =A0 =A0 =A0 =A0timeBeforeExpiration =A0[0] INTEGER (0 .. MaxInt), =A0= // 0x80<-> =A0 > -128 > =A0 =A0 =A0 =A0 =A0graceLoginsRemaining =A0[1] INTEGER (0 .. maxInt) } //= 0x81<-> =A0 > -127 > > so -127, 1, 4 is correct >> >> We have a user that has the pwdReset =3D true =A0Attribute =A0 AND their= password is about to expire. >> This is the byte[] value returned after 3 consecutive logins, you can=20 >> see the password expiration working >> >> [48, 8, -96, 3, -128, 1, 122, -127, 1, 2] =A0// pw expires in 122=20 >> seconds [48, 8, -96, 3, -128, 1, 83, -127, 1, 2] // pw expires in 83=20 >> seconds [48, 8, -96, 3, -128, 1, 48, -127, 1, 2] // pw expires in 48=20 >> seconds >> >> >> // here's the last case decoded. >> 48 (30) Skip >> 8 (8) Length =3D 8 >> -96 (160) Continue > This is 0xA0, the T for Warning[0] in the ASN/1 grammar >> 3 (3) Length =3D 3 >> -128 (128) Warning OK > this is 0x80, the T for timeBeforeExpiration [0] in the ASN/1 grammar >> 1 (1) Type 1<-- ?? This should be error Type 0? Type 1 defines Grace=20 >> Logins > This is not a type, it's the integer length for the=20 > timeBeforeExpiration field >> 48 (48) 48 seconds remaining on password<-- expected value but is=20 >> getting set in grace logins > Do you mean that the control is fed incorrectly ? >> // loop again >> -127 (129) Error OK >> 1 (1) length =3D1 >> 2 (2) Error =A0CHANGE_AFTER_RESET<-- this is what we expect. > correct >> >> >> Here's the same case, after the password expires. The Grace Login=20 >> also has an Error instead of a warning [48, 8, -96, 3, -127, 1, 4,=20 >> -127, 1, 2] >> -127 (129) Error<-- This should be a Warning =A0-128 >> 1 (1) Type 1 =3D Grace Logins remaining<-- this is the correct warning=20 >> type >> 4 (4) 4 logins remaining<-- correct # of logins remaining > > Not sure I get your point on this last sample. > > If I decode the bytes, here is what I get : > 0x30 0x08 // a SEQUENCE, 8 bytes long > =A0 0xA0 0x03 // Warning, 3 bytes > =A0 =A0 0x81 0x01 0x04 // graceLoginsRemaining, one byte, value =3D 4 > =A0 0x81 0x01 0x02 // error, changeAfterReset > > > We may have some issues in the way we generate the response, but as far a= s I can tell, the encoding is correct. > > Do you mean that the resulting PasswordPolicy instance is not correctly s= et ? This is not what I see in the decoder... > > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com > -- Kiran Ayyagari