bump for review
On 09.12.2015 21:00, Simo Sorce wrote:
Sent the wrong patch, attached the one that actually compiles.
----- Original Message -----
From: "Simo Sorce" <s...@redhat.com>
To: "Alexander Bokovoy" <aboko...@redhat.com>
Cc: "Simo Sorce" <s...@redhat.com>, "Jan Cholasta" <jchol...@redhat.com>,
Sent: Wednesday, December 9, 2015 2:18:23 PM
Subject: Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data
type per user
----- Original Message -----
From: "Alexander Bokovoy" <aboko...@redhat.com>
To: "Simo Sorce" <s...@redhat.com>
Cc: "Jan Cholasta" <jchol...@redhat.com>, "freeipa-devel"
Sent: Tuesday, December 1, 2015 3:07:32 AM
Subject: Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz
data type per user
On Wed, 25 Nov 2015, Simo Sorce wrote:
On Wed, 2015-11-25 at 08:09 +0100, Jan Cholasta wrote:
On 25.11.2015 00:09, Simo Sorce wrote:
This patch is untested and mostly an RFC.
I think it is all we need to allow to specify authz data types per
and by setting the attribute to NONE preventing a user from getting
MS-PAC data in their ticket.
Alexander you changed quite a bit the code around here so I'd like to
know if you think the change I made in the KDC will cause any issue
the special PACs we generate for master's principals. As far as I can
tell it shouldn't.
Any opinion is welcome.
Before your change, the server entry was checked for AS requests, now
only the client entry is checked for AS requests. I'm not very familiar
with ipa-kdb, but shouldn't the server entry still be checked as a
fallback when there is no authorization data in the client entry?
This is partly why I CCed Alexander, the way the get function works is
that it will get policy on the entry itself and if nothing is there it
will try with the global policy, so in both cases the global policy is
sourced as fallback.
For AS requests though you are generally asking for a TGT so the
"server" is the krbtgt entry that has no policy. It is through though
that a client *can* ask for a ticket directly via an AS request, that is
uncommon and it is unclear to me what we should do in that case if
client and server have incompatible options.
Well this is why it is a RFC after all :)
Can we source global policy for the direct AS request as well?
I think I would do this in a separate patch.
The attribute is exposed in the service plugin, shouldn't it be exposed
in the user plugin as well?
I didn't do it on purpose yet but eventually we may want to expose it,
indeed. The reason I didn't is that we may want to use something like
CoS to populate the attribute based on group membership and I am not
sure we want to expose it per user, up top debate.
I don't want to expose it in the config too.
attached find an updated patch as I found a crash bug with the older one in
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code