[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Password Policy draft...



"Steinitz, Dominic J" wrote:

> 1. In Section 6.1 "Bind Operation", 2, B, paragraph 3: what is the StartTLS operation? It doesn't appear in RFC2251 and no reference is given.

I will add reference to the StartTLS extended operation (RFC 2830).


>
>
> 2. In Section 7 "Client Implementation by LDAP operation", the following is specified:
>
>    The scenarios in the following operations assume that the client
>    attached a passwordPolicyRequest control to the request message of
>    the operation, and thus MAY receive a passwordPolicyResponse control
>    in the response message. In the event that the passwordPolicyRequest
>    control was not sent, no passwordPolicyRequest control is returned.
>    All other instructions remain the same.
>
> I couldn't find anything that specified what happens if the client doesn't attach a passwordPolicyRequest control and the password has expired, for example. Clearly the server can't return a passwordPolicyResponse control because Section 6  "Server Implementation by LDAP Operation" specifies:
>
>    The scenarios in the following operations assume that the client has
>    attached a passwordPolicyRequest control to the request message of
>    the operation. In the event that the passwordPolicyRequest control
>    was not sent, no passwordPolicyRequest control is returned. All
>    other instructions remain the same.

Ok, I will add text about what to do when there's no passwordPolicyRequest control and a password has expired.
I think that the only solution is that the server should return the same LDAP error and specify the reason of the error in the message.


>
> 3. In Section 8 "Administration of a Password Policy", the following is specified:
>
>    A password policy MUST be defined for a particular subtree of the
>    DIT by adding to an LDAP subentry whose immediate superior is the
>    root of the subtree, the pwdPolicy auxiliary object class.
>    The scope of the password policy is the same as the default scope of
>    an LDAP subentry as defined in section 5.1.2 of [SubEntry].
>
>    It is possible to define password policies for different password
>    attributes within the same pwdPolicy entry, by specifying multiple
>    values of the pwdAttribute. But password policies could also be in
>    separate sub entries as long as they are contained under the same
>    LDAP subentry.
>
> I think the first sentece of the second paragraph says that the same policy can apply to two attributes, for example,
>
> objectClass: pwdPolicy
> pwdAttribute: userPassword
> pwdAttribute: sn
>
> It's not clear why the second sentence begins with "But" as it refers to two different password policies not two password attributes. Does it mean that an entry could have two sub entries each with an objectClass of pwdPolicy but one with a pwdAttribute of userPassword, say, and the other with a pwdAttribute of sn, say? I suggest something like:
>
> "It is also possible to define password policies for different password attributes by using separate sub entries as long as they are contained under the same LDAP subentry"
>

The idea is that if you define set 2 attributes, the password policy is identical for both attributes.
However you may want to define 2 different password policies for 2 separate attributes with the same scope.
I'll try to clarify the text.


>
> 4. Is this draft generally implemented? Perhaps this isn't a question for this mailing list. I'm curious to know because if I modify my client would I have anything to test against?

>

>
> Dominic.

Thanks for your feedback.

Ludovic.

>
>
> -------------------------------------------------------------------------------------------------
> 21st century air travel     http://www.britishairways.com

--
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France