directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Carlo.Acco...@ibs-ag.com>
Subject RE: 2 issues with Password policy response warnings / types
Date Fri, 22 Jun 2012 19:09:35 GMT
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

Mime
View raw message