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: aboko...@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

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

Reply via email to