[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 <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
>>
> Ludwig confirmed that ACL plugin short-circuits DM access before
> proxy auth checked. I've filed a bug about it:
> https://fedorahosted.org/389/ticket/48366

I just tested a new DS version from
https://copr.fedoraproject.org/coprs/lkrispen/389-ds-current/build/146702/
and it works! Nice!

-- 
Petr^2 Spacek