On Wed, 2015-12-02 at 08:40 +0100, Petr Spacek wrote: > 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: 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
Note that the way kadmin is written, the proxy control won't help. The DAL driver layer simply have *no* knowledge of what principal connected to kadmin when kadmin makes requests, and we do not reconnect at each request anyway. We asked MIT to provide that information down to the DAL layer so we *can* try to use the proxy control already. It will take soime time though because the code paths in kadmin need to be change to allow something like that. > But now back to the original question: > Do kadmin/kpasswd support password policies? Yes, but we implement our own in the DAL driver. > If it is the case, why it works with kadmin/kpasswd and does not work with our > setkeytab? Because I was stupid when I invented setkeytab and did not think that it could be used to circumvent password policies. So I had to add a new control called getkeytab that works as needed and also adds the ability to retrieve an existing key, not just set one. So we fixed a bug and gained new functionality, we just need to deprecate the old control. Once we'll be able to have kadmin authorize properly based on DS ACLs, we can allow the use of the kadmin interface too, but that will take time. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
