[Freeipa-devel] FreeIPA integration with external DNS services

Tue Dec 2 14:56:28 UTC 2014

On 1.12.2014 17:12, Simo Sorce wrote:
> On Mon, 01 Dec 2014 16:17:54 +0100
> Petr Spacek <pspacek at redhat.com> wrote:
> 
>> On 14.11.2014 17:31, Petr Spacek wrote:
>>> On 14.11.2014 02:22, Simo Sorce wrote:
>>>> On Tue, 11 Nov 2014 16:29:51 +0100
>>>> Petr Spacek <pspacek at redhat.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> this thread is about RFE
>>>>> "IPA servers when installed should register themselves in the
>>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424
>>>>>
>>>>> It is not a complete design, just a raw idea.
>>>>>
>>>>>
>>>>> Use case
>>>>> ========
>>>>> FreeIPA installation to a network with existing DNS
>>>>> infrastructure + network administrator who is not willing to
>>>>> add/maintain new DNS servers "just for FreeIPA".
>>>>>
>>>>>
>>>>> High-level idea
>>>>> ===============
>>>>> - Transform dns* commands from FreeIPA framework to equivalent
>>>>> "nsupdate" commands and send DNS updates to existing DNS servers.
>>>>> - Provide necessary encryption/signing keys to nsupdate.
>>>>>
>>>>>
>>>>> 1) Integration to FreeIPA framework
>>>>> ===================================
>>>>> First of all, we need to decide if "external DNS integration" can
>>>>> be used at the same time with FreeIPA-integrated DNS or not.
>>>>> Side-question is what to do if a first server is installed with
>>>>> external-DNS but another replica is being installed with
>>>>> integrated-DNS and so on.
>>>>
>>>> I think being able to integrate with an external DNS is important,
>>>> and not just at the server level, being able to distribute TSIG
>>>> keys to client would be nice too, though a lot less important,
>>>> than getting server integration..
>>>
>>> Using TSIG on many clients is very problematic. Keep in mind that
>>> TSIG is basically HMAC computed using symmetric key so:
>>> a) Every client would have to use the same key - this is a security
>>> nightmare. b) We would have to distribute and maintain many keys
>>> for many^2 clients, which is an administrative nightmare.
>>>
>>> For *clients* I would rather stay with GSS-TSIG which is much more
>>> manageable because we can use Kerberos trust and Keytab
>>> distribution is already solved by ipa-client-install.
>>>
>>> Alternative for clients would be to use FreeIPA server as proxy
>>> which encapsulates TSIG keys and issues update requests on behalf
>>> of clients. This would be FreeIPA-specific but any
>>> TSIG-distribution mechanism will be FreeIPA-specific anyway.
>>>
>>> TSIG standard explicitly says that there is no standardized
>>> distribution mechanism.
>>>
>>>>> In other words, the question is if current "dns.py" plugin shipped
>>>>> with FreeIPA framework should be:
>>>>>
>>>>> a) Extended dns.py with dnsexternal-* commands
>>>>> ----------------------------------------------
>>>>> Disadvantages:
>>>>> - It complicate FreeIPA DNS interface which is a complex beast
>>>>> even now.
>>>>> - We would have add condition to every DNS API call in installers
>>>>> which would increase horribleness of the installer code even more
>>>>> (or add another layer of abstraction...).
>>>>
>>>> I agree having a special command is undesirable.
>>>>>
>>>>> - I don't see a point in using integrated-DNS with external-DNS at
>>>>> the same time. To use integrated-DNS you have to get a proper DNS
>>>>> delegation from parent domain - and if you can get the delegation
>>>>> then there is no point in using external DNS ...
>>>>
>>>> I disagree on this point, it makes a lot of sense to have some
>>>> zones maintained by IPA and ... some not.
>>>>
>>>>> Advantages:
>>>>> - You can use external & integrated DNS at the same time.
>>>>
>>>> We can achieve the same w/o a new ipa level command.
>>>
>>> This needs to be decided by FreeIPA framework experts ...
>>>
>>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This
>>> proxy would provide all ipa dns* commands and dispatch user-issued
>>> commands to appropriate FreeIPA-plugin (internal-dns or
>>> external-dns). This decision could depend on some values in LDAP.
>>>
>>>>> b) Replace dns.py with another implementation of current
>>>>> dnszone-* & dnsrecord-* API.
>>>>> ---------------------------------------------------------------------
>>>>> This seems like a cleaner approach to me. It could be shipped as
>>>>> ipa-server-dns-external package (opposed to "standard"
>>>>> ipa-server-dns package).
>>>>>
>>>>> Advantages:
>>>>> - It could seamlessly work with FreeIPA client installer because
>>>>> the dns*->nsupdate command transformation would be done on
>>>>> FreeIPA server and client doesn't need to know about it.
>>>>> - Does not require re-training/not much new documentation because
>>>>> commands are the same.
>>>>>
>>>>> Disadvantages:
>>>>> - You can't use integrated & external DNS at the same time (but I
>>>>> don't think it justifies the added complexity).
>>>>
>>>> I disagree.
>>>>
>>>> One of the reason to use a mix is to allow smooth migrations where
>>>> zones are moved into (or out of) IPA one by one.
>>>
>>> Good point, I agree. I will focus on supporting both (internal and
>>> external) DNS at the same time.
>>>
>>>>> Petr^3 or anyone else, what do you propose?
>>>>
>>>> I think what I'd like to see is to be able to configure a DNS zone
>>>> in LDAP and mark it external.
>>>> The zone would held the TSIG keys necessary to perform DNS updates.
>>>>
>>>> When the regular ipa dnsrecord-add etc... commands are called, the
>>>> framework detects that the zone is "external", fewttches the TSIG
>>>> key (if the user has access to it) and spawn an nsupdate command
>>>> that will perform the update against whatever DNS server is
>>>> authoritative for the zone.
>>>>
>>>> Some commands may be disabled if the zone is external and
>>>> appropriate errors would be returned.
>>>
>>> Correct, this will be inevitable.
>>>
>>>>> 2) Authentication to external DNS server/keys
>>>>> =============================================
>>>>> This is separate problem from FreeIPA framework integration.
>>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) or
>>>>> keytabs (for DNS GSS-TSIG) and distribute them somehow to
>>>>> replicas so every replica can update DNS records as necessary.
>>>>
>>>> For TSIG keys I think we should just store them in a LDAP record,
>>>> see above.
>>>
>>> Without any encryption? Am I missing something?
>>>
>>>> For keytabs we can simply store them just like any  other kerberos
>>>> key if we really need it (in a trust case for example, we may not
>>>> need a new keytab, we may be allowed to use our own credentials
>>>> through the trust. So we'll need to explore a bit how to properly
>>>> express that in configuration. REtrieval ok keytabs is then just a
>>>> matter of running ipa-getkeytab -r on the replica that needs it.
>>>>
>>>>> This will be the funny part because in case of AD trusts we have
>>>>> chicken-egg problem. You need to establish trust to get ticket for
>>>>> DNS/dc1.ad.example at AD principal but you can't (I guess) establish
>>>>> trust until proper DNS records are in place ...
>>>>
>>>> No, in this case we should create the records at trust
>>>> establishment time using the admin credentials we have been
>>>> provided. NO chicken-egg issue.
>>>
>>> Sorry, we surely *have* a chicken-egg issue because
>>> ipa-server-install is completely separate step from from
>>> ipa-adtrust-install which is completely separate from ipa
>>> trust-add. (And there is nothing which forces user to establish AD
>>> trust right after ipa-server-install finished.)
>>>
>>> Also, in some cases it is not possible to use the same credentials
>>> for trust establishment and for DNS updates on AD. Think about
>>> one-way trust or possibly two-way trust but established using
>>> pre-shared trust secret (which is AFAIK not usable for kinit).
>>>
>>> Alexander, could you clarify if it is possible to create an AD
>>> trust *without* DNS records for FreeIPA side of the trust?
>>>
>>> Another problem is that reliance on AD trusts would effectively
>>> prevent interoperability with non-AD DNS servers (think Infoblox or
>>> standard BIND).
>>>
>>> I tend to think that we will need to obtain credentials (AD
>>> login/pass/keytab/TSIG key) as one of ipa-server-install parameters
>>> so all DNS updates can be done right away. This would allow us have
>>> ipa-server-install script which in fact produces *working* FreeIPA
>>> domain. In other cases ipa-server-install would end but the FreeIPA
>>> domain would not be functional because of missing records in DNS.
>>>
>>>>> For 'experimental' phase I would go with pre-populated CCcache,
>>>>> i.e. admin will manually do kinit Administrator at AD and then run
>>>>> FreeIPA installer.
>>>>
>>>> We already to this, so there is no need to invent anything here
>>>> IMO.
>>>
>>> Except for cases mentioned above ...
>>>
>>>>> Maybe we can re-use trust secret somehow? I don't know, I will
>>>>> reach out to AD experts with questions.
>>>>>
>>>>> This area needs more research but for now it seems feasible to
>>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs
>>>>> so "only" the chicken-egg problem is left.
>>>>>
>>>>> This will need new LDAP schema but I will propose something when
>>>>> I'm done with investigation.
>>>>
>>>> Please let me know if you agree with a new zone type as a way to
>>>> "forward" updates.
>>>
>>> Generally I agree, it was my plan too. My main concern is not about
>>> LDAP structure but about FreeIPA framework and about workflow in
>>> general. It will be fun to extend the spaghetti code we have ...
>>
>> Ping :-) I would like to move the discussion forward.
>>
>> Alexander, could you please comment on authentication to AD mentioned
>> above?
>>
>> Simo and everybody else, what do you think about client use-case, i.e.
>> forwarding DNS updates from FreeIPA clients to external DNS
>> infrastructure? What about security implications (keeping in mind
>> that TSIG keys are symmetric)?
>>
>> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy
>> instead of nsupdate command (to hide TSIG key behind FreeIPA)?
> 
> Remind me this, when a client tries to update the DNS, does it always
> contact its own DNS server first, or does it try to go straight to the
> authoritative DNS server?

