Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Petr Spacek]

On 1.12.2015 12:00, Alexander Bokovoy wrote:
> On Tue, 01 Dec 2015, Alexander Bokovoy wrote:
>> On Tue, 01 Dec 2015, Petr Spacek wrote:
>>> On 1.12.2015 09:47, Alexander Bokovoy wrote:
 On Tue, 01 Dec 2015, Petr Spacek wrote:
> On 1.12.2015 09:21, Alexander Bokovoy wrote:
>> On Tue, 01 Dec 2015, Petr Spacek wrote:
>>> On 24.11.2015 20:42, 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.
>>>
>>> On a related note, how this works with plain kadmin & kpasswd protocols?
>> It is unrelated. We don't support principal manipulation via kadmin
>> protocol.
>
> Sure, I know that, but I'm trying to find out if we re-invented the wheel 
> or
> if our wheel has some additional features which cannot be incorporated to
> the
> original wheel :-)
 There is no need to incorporate something specific into kadmin protocol,
 the problem is with the fact that we don't have access controls within
 our KDC driver. It always connects to LDAP server over ldapi as root and
 thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
 this means we'll need to have some access control added to KDC DAL
 driver before we can allow kadmin operations on principals.

 Adding those access controls is not an easy feat.
>>>
>>> Hmm, why is that? We could use LDAP Proxy control (RFC 4370) and let DS to
>>> evaluate ACIs as usual. The change in kadmin would be adding LDAP Proxy
>>> control with proper DN (i.e. mapping from principal name to DN) to the LDAP
>>> requests.
>> Not sure how does it help:
>> $ ldapsearch -Dcn=Directory\ Manager -W -e
>> \!authzid=dn:uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li -b
>> uid=admin,cn=users,cn=accounts,dc=vda,dc=li userPassword
>> Enter LDAP Password: # extended LDIF
>> #
>> # LDAPv3
>> # base 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Simo Sorce]

On Wed, 2015-12-02 at 08:40 +0100, Petr Spacek wrote:
> On 1.12.2015 12:00, Alexander Bokovoy wrote:
> > On Tue, 01 Dec 2015, Alexander Bokovoy wrote:
> >> On Tue, 01 Dec 2015, Petr Spacek wrote:
> >>> On 1.12.2015 09:47, Alexander Bokovoy wrote:
>  On Tue, 01 Dec 2015, Petr Spacek wrote:
> > On 1.12.2015 09:21, Alexander Bokovoy wrote:
> >> On Tue, 01 Dec 2015, Petr Spacek wrote:
> >>> On 24.11.2015 20:42, 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.
> >>>
> >>> On a related note, how this works with plain kadmin & kpasswd 
> >>> protocols?
> >> It is unrelated. We don't support principal manipulation via kadmin
> >> protocol.
> >
> > Sure, I know that, but I'm trying to find out if we re-invented the 
> > wheel or
> > if our wheel has some additional features which cannot be incorporated 
> > to
> > the
> > original wheel :-)
>  There is no need to incorporate something specific into kadmin protocol,
>  the problem is with the fact that we don't have access controls within
>  our KDC driver. It always connects to LDAP server over ldapi as root and
>  thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
>  this means we'll need to have some access control added to KDC DAL
>  driver before we can allow kadmin operations on principals.
> 
>  Adding those access controls is not an easy feat.
> >>>
> >>> Hmm, why is that? We could use LDAP Proxy control (RFC 4370) and let DS to
> >>> evaluate ACIs as usual. The change in kadmin would be adding LDAP Proxy
> >>> control with proper DN (i.e. mapping from principal name to DN) to the 
> >>> LDAP
> >>> requests.
> >> Not sure how does it help:
> >> $ ldapsearch -Dcn=Directory\ Manager -W -e
> >> \!authzid=dn:uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li -b
> >> uid=admin,cn=users,cn=accounts,dc=vda,dc=li userPassword
> >> Enter LDAP Password: # extended LDIF
> >> #
> >> # LDAPv3
> >> # base 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Petr Spacek]

On 1.12.2015 12:00, Alexander Bokovoy wrote:
> On Tue, 01 Dec 2015, Alexander Bokovoy wrote:
>> On Tue, 01 Dec 2015, Petr Spacek wrote:
>>> On 1.12.2015 09:47, Alexander Bokovoy wrote:
 On Tue, 01 Dec 2015, Petr Spacek wrote:
> On 1.12.2015 09:21, Alexander Bokovoy wrote:
>> On Tue, 01 Dec 2015, Petr Spacek wrote:
>>> On 24.11.2015 20:42, 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.
>>>
>>> On a related note, how this works with plain kadmin & kpasswd protocols?
>> It is unrelated. We don't support principal manipulation via kadmin
>> protocol.
>
> Sure, I know that, but I'm trying to find out if we re-invented the wheel 
> or
> if our wheel has some additional features which cannot be incorporated to
> the
> original wheel :-)
 There is no need to incorporate something specific into kadmin protocol,
 the problem is with the fact that we don't have access controls within
 our KDC driver. It always connects to LDAP server over ldapi as root and
 thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
 this means we'll need to have some access control added to KDC DAL
 driver before we can allow kadmin operations on principals.

 Adding those access controls is not an easy feat.
>>>
>>> Hmm, why is that? We could use LDAP Proxy control (RFC 4370) and let DS to
>>> evaluate ACIs as usual. The change in kadmin would be adding LDAP Proxy
>>> control with proper DN (i.e. mapping from principal name to DN) to the LDAP
>>> requests.
>> Not sure how does it help:
>> $ ldapsearch -Dcn=Directory\ Manager -W -e
>> \!authzid=dn:uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li -b
>> uid=admin,cn=users,cn=accounts,dc=vda,dc=li userPassword
>> Enter LDAP Password: # extended LDIF
>> #
>> # LDAPv3
>> # base 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Petr Spacek]

On 1.12.2015 09:21, Alexander Bokovoy wrote:
> On Tue, 01 Dec 2015, Petr Spacek wrote:
>> On 24.11.2015 20:42, 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.
>>
>> On a related note, how this works with plain kadmin & kpasswd protocols?
> It is unrelated. We don't support principal manipulation via kadmin
> protocol.

Sure, I know that, but I'm trying to find out if we re-invented the wheel or
if our wheel has some additional features which cannot be incorporated to the
original wheel :-)

>> Do I remember correctly that there is no way to download keytab without
>> re-generating it?
> New keytab extended operation allows retrieval without re-generation
> since FreeIPA 4.0. See http://www.freeipa.org/page/V4/Keytab_Retrieval
> and http://www.freeipa.org/page/V4/Keytab_Retrieval_Management

Sure, I was talking about the original kadmin/kpasswd protocols.

-- 
Petr^2 Spacek

-- 
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] Add option to disable setkeytab extended operations

[Alexander Bokovoy]

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 1.12.2015 09:21, Alexander Bokovoy wrote:

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 24.11.2015 20:42, 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.


On a related note, how this works with plain kadmin & kpasswd protocols?

It is unrelated. We don't support principal manipulation via kadmin
protocol.


Sure, I know that, but I'm trying to find out if we re-invented the wheel or
if our wheel has some additional features which cannot be incorporated to the
original wheel :-)

There is no need to incorporate something specific into kadmin protocol,
the problem is with the fact that we don't have access controls within
our KDC driver. It always connects to LDAP server over ldapi as root and
thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
this means we'll need to have some access control added to KDC DAL
driver before we can allow kadmin operations on principals.

Adding those access controls is not an easy feat.
--
/ 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] Add option to disable setkeytab extended operations

[Petr Spacek]

On 1.12.2015 09:47, Alexander Bokovoy wrote:
> On Tue, 01 Dec 2015, Petr Spacek wrote:
>> On 1.12.2015 09:21, Alexander Bokovoy wrote:
>>> On Tue, 01 Dec 2015, Petr Spacek wrote:
 On 24.11.2015 20:42, 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.

 On a related note, how this works with plain kadmin & kpasswd protocols?
>>> It is unrelated. We don't support principal manipulation via kadmin
>>> protocol.
>>
>> Sure, I know that, but I'm trying to find out if we re-invented the wheel or
>> if our wheel has some additional features which cannot be incorporated to the
>> original wheel :-)
> There is no need to incorporate something specific into kadmin protocol,
> the problem is with the fact that we don't have access controls within
> our KDC driver. It always connects to LDAP server over ldapi as root and
> thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
> this means we'll need to have some access control added to KDC DAL
> driver before we can allow kadmin operations on principals.
> 
> Adding those access controls is not an easy feat.

Hmm, why is that? We could use LDAP Proxy control (RFC 4370) and let DS to
evaluate ACIs as usual. The change in kadmin would be adding LDAP Proxy
control with proper DN (i.e. mapping from principal name to DN) to the LDAP
requests.

