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

[Alexander Bokovoy]

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.
-- 
/ Alexander Bokovoy