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

-- 
/ Alexander Bokovoy