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 <pspa...@redhat.com> wrote: >>>>> >>>>>> On 1.12.2014 17:12, Simo Sorce wrote: >>>>>>> On Mon, 01 Dec 2014 16:17:54 +0100 >>>>>>> Petr Spacek <pspa...@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 <pspa...@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@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@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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel