directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: 2 issues with Password policy response warnings / types
Date Fri, 22 Jun 2012 19:15:25 GMT
take a look at the class
org.apache.directory.shared.asn1.ber.tlv.IntegerDecoder

On Sat, Jun 23, 2012 at 12:39 AM,  <Carlo.Accorsi@ibs-ag.com> 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: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 é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

Mime
View raw message