[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 <uid=admin,cn=users,cn=accounts,dc=vda,dc=li> with scope subtree
# filter: (objectclass=*)
# requesting: userPassword 
#

# admin, users, accounts, vda.li
dn: uid=admin,cn=users,cn=accounts,dc=vda,dc=li
userPassword:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
 =

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
$ ldapsearch -Y GSSAPI -e \!authzid=dn:uid=admin,cn=users,cn=accounts,dc=vda,dc=li -b uid=admin,cn=users,cn=accounts,dc=vda,dc=li userPassword
SASL/GSSAPI authentication started
SASL username: abokovoy at VDA.LI
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <uid=admin,cn=users,cn=accounts,dc=vda,dc=li> with scope subtree
# filter: (objectclass=*)
# requesting: userPassword 
#

# search result
search: 4
result: 0 Success

# numResponses: 1

As you can see, posing different authzid does not allow to get through
ACLs unless you were already a directory manager. Which means the
proxyauth control is not really useful here:

[01/Dec/2015:10:51:22 +0100] conn=12466 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[01/Dec/2015:10:51:22 +0100] conn=12466 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[01/Dec/2015:10:51:22 +0100] conn=12466 op=1 SRCH base="uid=admin,cn=users,cn=accounts,dc=vda,dc=li" scope=2 filter="(objectClass=*)" attrs="userPassword" authzid="uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li"
[01/Dec/2015:10:51:22 +0100] conn=12466 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U
[01/Dec/2015:10:51:22 +0100] conn=12466 op=2 UNBIND

and

[01/Dec/2015:10:48:44 +0100] conn=12465 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[01/Dec/2015:10:48:44 +0100] conn=12465 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[01/Dec/2015:10:48:44 +0100] conn=12465 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[01/Dec/2015:10:48:44 +0100] conn=12465 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[01/Dec/2015:10:48:44 +0100] conn=12465 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[01/Dec/2015:10:48:44 +0100] conn=12465 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=abokovoy,cn=users,cn=accounts,dc=vda,dc=li"
[01/Dec/2015:10:48:44 +0100] conn=12465 op=3 SRCH base="uid=admin,cn=users,cn=accounts,dc=vda,dc=li" scope=2 filter="(objectClass=*)" attrs="userPassword" authzid="uid=admin,cn=users,cn=accounts,dc=vda,dc=li"
[01/Dec/2015:10:48:44 +0100] conn=12465 op=3 RESULT err=0 tag=101 nentries=0 etime=0 notes=U
[01/Dec/2015:10:48:44 +0100] conn=12465 op=4 UNBIND


-- 
/ Alexander Bokovoy