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.
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
