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

[Petr Spacek]

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.

> 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?

> achieving essentially the same thing, if we would use
>    dn: cn=config
>    nsslapd-ldapimaptoentries: on
>    nsslapd-ldapiuidnumbertype: uidNumber
>    nsslapd-ldapigidnumbertype: gidNumber
>    nsslapd-ldapientrysearchbase: cn=accounts,$SUFFIX
This is part of default IPA installation.

> and
>
>    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.

>    uidNumber: <uid for named>
>    gidNumber: <gid for named>
>
> and then define ACIs equal to what we have for DNS service now.
ACIs are already in place and associated with the principals mentioned above.

> 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.

It would be even better if DS could do something like:

dn: uidNumber=<uid>+gidNumber=<gid>, cn=autobind, cn=config
uidNumber: <uid>
gidNumber: <gid>
autobindDN: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX

I.e. add one layer of indirection to autobind evaluation. That would allow us 
to have autobind object in non-replicated part of the tree and at the same 
time centralize ACIs under one DN (i.e. principal) in replicated part of the tree.

I guess that it would require DS modification...

-- 
Petr^2 Spacek