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

Thu Jun 19 11:33:36 UTC 2014

On Thu, 19 Jun 2014, Petr Spacek wrote:
>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.
I think it is better to extend the logic in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user()
to further process multiple returned entries, selecting those that are
Kerberos principals (object class can be defined similar to existing
ldapi attributes in cn=config) and then pick up the one that corresponds
to the host 389-ds is running on. If there are still multiple of them,
only then reject the bind.

-- 
/ Alexander Bokovoy