LDAP realm config

[Michael Griego]

Right, I did see those.  Their use, though, is able to be confined to  
the kldap plugin.  Since other parts of the kadmin code, for  
instance, are responsible for creating the key data on a password  
change and, therefore, must know what encryption/salt types to use  
when doing so, it was clear that the other attributes could not be so  
easily used and would have to be hooked in to the realm config  
elsewhere.  I was actually thinking that a further abstraction of the  
profile system might be the way to go, but I didn't want to tackle  
that without first checking on what may have already been done or  
decided.  Sounds like that's what's already on the roadmap.

So, I guess my next questions are:  What's the timetable for this, if  
there is one, has any work been done already on it, and where can I  
help?

--Mike

On Sep 21, 2007, at 6:10 AM, Savitha R wrote:

> Currently, only a few attributes( like maxticketlife, maxrenewlife  
> and ticketflags)
> of the realm configuration in directory is being used.
>
> The long term plan is to add a LDAP plugin when a plugin interface
> for the profile library is available.
>
>
> -Savitha
>
>>>> On Fri, Sep 21, 2007 at  5:44 AM, in message
> <DA147DCC-804C-4814-8DAD-433D2735C9D6 at nearband.com>, Michael Griego
> <mgriego at nearband.com> wrote:
>> I've been playing with the LDAP kdb backend, and was surprised by the
>> fact that the realm configuration attributed in the krbRealmContainer
>> object class aren't used.  Unfortunately, its not clear with the
>> current documentation that a kdc.conf is still needed when using the
>> LDAP kdb plugin.  As such, I've been looking into what it would take
>> to add the code needed to make use of the other realm configuration
>> attributes.
>>
>> I've done a fair amount of investigation into this, and its not a
>> trivial task (which I'm sure is the reason its not there
>> already... :).  Before I go much further, I was curious if anyone had
>> already done any work on this or had any thoughts on the best
>> approach.  One thought I had was to add another hook into the kdb
>> layer for getting realm parameters from the kdb backends.  There are
>> some possible chicken-and-egg scenarios there.
>>
>> Anyway, any input would be appreciated.  I'd really like to see the
>> ability to completely ditch the kdc.conf, stash file, and perhaps
>> even the kadm5.acl in favor of directory configuration.
>>
>> --Mike
>>
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>