[Freeipa-devel] FreeIPA integration with external DNS services

[Petr Spacek]

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

Ideas?

-- 
Petr^2 Spacek