take a look at the class org.apache.directory.shared.asn1.ber.tlv.IntegerDecoder
On Sat, Jun 23, 2012 at 12:39 AM, <[email protected]> wrote: > OK, Thank you very much for the clarification. I really thought I had it > right. > Last question on this. In 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? I'm looking for 208, which is > 0xd0 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écharny [mailto:[email protected]] > Sent: Thursday, June 21, 2012 6:40 PM > To: [email protected] > Subject: Re: 2 issues with Password policy response warnings / types > > Le 6/21/12 8:24 PM, [email protected] a écrit : >> Hi, we're deep into testing the password policy and we came across >> this situation. Using DS 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 >> be -128, 0, 60 instead they are -128, 1, 60 > No. The second byte is the length of the next field. Controls are encoded > using BER encoding, which means every PDU is encoded to containg a type, a > length and a value (TLV). Here, the type is 0x80 for timeBeforeExpiration and > 0x81 for graceLoginsRemaining. As soon as you have an integer type, then the > L byte is something between 1 and 4, > *never* 0. > > So 0x80 0x01 0x3C is correct. >> When 4 grace logins remain, the three bytes should be -128, 1, 4 >> instead they are -127, 1, 4 > Again, graceLogin is encoded 0x81 (-127) per the specification : > > SEQUENCE { > warning [0] CHOICE OPTIONAL { > timeBeforeExpiration [0] INTEGER (0 .. MaxInt), // 0x80<-> -128 > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } // 0x81<-> -127 > > so -127, 1, 4 is correct >> >> We have a user that has the pwdReset = true Attribute AND their password >> is about to expire. >> This is the byte[] value returned after 3 consecutive logins, you can >> see the password expiration working >> >> [48, 8, -96, 3, -128, 1, 122, -127, 1, 2] // pw expires in 122 >> seconds [48, 8, -96, 3, -128, 1, 83, -127, 1, 2] // pw expires in 83 >> seconds [48, 8, -96, 3, -128, 1, 48, -127, 1, 2] // pw expires in 48 >> seconds >> >> >> // here's the last case decoded. >> 48 (30) Skip >> 8 (8) Length = 8 >> -96 (160) Continue > This is 0xA0, the T for Warning[0] in the ASN/1 grammar >> 3 (3) Length = 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 >> Logins > This is not a type, it's the integer length for the timeBeforeExpiration field >> 48 (48) 48 seconds remaining on password<-- expected value but is >> getting set in grace logins > Do you mean that the control is fed incorrectly ? >> // loop again >> -127 (129) Error OK >> 1 (1) length =1 >> 2 (2) Error CHANGE_AFTER_RESET<-- this is what we expect. > correct >> >> >> Here's the same case, after the password expires. The Grace Login also >> has an Error instead of a warning [48, 8, -96, 3, -127, 1, 4, -127, 1, >> 2] >> -127 (129) Error<-- This should be a Warning -128 >> 1 (1) Type 1 = Grace Logins remaining<-- this is the correct warning >> 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 > 0xA0 0x03 // Warning, 3 bytes > 0x81 0x01 0x04 // graceLoginsRemaining, one byte, value = 4 > 0x81 0x01 0x02 // error, changeAfterReset > > > We may have some issues in the way we generate the response, but as far as I > can tell, the encoding is correct. > > Do you mean that the resulting PasswordPolicy instance is not correctly set ? > This is not what I see in the decoder... > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > -- Kiran Ayyagari