It should go straight to authoritative servers listed in NS records.

> I do not like the XML-RPC->DNS approach as it requires a special
> client, leaving out the majority of clients.

Yes, it is an option of last resort (because I don't see a way how to be
compatible with standard clients, see the point above).

> Also, I am thinking that we only _need_ to set infrastructure relevant
> names (like IPA servers SRV records), but if someone decides not to use
> IPA for the DNS we may decide that it is not our responsibility to
> provide a full end-to-end client dns update solution.

If we can agree on that then I'm fine with it.

> So I would concentrate on making it possible for IPA *Servers* to use a
> private TSIG key to update infrastructure relevant names, and possibly
> defer the clients side of the problem.

Speaking about native clients, two-way AD trust should nicely work with
clients because clients could go straight to the AD and authenticate using
host keytab from FreeIPA realm. It will not work in other cases but it is
still better than nothing.

> We could use an internal bus on the server to allow the ipa framework
> to use nsupdate w/o gaining direct access to the TSIG key, this way
> admins can use ipa dnsrecod-add and friends w/o exposing the key.

I agree with the idea but it depends on an authorization daemon you have
proposed earlier (in different discussion). Do you see it as reasonable goal
for FreeIPA 4.2 time-span?

If the authorization daemon is too far away, would it be okay to support
external DNS domains only for ipa* installers but do not support it for
FreeIPA users? (I.e. basically store the key in HSM which is not accessible to
users - that is what we do with DNSSEC keys now.)

-- 
Petr^2 Spacek