-- 
Petr^2 Spacek

-- 
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] Add option to disable setkeytab extended operations

[Alexander Bokovoy]

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 1.12.2015 09:47, Alexander Bokovoy wrote:

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 1.12.2015 09:21, Alexander Bokovoy wrote:

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 24.11.2015 20:42, 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.


On a related note, how this works with plain kadmin & kpasswd protocols?

It is unrelated. We don't support principal manipulation via kadmin
protocol.


Sure, I know that, but I'm trying to find out if we re-invented the wheel or
if our wheel has some additional features which cannot be incorporated to the
original wheel :-)

There is no need to incorporate something specific into kadmin protocol,
the problem is with the fact that we don't have access controls within
our KDC driver. It always connects to LDAP server over ldapi as root and
thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
this means we'll need to have some access control added to KDC DAL
driver before we can allow kadmin operations on principals.

Adding those access controls is not an easy feat.


Hmm, why is that? We could use LDAP Proxy control (RFC 4370) and let DS to
evaluate ACIs as usual. The change in kadmin would be adding LDAP Proxy
control with proper DN (i.e. mapping from principal name to DN) to the LDAP
requests.

Not sure how does it help:
$ ldapsearch -Dcn=Directory\ Manager -W -e 
\!authzid=dn:uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li -b 
uid=admin,cn=users,cn=accounts,dc=vda,dc=li userPassword
Enter LDAP Password: 
# extended LDIF

#
# LDAPv3
# base 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Alexander Bokovoy]

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 24.11.2015 20:42, 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.


On a related note, how this works with plain kadmin & kpasswd protocols?

It is unrelated. We don't support principal manipulation via kadmin
protocol.


Do I remember correctly that there is no way to download keytab without
re-generating it?

New keytab extended operation allows retrieval without re-generation
since FreeIPA 4.0. See http://www.freeipa.org/page/V4/Keytab_Retrieval
and http://www.freeipa.org/page/V4/Keytab_Retrieval_Management
--
/ 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] Add option to disable setkeytab extended operations

[Petr Spacek]

On 24.11.2015 20:42, 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.

On a related note, how this works with plain kadmin & kpasswd protocols?

Do I remember correctly that there is no way to download keytab without
re-generating it?

-- 
Petr^2 Spacek

-- 
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] Add option to disable setkeytab extended operations

[Alexander Bokovoy]

On Tue, 01 Dec 2015, Alexander Bokovoy wrote:

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 1.12.2015 09:47, Alexander Bokovoy wrote:

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 1.12.2015 09:21, Alexander Bokovoy wrote:

On Tue, 01 Dec 2015, Petr Spacek wrote:

On 24.11.2015 20:42, 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.


On a related note, how this works with plain kadmin & kpasswd protocols?

It is unrelated. We don't support principal manipulation via kadmin
protocol.


Sure, I know that, but I'm trying to find out if we re-invented the wheel or
if our wheel has some additional features which cannot be incorporated to the
original wheel :-)

There is no need to incorporate something specific into kadmin protocol,
the problem is with the fact that we don't have access controls within
our KDC driver. It always connects to LDAP server over ldapi as root and
thus maps to cn=Directory Manager which bypasses LDAP ACIs. As such,
this means we'll need to have some access control added to KDC DAL
driver before we can allow kadmin operations on principals.

Adding those access controls is not an easy feat.


Hmm, why is that? We could use LDAP Proxy control (RFC 4370) and let DS to
evaluate ACIs as usual. The change in kadmin would be adding LDAP Proxy
control with proper DN (i.e. mapping from principal name to DN) to the LDAP
requests.

Not sure how does it help:
$ ldapsearch -Dcn=Directory\ Manager -W -e 
\!authzid=dn:uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li -b 
uid=admin,cn=users,cn=accounts,dc=vda,dc=li userPassword
Enter LDAP Password: # extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Simo Sorce]

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.


-- 
Simo Sorce * Red Hat, Inc * New York
From 5b77aba72415ad40dfef02a25effa7fc09d34aa2 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Tue, 24 Nov 2015 14:02:01 -0500
Subject: [PATCH] Disable User's ability to use the setkeytab exop.

Users can still obtain a keytab for themselves using the getkeytab exop
which does not circumvent password policy checks.

Users are disallowed from using setkeytab by default in new installations
but not in existing installations (no forced upgrade).

