Helmut Volpers wrote: > Hi, > > Some comments and questions. > > > > 7. Whether users are allowed to change their own passwords. > > Why is it needed in the password policy ? It's an item of AccessControl. You can control password change via ACLs too. This provide a easier mechanism to switch on/off "the ability to change password". Once we support multiple policies ( i.e. association between set of users and a policy) this makes life easier ( don't have to create lots of ACLs). > > > > 8. Whether passwords must be changed after the administrator > > resets them. > > > > > > > > 12. Server Implementation > > 12.1 Password policy initialization > > > > The pwdPolicy object class holds the password policy settings for > > a set of user accounts. > > How is the set of user-accounts specified ? over a Subtree specification > or > a filter ? Is it not a case where subentries (operational objects) make > sense? > Subentries because you don't want to see this entries when you browse > through the DIT. > Section 14 touched on this issue. We left it open to get feedback from the community. We have considered the approaches you have suggested but didn't have time to think it thru to make it to the draft. This is one of the area which we will be working on for the next round. > > > > > > > > 12.5 Compare Operation > > > > The compare operation may be used to compare a userPassword. This > > might be performed when a client wishes to verify that user's > > supplied password is correct. An example of this is an LDAP PAM > > redirector or an LDAP HTTP authentication redirector. It is > > desirable to use this rather than performing a bind operation in > > order to reduce possible overhead involved in performing a bind. > > what's the overhead here ? before you compare you will also bind > authenticated ? correct. > > > > ACLs may be used to restrict this comparison from being made. > > In the normal case the compare to a UserPassword is not allowed by ACLs. It's a admin decision. > > > > > If a server supports this behavior, it MUST comply with the > > following. Otherwise the password policy described in this > > document may be circumvented. > > > > 12.5.1 During a compare operation on the userPassword attribute > > > > The server should > > will the returncodes and errormessages change for the compare operation > ? > > > > 1. Check the pwdAccountUnlockTime attribute. If it exists, return > > LDAP_UNWILLING_TO_PERFORM to indicate that the account is > > locked. > > > > 2. If ACLs permit, compare the password. > > > > > 14. Association between Users and Password Policy > > > > We have so far described two new objectclasses; one contains the > > password policy and the other contains password-related > > information in a user?s entry. We need an association between the > > password policy and users. Association via DIT or groups or any > > other method can be used. To make this policy work in a > > heterogeneous environment we need to describe a mechanism for the > > association. This work is still under investigation. > > I think there should be different password policies for "users", > "administrators", > "services", "CAs", etc. Right. > > > > > 15. Password Policy and Replication > > > > The pwdPolicyObject defines the password policy for a set of > > users of the directory and must be replicated on all the > > replicas. > > I think that is easy if we define a subentry for the password policy. I think so. > > > > /prasanta
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature