Hi Emmanuel, 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
