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

Reply via email to