directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: LDAP Triggers use cases: Need for real world data
Date Sun, 16 Jul 2006 00:51:19 GMT
Ersin Er wrote:
> On 7/15/06, Enrique Rodriguez <> 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.


View raw message