Sumit Bose wrote:
On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote:
Based on a comment from Sumit in ticket here is a bare outline
of how one might do it:

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,
- 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

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/

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.


Freeipa-devel mailing list

Reply via email to