Signed-off-by: Simo Sorce 

Ticket: https://fedorahosted.org/freeipa/ticket/5485
---
 API.txt|  2 +-
 VERSION|  2 +-
 daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c   |  4 
 .../ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c| 18 +-
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h   |  1 +
 install/share/bootstrap-template.ldif  |  1 +
 ipalib/plugins/config.py   |  2 +-
 7 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/API.txt b/API.txt
index 763ec12413fc1267b2cf7f519cf8c9bc14360c8c..9a7a23f0d6e3efcdaa355e15a37e8879d8f030d7 100644
--- a/API.txt
+++ b/API.txt
@@ -766,7 +766,7 @@ args: 0,25,3
 option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('delattr*', cli_name='delattr', exclude='webui')
-option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'DisableSetKeytab', u'KDC:Disable Last Success', u'KDC:Disable Lockout'))
+option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'DisableSetKeytab', u'DisableUserSetKeytab', u'KDC:Disable Last Success', u'KDC:Disable Lockout'))
 option: Str('ipadefaultemaildomain', attribute=True, autofill=False, cli_name='emaildomain', multivalue=False, required=False)
 option: Str('ipadefaultloginshell', attribute=True, autofill=False, cli_name='defaultshell', multivalue=False, required=False)
 option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name='defaultgroup', multivalue=False, required=False)
diff --git a/VERSION b/VERSION
index 064e98cb46a084b9f87f4fb52c8cd6033be171a4..cbd1cb35fc303ad1175ee59e1702d47de3ecae30 100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
 #  #
 
 IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=158

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Simo Sorce]

On Wed, 2015-11-25 at 10:24 +0100, Sumit Bose wrote:
> On Tue, Nov 24, 2015 at 02:42:32PM -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.
> 
> ipasam uses this exop to create the cross-realm TGT principal objects,
> krbtgt/DOM.A@DOM.B. What should be used instead to make sure that
> setkeytab can safely be disabled?

It must use the new getkeytab extended operation.

Can you open a ticket to fix this and assign it to me ?

Simo.

> bye,
> Sumit
> 
> > 
> > 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)
> > 
> > Simo.
> > 
> > -- 
> > Simo Sorce * Red Hat, Inc * New York


-- 
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] Add option to disable setkeytab extended operations

[Sumit Bose]

On Tue, Nov 24, 2015 at 02:42:32PM -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.

ipasam uses this exop to create the cross-realm TGT principal objects,
krbtgt/DOM.A@DOM.B. What should be used instead to make sure that
setkeytab can safely be disabled?

bye,
Sumit

> 
> 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)
> 
> 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] Add option to disable setkeytab extended operations

[Rob Crittenden]

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

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

[Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Simo Sorce]

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)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 46120a5a4a3032f93c9c05a6e6e82dba0d64cdfc Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Tue, 24 Nov 2015 13:42:10 -0500
Subject: [PATCH] Introduce option to disable the SetKeytab exop

If DisableSetKeyta is set in ipa Config options then setkeytab will not be
available. The default is still to allow this operation for backwards
compatibility towards older clients that do not know how to use the new
GetKeytab extended operation.

Signed-off-by: Simo Sorce 

Ticket: https://fedorahosted.org/freeipa/ticket/5485
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c| 4 
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 5 +
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h| 1 +
 3 files changed, 10 insertions(+)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
index 5dc606d22305cf63a16feca30aab2728bb20b80d..f79c0b4a6652773807a6bad388a5a857ab321755 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
@@ -232,6 +232,7 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void)
 
 /* get the ipa etc/ipaConfig entry */
 config->allow_nt_hash = false;
