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

Thu Jun 19 11:26:50 UTC 2014

On 19.6.2014 13:13, 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.

Sure, this will work for single principal. Things will break if there is more 
than one object with given uidNumber and gidNumber.

See figure 13.1 on page
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/configuring-special-binds.html#autobind-enabling

That is why I proposed the 'indirection object' (under cn=config) hack.

-- 
Petr^2 Spacek