----- Original Message -----
> From: "Alexander Bokovoy" <aboko...@redhat.com>
> To: "Simo Sorce" <s...@redhat.com>
> Cc: "Jan Cholasta" <jchol...@redhat.com>, "freeipa-devel" 
> <freeipa-devel@redhat.com>
> 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 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 :)
> 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.

Agreed.

attached find an updated patch as I found a crash bug with the older one in 
some situations.

Simo.
From f4a27d66e5197f8dfe66d6e63b2fd6c17212d497 Mon Sep 17 00:00:00 2001
From: Simo Sorce <s...@redhat.com>
Date: Tue, 24 Nov 2015 18:01:52 -0500
Subject: [PATCH] Allow to specify Kerberos authz data type per user

Like for services setting the ipaKrbAuthzData attribute on a user object will
allow us to control exactly what authz data is allowed for that user.
Setting NONE would allow no authz data, while setting MS-PAC would allow only
Active Directory compatible data.

Signed-off-by: Simo Sorce <s...@redhat.com>

Ticket: https://fedorahosted.org/freeipa/ticket/2579
---
 daemons/ipa-kdb/ipa_kdb_mspac.c | 16 +++++++++-------
 install/share/60basev3.ldif     |  2 +-
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 8594309dbd27b45abda68de5f7ebf0c31e16904d..2687803b769e54b597b8cb14554c6e7e177b3cad 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2139,11 +2139,13 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
         ks_client_princ = client->princ;
     }
 
-    /* We only need to check the server entry here, because even if the client
-     * is a service with a valid authorization data it will result to NONE
-     * because ipadb_get_pac() can only generate a pac for 'real' IPA users.
-     * (I assume this will be the same for PAD.) */
-    get_authz_data_types(context, server, &with_pac, &with_pad);
+    if (client_entry == NULL) client_entry = client;
+
+    if (is_as_req) {
+        get_authz_data_types(context, client_entry, &with_pac, &with_pad);
+    } else {
+        get_authz_data_types(context, server, &with_pac, &with_pad);
+    }
 
     if (with_pad) {
         krb5_klog_syslog(LOG_ERR, "PAD authorization data is requested but " \
@@ -2185,7 +2187,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
         /* check or generate pac data */
         if ((pac_auth_data == NULL) || (pac_auth_data[0] == NULL)) {
             if (flags & KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) {
-                kerr = ipadb_get_pac(context, client_entry ? client_entry : client, &pac);
+                kerr = ipadb_get_pac(context, client_entry : client, &pac);
                 if (kerr != 0 && kerr != ENOENT) {
                     goto done;
                 }
@@ -2238,7 +2240,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
     kerr = 0;
 
 done:
-    if (client_entry != NULL) {
+    if (client_entry != NULL && client_entry != client) {
         ipadb_free_principal(context, client_entry);
     }
     krb5_pac_free(context, pac);
diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif
index f04044cc43efff737a1016e5870e7a322908dad5..5ebe335c3970c4161df45696f873d2fbe23fb394 100644
--- a/install/share/60basev3.ldif
+++ b/install/share/60basev3.ldif
@@ -76,7 +76,7 @@ objectClasses: (2.16.840.1.113730.3.8.12.15 NAME 'ipaIDrange' ABSTRACT MUST ( cn
 objectClasses: (2.16.840.1.113730.3.8.12.16 NAME 'ipaDomainIDRange' SUP ipaIDrange STRUCTURAL MAY ( ipaBaseRID $ ipaSecondaryBaseRID ) X-ORIGIN 'IPA v3' )
 objectClasses: (2.16.840.1.113730.3.8.12.17 NAME 'ipaTrustedADDomainRange' SUP ipaIDrange STRUCTURAL MUST ( ipaBaseRID $ ipaNTTrustedDomainSID ) X-ORIGIN 'IPA v3' )
 objectClasses: (2.16.840.1.113730.3.8.12.19 NAME 'ipaUserAuthTypeClass' SUP top AUXILIARY DESC 'Class for authentication methods definition' MAY ipaUserAuthType X-ORIGIN 'IPA v3')
-objectClasses: (2.16.840.1.113730.3.8.12.20 NAME 'ipaUser' AUXILIARY MUST ( uid ) MAY ( userClass ) X-ORIGIN 'IPA v3' )
+objectClasses: (2.16.840.1.113730.3.8.12.20 NAME 'ipaUser' AUXILIARY MUST ( uid) MAY ( userClass $ ipaKrbAuthzData ) X-ORIGIN 'IPA v3' )
 objectClasses: (2.16.840.1.113730.3.8.12.21 NAME 'ipaPermissionV2' DESC 'IPA Permission objectclass, version 2' SUP ipaPermission AUXILIARY MUST ( ipaPermBindRuleType $ ipaPermLocation ) MAY ( ipaPermDefaultAttr $ ipaPermIncludedAttr $ ipaPermExcludedAttr $ ipaPermRight $ ipaPermTargetFilter $ ipaPermTarget $ ipaPermTargetTo $ ipaPermTargetFrom ) X-ORIGIN 'IPA v4.0' )
 objectClasses: (2.16.840.1.113730.3.8.12.22 NAME 'ipaAllowedOperations' SUP top AUXILIARY DESC 'Class to apply access controls to arbitrary operations' MAY ( ipaAllowedToPerform $ ipaProtectedOperation ) X-ORIGIN 'IPA v4.0')
 objectClasses: (2.16.840.1.113730.3.8.12.24 NAME 'ipaPublicKeyObject' DESC 'Wrapped public keys' SUP top AUXILIARY MUST ( ipaPublicKey ) X-ORIGIN 'IPA v4.1' )
-- 
2.5.0

-- 
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