On 7/16/06, Ersin Er <[EMAIL PROTECTED]> wrote:
Hi Emmanuel,
s/Emmanuel/Enrique. Sorry :-)
Thanks for the responses. More to say inlined.. On 7/16/06, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > Ersin Er wrote: > > On 7/15/06, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > >> Ersin Er wrote: > >> > Enrique Rodriguez wrote: > >> >> Ersin Er wrote: > >> ... > >> > So the Change Password Protocol provider is currently able to do this > >> > generation/conversion but the Core and LDAP Protocol Provider are not > >> > aware of this, right? > >> > >> Correct. Change Password protocol provider can also enforce password > >> policy (minimum length, character mix, etc.) which at some point should > >> be enforced globally. > > > > One more question: Change Password Protocol does not use clear text > > passwords, right? So we'll never be able to keep LDAP and Kerberos > > passwords in sync, right? > > The user enters a plaintext password on the client and that plaintext > password does traverse the network. The server-side will have the > plaintext password. So, I think that the answers to your questions are: > Change Password does "use" clear text passwords. We will be able to > keep LDAP and Kerberos passwords in sync. So where does the conversion occurs from clear text to KerberosKey object. (I could learn this via a constructor usage search but I do not have an environment here.) BTW, SP and Triggers are core level constructs. So I do not think that the clear text password reachs the core. But it's also a fact that Kerberos service itself can update LDAP password to keep both passwords in sync. So, adding an 'userPassword' update inside the Kerberos service's operation chain should not be hard. > While a plaintext password does traverse the network, it is over a > secure channel set up by the Change Password protocol in conjunction > with the Kerberos protocol. > > > > >> ... > >> > OK, so we'll have Triggers for modification type operations for the > >> > ou=Users based subtree. Is it reasonable to do this with an AFTER > >> > Trigger so that the Kerberos related attributes will be updated just > >> > after the entry has been added/modified? Because I'm not sure whether > >> > we'll support modification of request parameters inside triggered > >> stored > >> > procedures. > >> > >> I think this makes sense. > > > > Well, I have futher investigated this and saw that Kerberos related > > object class does not require the password related attribute to exist > > mandatorily. So it's ok to have an object class for Kerberos and not > > having the password attribute and adding the password attribute with > > another operation. So there is no pb here. > > OK, I see what you're saying. In fact, one of the major enhancements to > the 2nd version of Change Password was to add the ability to initialize > the password for a new user, from the client-side. > > Enrique > > -- Ersin
-- Ersin
