[Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?

[Simo Sorce]

On Thu, 2014-06-19 at 16:05 +0200, Petr Spacek wrote:
> On 19.6.2014 16:02, Simo Sorce wrote:
> > On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote:
> >> On Thu, 19 Jun 2014, Simo Sorce wrote:
> >>> On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote:
> >>>> On Thu, 19 Jun 2014, Petr Spacek wrote:
> >>>>> On 19.6.2014 11:02, Alexander Bokovoy wrote:
> >>>>>> On Thu, 19 Jun 2014, Petr Spacek wrote:
> >>>>>>> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened
> >>>>>>> question "Why do we use Kerberos for named<->DS connection? Named connects
> >>>>>>> over LDAPI to local DS instance anyway."
> >>>>>>>
> >>>>>>> Maybe we can get rid of Kerberos for this particular connection and use
> >>>>>>> autobind instead. It would make it more reliable and effective.
> >>>>>>>
> >>>>>>> As a side effect, named will be able to start even if KDC is down for some
> >>>>>>> reason. It partially solves chicken-egg problem during IPA start-up.
> >>>>>>>
> >>>>>>> I wasn't around when it bind-dyndb-ldap was designed so I don't know
> >>>>>>> historical reasons.
> >>>>>> My primary worry is the fact that any break in named/bind-dyndb-ldap
> >>>>>> could be then exploited to have access to all key material. In the case of
> >>>>>> GSSAPI you are confined to whatever ACIs allow for dns/ principal.
> >>>>> IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so
> >>>>> I don't see any difference from using SASL/GSSAPI/Kerberos.
> >>>> My impression was that you wanted autobind to Directory Manager (root
> >>>> autobind), this is what I don't want to support, for sure.
> >>>>
> >>>>>> Samba case goes further -- I specifically added GSSAPI bind to Samba
> >>>>>> code LDAP code to allow splitting DCs and file servers while being able
> >>>>>> to use the same ipasam module securely, in addition to the usual
> >>>>>> ACI limitations.
> >>>>> Named has only one function (i.e. DNS server with support for DNS
> >>>>> updates). I don't think that there is meaningful separation.
> >>>>>
> >>>>>> For named what we could do is to have named+ldapi:// access mapped to
> >>>>>> specific DN uidNumber=<named>+gidNumbe=<named>,cn=peercred,cn=external,cn=auth
> >>>>> This is OpenLDAP-ism, right?
> >>>> yes, this is what the client code reports. 389-ds server sees proper dn:
> >>>>
> >>>> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \
> >>>>    --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \
> >>>>    --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \
> >>>>    --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \
> >>>>    --setattr=uid=named
> >>>> -----------------------------------------------
> >>>> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI"
> >>>> -----------------------------------------------
> >>>>    Principal: DNS/ipa-01.t.vda.li at T.VDA.LI
> >>>>    Managed by: ipa-01.t.vda.li
> >>>>
> >>>> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config '
> >>>> SASL/EXTERNAL authentication started
> >>>> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth
> >>>> SASL SSF: 0
> >>>> # extended LDIF
> >>>> #
> >>>> # LDAPv3
> >>>> # base <dc=t,dc=vda,dc=li> (default) with scope subtree
> >>>> # filter: cn=config
> >>>> # requesting: ALL
> >>>> #
> >>>>
> >>>> # search result
> >>>> search: 2
> >>>> result: 0 Success
> >>>>
> >>>> # numResponses: 1
> >>>>
> >>>> and here is what we see in the logs:
> >>>> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li"
> >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL
> >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li"
> >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL
> >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0
> >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND
> >>>>
> >>>>
> >>>>>
> >>>>>>    dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX
> >>>>> This object already exists for every single DNS server, which is
> >>>>> exactly the problem. Multiple servers are running under the same
> >>>>> UID/GID pair on Fedora.
> >>>> No, it is not a problem because there are multiple objects, one per
> >>>> server.
> >>>>
> >>>>>> There is an issue of uid/gid being different on different platforms,
> >>>>>> though but it is doable.
> >>>>> I can see the problem with UID/GID mapping to multiple different
> >>>>> principals. We can't remove these principals because they are used on
> >>>>> server side for DNS updates.
> >>>>>
> >>>>> Maybe we can create autobind mapping objects in some non-replicated
> >>>>> part of the tree. That would solve the problem with different UID/GIDs
> >>>>> on different platforms and also mapping UID/GID mapping to multiple
> >>>>> principals because one replica would see only one mapping object for
> >>>>> given UID/GID.
> >>>> No, I don't think we ever need to modify anything here apart from giving
> >>>> posixgroup/posixaccount object classes to the DNS principal per server
> >>>> and setting their properties.
> >>>>
> >>>> As you can see above, it simply works. I actually tested it with named
> >>>> too, by setting
> >>>>
> >>>> diff -up /etc/named.conf.old /etc/named.conf
> >>>> --- /etc/named.conf.old	2014-06-19 14:10:40.725934702 +0300
> >>>> +++ /etc/named.conf	2014-06-19 14:10:58.432601624 +0300
> >>>> @@ -45,7 +45,7 @@ dynamic-db "ipa" {
> >>>>   	arg "base cn=dns, dc=t,dc=vda,dc=li";
> >>>>   	arg "fake_mname ipa-01.t.vda.li.";
> >>>>   	arg "auth_method sasl";
> >>>> -	arg "sasl_mech GSSAPI";
> >>>> -	arg "sasl_user DNS/ipa-01.t.vda.li";
> >>>> +	arg "sasl_mech EXTERNAL";
> >>>> +	arg "sasl_user named";
> >>>>   	arg "serial_autoincrement yes";
> >>>>   };
> >>>>
> >>>> and named successfully started, with 389-ds showing autobind to the same
> >>>> krprincipalname=dns/... in the logs.
> >>>
> >>> why do we need to associate bind to dns/whatever ??
> >> Because we already have ACIs given to dns/hostname to handle DNS
> >> entries.
> >
> > Which are easy to change on upgrade.
> >
> >>> we can have a sysaccount called named, like we did for kerberos before
> >>> we had the ipa-kdb driver.
> >> A modification of DNS service with 'ipa service-mod' is all what we
> >> need for single node case, I tried it.
> >
> > I do not like it at all, plus each server has a different object and
> > they would all be duplicates. I prefer very much a single, passwordless
> > special user in sysconfig, added to the same group that control access
> > for the DNS tree.
> 
> We need to have the DNS principal for every replica anyway - for DNS updates. 
> There is no way how to get rid of it without changes in GSS-TSIG protocol.

They serve 2 completely different purposes, there is no reason to tie
LDAP access to one principal just because it is available to you to get
keys for GSS-TSIG.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York