[Freeipa-devel] FreeIPA integration with external DNS services

[Petr Spacek]

On 10.12.2014 15:50, Martin Kosek wrote:
> On 12/10/2014 03:13 PM, Petr Spacek wrote:
>> On 9.12.2014 13:40, Martin Kosek wrote:
>>> On 12/03/2014 05:04 PM, Petr Spacek wrote:
>>>> On 2.12.2014 17:21, Simo Sorce wrote:
>>>>> On Tue, 02 Dec 2014 15:56:28 +0100
>>>>> Petr Spacek <pspacek at redhat.com> wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Yes the more I think of it, the more I prefer to wait in trying to
>>>>> solve the clients problem.
>>>>>
>>>>>>> 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.
>>>>>
>>>>> Yes, this has been accounted for.
>>>>>  
>>>>>>> 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?
>>>>>
>>>>> I wouldn't say a definite no, but I am not confident we can.
>>>>>
>>>>>> 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.)
>>>>>
>>>>> Yes I think it would be fine as a first step.
>>>>
>>>> Okay, I tried to summarize current goals on:
>>>> http://www.freeipa.org/page/V4/External_DNS_integration_with_installer
>>>>
>>>> At the moment I see a first obstacle:
>>>> $ ipa-replica-manage can authenticate to LDAP servers using:
>>>> - LDAPI (when running as root)
>>>> - GSSAPI
>>>> - DM password
>>>>
>>>> The problem is that we would need to have access to TSIG keys even when using
>>>> GSSAPI and DM password authentication ... so we again need the authorization
>>>> daemon.
>>>>
>>>>
>>>> Alternatively we can use Vault for TSIG key storage and use Vault's capability
>>>> to share keys among many users. In that case we don't have problem with key
>>>> distribution nor authorization.
>>>
>>> I am not convinced we should grow Vault dependency for this functionality, it
>>> requires the whole PKI machinery to be available. Many deployments do not use
>>> it though.
>>>
>>>> Another possibility is to say that replica-deletion can be done only by root
>>>> user or that updates to external DNS are supported only when running
>>>> ipa-replica-manage as root.
>>>
>>> Why does root help? So that TSIG keys will be available on all IPA servers,
>>> regardless whether they have DNS service running or not?
>> The point is that we need to store TSIG keys "somewhere" to make them
>> available to ipa* scripts on all replica but at the same not to human-users.
>>
>> BTW there don't need to be any 'DNS service' if only external DNS integration
>> is in use.
>>
>>> It would be better to have the TSIG keys available using standard FreeIPA RBAC
>>> roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I
>>> missing anything?
>>
>> Ideologically - no, it sounds fine.
>> Technically - the problem is in implementation. We need a mechanism for secure
>> key distribution *among users*, i.e. Vault-like functionality. I would rather
>> not re-implement Vault just for external DNS.
>>
>> I think that external DNS could depend on Vault (assuming that external DNS
>> support will be purely optional).
>>
>> DNSSEC key distribution is very different because it distributes keys to
>> *servers* and there is no ACI mechanism on top of that - all DNS servers need
>> to know all the keys anyway.
> 
> So IIUC, the goal would be to put TSIG keys in the Vault and then make them
> available for all IPA servers?
> 
> I am now not sure if the Vault as proposed can easily select a group of
> principals to allow reading the Vault or if it is only confined for the
> owner/user principal. We would need to ask Endi (CCed).

I assumed that very first sentence of
http://www.freeipa.org/page/V4/Password_Vault_Implementation#Vault
"Vault is a secure place to store data or a collection of secrets. A vault may
be privately owned by a user, or shared among users, groups, or services."
is correct :-)

Endi, we would like to have one secret which is shared among services & users
at the same time. Is it possible to do that with Vault?

-- 
Petr^2 Spacek