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
