On Thu, 2015-12-03 at 09:31 +0100, Petr Vobornik wrote:
> On 12/02/2015 07:16 PM, Simo Sorce wrote:
> > 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.
> >
> 
> I would agree if the optional setting(DisableUserSetKeytab) was not 
> enabled by default.

Do we have a ticket to fix whatever is broken by this ?
If not can you please create one with the details ?

In either case can you assign the ticket to me ?

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

Reply via email to