On Mon, 01 Dec 2014, 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?
Trust is not possible to establish without proper DNS records in place.
At least, verification step will fail because for it to be successful,
AD DC must contact IPA domain controllers which it searches via SRV
records -- we can't influence that.

Additionally, there are no AD admin credentials available when we create
DNS records in ipa-adtrust-install because it is an operation done by
IPA admin. At this stage we don't really need these DNS records for IPA
side yet.

When IPA - AD trust is established with 'ipa trust-add' in one use case
we have both IPA admin and AD forest root domain's admin credentials,
thus we theoretically can create DNS records in AD as part of the
process, essentially making it two-step:
1. Discover IPA DCs via SRV records and if that fails, propose AD admin
to create the records -- either via confirmation or by providing a
separate command (e.g. 'ipa trust-init-dnsconfig').
2. Establish trust to AD and verify it.

It will not be working for the case we are creating a trust with a
shared secret because we'd have no AD admin credentials at all.

/ Alexander Bokovoy

Freeipa-devel mailing list

Reply via email to