Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2016-03-09 Thread Martin Basti 



On 09.03.2016 13:44, Martin Basti wrote:



On 09.03.2016 13:40, Alexander Bokovoy wrote:

On Wed, 09 Mar 2016, Martin Basti wrote:



On 09.03.2016 13:19, Alexander Bokovoy wrote:

On Wed, 09 Dec 2015, Simo Sorce wrote:
From f21c88b9f74453c6d6e16fb17d94efa469eed564 Mon Sep 17 00:00:00 
2001

From: Simo Sorce 
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 

Ticket: https://fedorahosted.org/freeipa/ticket/2579

ACK for the code as that is obvious but I have question about
objectclass replication -- we extend objectclass definition to allow
more attributes in MAY. How 389-ds handles replication of such case,
will a new definition override the old one without any problem?
if it will be updated by ipa-server-upgrade, it should be done 
without any problem.

I'm interested in the replication part.


ipa-server-upgrade will cause that schema definition will be replicated.
If you put ldif file just to directory and restart DS, then it will 
not be replicated. Replication requires that schema definitions must 
be added via ldapadd/mod. Thierry can provide more details.


Martin^2


Pushed to:
master: 7a20fc671b07344b0ee8460bef07398cb3ffaf59
ipa-4-3: 6798ee6d0db1aa5d975b82e156790d81960c8a7a

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2016-03-09 Thread Martin Basti 



On 09.03.2016 13:40, Alexander Bokovoy wrote:

On Wed, 09 Mar 2016, Martin Basti wrote:



On 09.03.2016 13:19, Alexander Bokovoy wrote:

On Wed, 09 Dec 2015, Simo Sorce wrote:

From f21c88b9f74453c6d6e16fb17d94efa469eed564 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
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 

Ticket: https://fedorahosted.org/freeipa/ticket/2579

ACK for the code as that is obvious but I have question about
objectclass replication -- we extend objectclass definition to allow
more attributes in MAY. How 389-ds handles replication of such case,
will a new definition override the old one without any problem?
if it will be updated by ipa-server-upgrade, it should be done 
without any problem.

I'm interested in the replication part.


ipa-server-upgrade will cause that schema definition will be replicated.
If you put ldif file just to directory and restart DS, then it will not 
be replicated. Replication requires that schema definitions must be 
added via ldapadd/mod. Thierry can provide more details.


Martin^2

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2016-03-09 Thread Alexander Bokovoy 

On Wed, 09 Mar 2016, Martin Basti wrote:



On 09.03.2016 13:19, Alexander Bokovoy wrote:

On Wed, 09 Dec 2015, Simo Sorce wrote:

From f21c88b9f74453c6d6e16fb17d94efa469eed564 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
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 

Ticket: https://fedorahosted.org/freeipa/ticket/2579

ACK for the code as that is obvious but I have question about
objectclass replication -- we extend objectclass definition to allow
more attributes in MAY. How 389-ds handles replication of such case,
will a new definition override the old one without any problem?
if it will be updated by ipa-server-upgrade, it should be done without 
any problem.

I'm interested in the replication part.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2016-03-09 Thread Martin Basti 



On 09.03.2016 13:19, Alexander Bokovoy wrote:

On Wed, 09 Dec 2015, Simo Sorce wrote:

From f21c88b9f74453c6d6e16fb17d94efa469eed564 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
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 

Ticket: https://fedorahosted.org/freeipa/ticket/2579

ACK for the code as that is obvious but I have question about
objectclass replication -- we extend objectclass definition to allow
more attributes in MAY. How 389-ds handles replication of such case,
will a new definition override the old one without any problem?
if it will be updated by ipa-server-upgrade, it should be done without 
any problem.


Martin^2


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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2016-03-09 Thread Alexander Bokovoy 

On Wed, 09 Dec 2015, Simo Sorce wrote:

From f21c88b9f74453c6d6e16fb17d94efa469eed564 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
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 

Ticket: https://fedorahosted.org/freeipa/ticket/2579

ACK for the code as that is obvious but I have question about
objectclass replication -- we extend objectclass definition to allow
more attributes in MAY. How 389-ds handles replication of such case,
will a new definition override the old one without any problem?


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




--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2016-03-09 Thread Martin Basti 

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>, 
"freeipa-devel" <freeipa-devel@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"
<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.





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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2015-12-09 Thread Simo Sorce 
- 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, _pac, _pad);
+if (client_entry == NULL) client_entry = client;
+
+if (is_as_req) {
+get_authz_data_types(context, client_entry, _pac, _pad);
+} else {
+get_authz_data_types(context, server, _pac, _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 da

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2015-12-09 Thread Simo Sorce 
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>, 
> "freeipa-devel" <freeipa-devel@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"
> > <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 f21c88b9f74453c6d6e16fb17d94efa469eed564 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..5d11f3c375dd1d0715cb1813cef4de2e5b4744fd 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2139,11 +2139,13 @@ kr

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2015-12-01 Thread Alexander Bokovoy 

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?


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.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2015-11-30 Thread Simo Sorce 
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.

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2015-11-25 Thread Simo Sorce 
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.

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

Re: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user

2015-11-24 Thread Jan Cholasta 

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?


The attribute is exposed in the service plugin, shouldn't it be exposed 
in the user plugin as well?


Nitpick: don't remove the space character here: "( uid )".

--
Jan Cholasta

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