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

[Simo Sorce]

On Thu, 2014-06-19 at 15:41 +0200, Petr Spacek wrote:
> On 19.6.2014 15:36, 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 ??
> As I said earlier in the thread, we need DNS/<hostname> principal for DNS 
> updates with GSS-TSIG.

I know this, I am not proposing to remove the keytab, but that's a
different thing.

> > we can have a sysaccount called named, like we did for kerberos before
> > we had the ipa-kdb driver.
> I would prefer to have only one account for named daemon...

Right, which is why we should have one entry in sysaccounts for named.
The main issue is if we ever end up with 2 masters having different
uid/gid assigned to the named user in /etc/passwd ...

Simo.

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