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,
- 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
- 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
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
Adding the new schema and plugin should be the easy part.
Freeipa-devel mailing list