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...@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...@t.vda.li"
-----------------------------------------------
Principal: DNS/ipa-01.t.vda...@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...@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...@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...@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.
