directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: LDAP Triggers use cases: Need for real world data
Date Sun, 16 Jul 2006 16:40:50 GMT
On 7/16/06, Ersin Er <ersin.er@gmail.com> wrote:
> Hi Emmanuel,

s/Emmanuel/Enrique. Sorry :-)

> Thanks for the responses.
>
> More to say inlined..
>
> On 7/16/06, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > Ersin Er wrote:
> > > On 7/15/06, Enrique Rodriguez <enriquer9@gmail.com> 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

Mime
View raw message