[Freeipa-devel] [PROPOSAL] Kerberos flags

Jan Cholasta jcholast at redhat.com
Tue Mar 12 16:02:25 UTC 2013


On 12.3.2013 16:00, Rob Crittenden wrote:
> Petr Spacek wrote:
>> On 12.3.2013 15:39, Rob Crittenden wrote:
>>> Petr Spacek wrote:
>>>> On 12.3.2013 13:34, Simo Sorce wrote:
>>>>>>> > >We might, but how do you check for the global value ?
>>>>>>> > >An additional search for every KDC operation is simply not
>>>>>>> going to
>>>>>>> > >happen.
>>>>>> >
>>>>>> >Can we do that extra search only when the KDC is initialized and
>>>>>> when
>>>>>> >configuration is refreshed? I don't think the default values would
>>>>>> >change too often, so this might be OK.
>>>>> How do you know when the configuration changes ?
>>>> Persistent search?
>>>>
>>>
>>> Well, this is where we might do well with a 389-ds plugin that
>>> monitors flag
>>> changes so we can catch changes made directly by kadmin.local as well.
>>> This
>>> would be similar to the password plugin in keeping several attributes
>>> in sync.
>>
>> I didn't understand your note about DS plugin.
>>
>> kadmin.local does all changes in LDAP, or not? All changes in LDAP DB
>> are sent via persistent search (if the persistent search was issued with
>> appropriate parameters).
>>
>
> Let me step back and say I know next to nothing about how the KDB
> backend works.
>
> What would be nice is one place to notice changes to these proposed
> flags and the flag bitfield. Whether that is best done in the backend or
> via a 389-ds plugin I don't know. So whatever we do, we need one place
> to notice changes in either the flag(s) or bitfield and keep the values
> in sync.

Why can't we set the bitfield (krbTicketFlags) directly? (There is an 
ACI preventing that, I'm just wondering what is the reason for this.)

>
> kadmin.local changes things in LDAP because we use our own backend
> driver. It doesn't speak LDAP natively.
>
> rob
>

-- 
Jan Cholasta




More information about the Freeipa-devel mailing list