On Tue, 2015-12-01 at 16:44 +0100, Petr Vobornik wrote: > On 12/01/2015 04:20 PM, Alexander Bokovoy wrote: > > On Tue, 01 Dec 2015, Martin Kosek wrote: > >> On 12/01/2015 02:59 PM, Simo Sorce wrote: > >>> On Tue, 2015-12-01 at 14:42 +0100, Martin Kosek wrote: > >>>> On 12/01/2015 02:38 PM, Simo Sorce wrote: > >>>>> On Tue, 2015-12-01 at 10:11 +0200, Alexander Bokovoy wrote: > >>>>>> On Mon, 30 Nov 2015, Simo Sorce wrote: > >>>>>>> On Wed, 2015-11-25 at 09:47 -0500, Simo Sorce wrote: > >>>>>>>> On Wed, 2015-11-25 at 09:02 -0500, Rob Crittenden wrote: > >>>>>>>>> Jan Cholasta wrote: > >>>>>>>>>> On 24.11.2015 22:17, Simo Sorce wrote: > >>>>>>>>>>> On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote: > >>>>>>>>>>>> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: > >>>>>>>>>>>>> Since some time we use the getkeytab operation to fetch > >>>>>>>>>>>>> keytabs on > >>>>>>>>>>>>> newer > >>>>>>>>>>>>> clients. According to bug #232 setkeytab can be used to > >>>>>>>>>>>>> circumvent > >>>>>>>>>>>>> password quality controls so it needs to be slowly retired. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The attached patches implement #5485 in 2 parts. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The first introduces the option DisableSetKeytab which > >>>>>>>>>>>>> globally > >>>>>>>>>>>>> disables > >>>>>>>>>>>>> the setkeytab extended operation. This is set to false by > >>>>>>>>>>>>> default for > >>>>>>>>>>>>> backwards compatibility. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The second introduces an option called > >>>>>>>>>>>>> DisableUserSetKeytab, which is > >>>>>>>>>>>>> active by default in new installs (but not in upgraded > >>>>>>>>>>>>> ones), and only > >>>>>>>>>>>>> disables the use of setkeytab for ipa suers, but not for > >>>>>>>>>>>>> hosts/services. > >>>>>>>>>>>>> This is because user's are the ones that may abuse the > >>>>>>>>>>>>> interface to > >>>>>>>>>>>>> escape password policies and users also normally do not > >>>>>>>>>>>>> acquire > >>>>>>>>>>>>> keytabs, > >>>>>>>>>>>>> so it is a safe bet to disable just them by default in new > >>>>>>>>>>>>> installs. > >>>>>>>>>>>>> > >>>>>>>>>>>>> (Testing in progress) > >>>>>>>>>>>> > >>>>>>>>>>>> Tested and working as expected. > >>>>>>>>>>> > >>>>>>>>>>> I realized that adding options to ipaConfig require to add > >>>>>>>>>>> them in the > >>>>>>>>>>> UI as well, attached patches add options in API.txt and > >>>>>>>>>>> config.py > >>>>>>>>>>> Make now complain I should change API Major or Minor, but it > >>>>>>>>>>> is not > >>>>>>>>>>> clear to me why given this are additional values and no real > >>>>>>>>>>> change or > >>>>>>>>>>> new function is introduced. What's the recommendation ? > >>>>>>>>>> > >>>>>>>>>> When does make complain? It is supposed to complain only when > >>>>>>>>>> API.txt > >>>>>>>>>> does not match code. > >>>>>>>>>> > >>>>>>>>>> Anyway, we usually bump minor version even for backward > >>>>>>>>>> compatible > >>>>>>>>>> changes, see e.g. commit 9549a59. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> The point of API.txt (and the heavy client) was to save a > >>>>>>>>> round-trip. > >>>>>>>>> Being able to pass in an invalid option would void that rule hence > >>>>>>>>> having to update the API when new values are added. > >>>>>>>>> > >>>>>>>>> rob > >>>>>>>> > >>>>>>>> Ok added version change to the second patch (so we bump it only > >>>>>>>> once > >>>>>>>> given these are basically related changes. > >>>>>>> > >>>>>>> Bump, is this ok ? > >>>>>> This patch is fine but please fix setkeytab use in ipa-sam before > >>>>>> committing this patch. > >>>>> > >>>>> This patch does not disable setkeytab yet, so it can go in right away > >>>>> (it blocks other patches already). We have a bug to change ipa-sam, > >>>>> should we mark it blocker for 4.4 ? > >>>> > >>>> We also have to fix the permission to change keytab, so that it uses > >>>> the new > >>>> style (https://fedorahosted.org/freeipa/ticket/5487). I would > >>>> actually make > >>>> this ticket and the ipa-sam ticket a blocker for this patch set. > >>>> > >>>> Otherwise you are actually introducing a switch that breaks FreeIPA > >>>> as some of > >>>> it's core server functions still use the old method. > >>> > >>> The point of this patchset is to introduce the switch early so that > >>> current server will support the off switch when newer servers down the > >>> road are ready to flip it. The defaults are still to allow these > >>> operations for services/hosts. > >> > >> I still do not get the logic about an early switch. Now, if switch is > >> turned > >> on, FreeIPA server breaks on several places. I would really rather > >> expect the > >> switch to be introduced when the server itself supports it. Then, > >> admin would > >> enable it when the clients are sufficiently updated and can use the > >> new method. > >> > >> Why would admin want to enable the switch early if it breaks FreeIPA > >> some of > >> the FreeIPA servers? Permission can be upgraded in newer version and get > >> replicated, that's fine. But ipa-sam would be still broken on this old > >> FreeIPA > >> server. > > Old server is not a problem here: ipa-sam only talks to the > > localhost-based server as we always use ldapi protocol. So if server is > > running old-behavior FreeIPA, ipa-sam on the same server will work > > against it. > > > > What I don't want to have is a situation where setkeytab is disabled and > > a new server obeys it but ipa-sam on this new server is not updated and > > will expectedly fail. We are not that forced to do the change right now > > in 4.3, given that the default will still be to keep setkeytab, thus we > > can wait with this patch until ipa-sam is fixed and then push both > > patches into the closest release, be it 4.3.x (x>=0) or whatever is the > > next one. > > > > +1, fixing ipa-sam would be then a release blocker for 4.3 which is not > desired. > > Also what about adding support for "ipaProtectedoperation check" for > user principals? > > I'm afraid that forbidding getting user principal might be regarded as a > regression which might cause that admins won't set DisableSetKeytab.
One thing at a time. We have bugs open for all these things, but I see no reason not to add an *optional* setting just because some things break when it is turned on. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code