+config->disable_setkeytab = false;
 ret = ipapwd_getEntry(ipa_etc_config_dn, _entry, NULL);
 if (ret != LDAP_SUCCESS) {
 LOG_FATAL("No config Entry?\n");
@@ -243,6 +244,9 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void)
 if (strcasecmp(tmparray[i], "AllowNThash") == 0) {
 config->allow_nt_hash = true;
 continue;
+} else if (strcasecmp(tmparray[i], "DisableSetKeytab") == 0) {
+config->disable_setkeytab = true;
+continue;
 }
 }
 if (tmparray) slapi_ch_array_free(tmparray);
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index dc657cc4ebff987cde9d9ab07704ba171d650194..aa45ed3e79ca3d488fd4f3aac6c16370e98e3ed6 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -1742,6 +1742,11 @@ static int ipapwd_extop(Slapi_PBlock *pb)
 		return ret;
 	}
 	if (strcasecmp(oid, KEYTAB_SET_OID) == 0) {
+if (krbcfg->disable_setkeytab) {
+errMesg = "Operation administratively disabled.\n";
+rc = LDAP_UNWILLING_TO_PERFORM;
+goto free_and_return;
+}
 		ret = ipapwd_setkeytab(pb, krbcfg);
 		free_ipapwd_krbcfg();
 		return ret;
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h
index 2e9d4fe86b34c64731728882db7c81e3871d7d07..a6a85d78d1fc76715dd20715424fc4cab98fd426 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h
@@ -109,6 +109,7 @@ struct ipapwd_krbcfg {
 char **passsync_mgrs;
 int num_passsync_mgrs;
 bool allow_nt_hash;
+bool disable_setkeytab;
 };
 
 int ipapwd_entry_checks(Slapi_PBlock *pb, struct slapi_entry *e,
-- 
2.5.0

From 3ea3751e2429523518ab1b7705a65b8d989ec66c Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Tue, 24 Nov 2015 14:02:01 -0500
Subject: [PATCH] Disable User's ability to use the setkeytab exop.

User's can still obtain a keytab for themselves using the getkeytab exop
which does not circumvent passwod policy checks.

Users are disabled by default in new installations but not in existing
installations (no forced upgrade).

Signed-off-by: Simo Sorce 

Ticket: https://fedorahosted.org/freeipa/ticket/5485
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c   |  4 
 .../ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c| 18 +-
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h   |  1 +
 install/share/bootstrap-template.ldif  |  1 +
 4 files changed, 23 insertions(+), 1 deletion(-)

diff 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Simo Sorce]

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 ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 417f423d6f0786f3bb7a5284577548cdf117f6e2 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Tue, 24 Nov 2015 13:42:10 -0500
Subject: [PATCH 1/3] Introduce option to disable the SetKeytab exop

If DisableSetKeytab is set in ipaConfig options then setkeytab will not be
available. The default is still to allow this operation for backwards
compatibility towards older clients that do not know how to use the new
GetKeytab extended operation.

Signed-off-by: Simo Sorce 

Ticket: https://fedorahosted.org/freeipa/ticket/5485
---
 API.txt | 2 +-
 daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c| 4 
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 5 +
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h| 1 +
 ipalib/plugins/config.py| 1 +
 5 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/API.txt b/API.txt
index 0976c97213775d79da43ee382a0badbe029b7960..763ec12413fc1267b2cf7f519cf8c9bc14360c8c 100644
--- a/API.txt
+++ b/API.txt
@@ -766,7 +766,7 @@ args: 0,25,3
 option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('delattr*', cli_name='delattr', exclude='webui')
-option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout'))
+option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'DisableSetKeytab', u'KDC:Disable Last Success', u'KDC:Disable Lockout'))
 option: Str('ipadefaultemaildomain', attribute=True, autofill=False, cli_name='emaildomain', multivalue=False, required=False)
 option: Str('ipadefaultloginshell', attribute=True, autofill=False, cli_name='defaultshell', multivalue=False, required=False)
 option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name='defaultgroup', multivalue=False, required=False)
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
index 5dc606d22305cf63a16feca30aab2728bb20b80d..f79c0b4a6652773807a6bad388a5a857ab321755 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
@@ -232,6 +232,7 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void)
 
 /* get the ipa etc/ipaConfig entry */
 config->allow_nt_hash = false;
+config->disable_setkeytab = false;
 ret = ipapwd_getEntry(ipa_etc_config_dn, _entry, NULL);
 if (ret != LDAP_SUCCESS) {
 LOG_FATAL("No config Entry?\n");
@@ -243,6 +244,9 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void)
 if (strcasecmp(tmparray[i], "AllowNThash") == 0) {
 config->allow_nt_hash = true;
 continue;
+} else if (strcasecmp(tmparray[i], "DisableSetKeytab") == 0) {
+config->disable_setkeytab = true;
+continue;
 }
 }
 if (tmparray) slapi_ch_array_free(tmparray);
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index dc657cc4ebff987cde9d9ab07704ba171d650194..aa45ed3e79ca3d488fd4f3aac6c16370e98e3ed6 100644
--- 

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Simo Sorce]

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.

Simo.

> 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


-- 
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] Add option to disable setkeytab extended operations

[Jan Cholasta]

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.


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