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. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
