[Freeipa-devel] [PROPOSAL] Kerberos flags

[Rob Crittenden]

Sumit Bose wrote:
> On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:
>> Based on a comment from Sumit in ticket
>> https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline
>> of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags
>>
>> There is a bit of hand waving going on around how the flags are
>> actually set inside the KDB plugin since I'm not at all familiar
>> with that code but I don't expect it to be too big a deal.
>>
>> I'm not necessarily volunteering to do this work, just trying to
>> keep the ball moving forward.
>
> Thank you for setting up the design page. I would like to suggest that
> we should try to include all currently available flags in one run,
> because:
> - some flags related to OTP would be needed as well
> - it is only a minor increase the development effort
> - it is only a minor increase in the QE effort. Instead of doing
>    * set/unset flag in CLI/WebUI
>    * check with kdamin.local if the flag is in the expected state
>    for a single attribute it has to be done for a list of attributes
>    (maybe the steps can be added to a new 'How to test' section on the
>    design page)
> - it will help to find a good solution how to handle the flags in the
>    CLI/WebUI
>
> I think the last point is important because the flags are needed for all
> Kerberos principals, i.e. users, hosts and services. Instead of adding a
> list of new options/check boxes to each of the CLI commands/WebUI pages
> it might be more helpful to handle the flags separately. The CLI can get
> a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be
> shown and modified in a separate tab, I hope this will allow to use a
> common template to users, hosts and services. These are only rough ideas
> and suggestions, my point is that if we not only add a single flag but
> about 15 it might be easier to find a good and usable interface to
> modify them.

I'll update the page with these comments as well, eventually...

Ok, a new plugin makes sense, so we don't have to pollute all the other 
plugins with these flags.

One would need to pass in the object type they are dealing with:

ipa krbflags --type=user --ok-as-delegate=false sbose
ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com

We *could* avoid type potentially but it would expand our search base 
and could slow things down with lots of entries. We could search on the 
accounts container using (objectclass=ipaKrbPrincipal) and 
(|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something 
like that. I think I'd prefer specifying a type to avoid the case where 
someone has a hostname the same as a uid (we typically allow specifying 
non-fqdn when managing hosts).

As for setting all these flags, is this going to introduce oddball 
support issues if people start experimenting with turning somethings on 
and off? I really don't know. They can do it now using kadmin.local I 
suppose, and we aren't hearing any complaints.

Simo asked about upgrades. An interesting question.

So we'd have to sift through all the krbextradata to see if any of the 
flags we want to set are actually set and update LDAP. We may end up 
requiring a C tool to do this.

Mixing old and new backends could be supported during a transition 
period by setting the value both in the attribute and within 
krbextradata but we lack a way to do that in python AFAIK.

Doing this in a 398-ds plugin might be an easy way to support forwards 
and backwards compatibility, and it'd be C so we'd avoid all the python 
issues.

Adding the new schema and plugin should be the easy part.

rob