directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject Re: [Kerberos] Kerberos + OpenLDAP
Date Fri, 02 Mar 2007 23:00:20 GMT
On 3/2/07, g.w@hurderos.org <g.w@hurderos.org> wrote:
> ...
> For ADS to get 'real' as a Kerberos implementation there will be some
> issues which need to be addressed.
>
> Our work on an LDAP interface for an MIT/KDC has to address some of
> the some issues your work does so I hope to feedback the results of
> some of our work to your codebase if they prove suitable.

I hope you'll help us.  I know you have a lot of experience managing
KDC's.  It will be interesting to review per-server, per-realm, and
per-user configuration with a DIT in mind.  We have rich semantics,
such as subtree and subtree refinements, which I think will play an
important role here.

And, of course, similar issues exist with the other realm control protocols.

> The exception, of course, is password creation/modification.  Since a
> KDC doesn't deal with passwords per se but rather keys derived from
> the password there is technically a requirement for an algorithmic
> action when a password manipulation event needs to be processed.

We have the challenge where passwords may come in from LDAP, LDIF, or
Change Password, so both the key derivation event and the enforcement
of password policy should be centralized.

> It actually struck me last night when I was cross-country skiing with
> my dog Iggy that administrative password modification could be done
> with strictly an LDAP interface.  It would require a client which
> understood the types of keys which the KDC wanted but that shouldn't
> be a show stopper.  The client could be simply distributed as a tool
> with ADS or whatever server was being used.

Our plan was to use something like a Trigger/SP on 'userPassword' to
both call a password policy check, then key derivation, then even
destroy the plaintext.  Then you wouldn't need client-side key
derivation nor the aforementioned encryption type negotiation.

There's an old thread here that I hope to resurrect, after SASL/GSSAPI:
http://www.nabble.com/LDAP-Triggers-use-cases%3A-Need-for-real-world-data-tf1828455.html#a4987843

> > ...
> > I know a common schema is a good thing overall regardless of whether
> > the changes are taking place via LDAP or via Changepw.  However are
> > there any foreseeable disadvantages to using LDAP verses Changepw
> > with this new schema or another?
>
> As I mentioned above I think the two concepts are somewhat orthogonal
> in character.
>
> I believe ChangePw is best desribed as a standardized
> interface/protocol for executing password changes.  The schema which
> I'm discussing is a method for describing data elements or objects
> needed to manage a Kerberos authentication identity.

For the list, changepw does nothing else than securely transmit a
plaintext password for a principal to the KDC.  Changepw supports a
given principal changing their own password, as well as allowing the
specification of an admin principal to change the password for another
principal, but that's it.  It also supports "setting" a password,
where the password is on a brand new account.

So, it's basically a single-command single-attribute request-response
protocol and, as such, can't manipulate any attributes representing
any other configuration.  This is where LDAP comes in.

> Other than the fact its a standardized protocol I'm not sure ChangePw
> would be needed in a purely LDAP managed Kerberos environment.  One of
> the things which ChangePw needs to do is authenticate the user.  If an
> authenticated BIND by the user is required to their Kerberos
> management object the same effect would be accomplished.  The only
> left is to translate the password attribute modification into a key
> generation action.

I agree an authenticated Bind is the same, but Changepw will be here
for a while as it is used in Windows from the command line or when you
issue Ctrl+Alt+Delete and hit "Change Password ..." as well as being
deployed in Linux et al as kpasswd.

Enrique

Mime
View raw message