On Wed, 2015-11-25 at 12:43 -0500, 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 user
> > > 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 with
> > > 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 :)
> > 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.
> > Nitpick: don't remove the space character here: "( uid )".
> noted.

Bump, Alexander any opinion ?


Simo Sorce * Red Hat, Inc * New York

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to