[Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Alexander Bokovoy]

On Mon, 23 May 2016, Petr Spacek wrote:
>On 20.5.2016 12:43, Alexander Bokovoy wrote:
>> On Fri, 20 May 2016, Petr Spacek wrote:
>>> Theory I have seen looks good to me but Security considerations section is
>>> missing. The design must spell out what are security implications of
>>>  ignore_acceptor_hostname = true
>>>  GSSAPIStrictAcceptorCheck no
>> I'll add security considerations, thanks for noticing that.
>>
>>> All of the implementation details are missing so this review cannot be
>>> considered complete.
>> There is nothing to implement here on our side. We discussed it with
>> Martin K. and he suggested that we might add a link to documentation
>> when it would be written but that's as much as we can do.
>>
>> Thing is, a proper implementation means changes to be done way above
>> ipa-client-install level, even way above FreeIPA deployment itself,
>> especially for SSO case where a CNAME would need to be created in a
>> separate DNS zone that is not under control of FreeIPA. So all we can do
>> is to suggest something rather than implement. We do that already and
>> Mark is going to turn the design into a section in the Windows
>> Integration Guide.
>
>Let me clarify that. I did not mean that ipa-client-install should *create*
>CNAME records. I was thinking more about tailored installation process which
>can be automatically enabled when CNAME is detected during installation.
If CNAME is detected, we can do some magic, right. But would it help?
Two things matter here:
 - if `hostname` is a CNAME, we need to register real hostname
 - also create host object for CNAME record and make sure realm hostname
   is used to manage it

Question is what to do if hostname was forced via command line option
and it is different from the CNAME which is `hostname`. In current code
we ignore `hostname` and force the hostname via /etc/hosts to whatever
was specified on the command line.

>
>I was thinking about detection of CNAME which could trigger addition of
>ipa-client.example.com = IPA.EXAMPLE.COM
>to krb5.conf.
>
>Or, alternatively, why can't we add ipa-client.example.com = IPA.EXAMPLE.COM
>to krb5.conf unconditionally? I do not see any harm in doing so.
That sounds better. May be you can file a ticket for this one? It
doesn't need to be tied to the discussed proposal although you can
certainly mention it.


>> However, it is impossible to
>> do anything here automatically because the actual behavior would depend
>> on external conditions which we cannot control.
>>
>> This is really something that has to be written in the planning guide.
>> For example, if you have SSO case and want to put A/AAAA record and
>> CNAME record, it is not a given fact that both of them have to be named
>> in the same way. In fact, they most likely will be different as CNAME
>> record is part of user-facing application namespace and A/AAAA records
>> in IPA DNS zone are part of a backend naming. There is no
>> standardization here.
>
>Sure. I was thinking about special handling for case where ipa-client-install
>is ran with parameters "--domain=ipa --hostname=cname". It could modify
>krb5.conf and possibly print hint about ignore_acceptor_hostname or just a
>link to docs "it seems that you should read <this>".
Well, we don't have the documentation for it yet, only upstream wiki.
May be we should add instead a section to ipa-client-install manual page
and reference it?



>
>>> Speaking of certs, should we introduce a aliases for host entries to avoid the
>>> need of fake hosts?
>> These 'fake hosts' are as good as aliases, even better, because they
>> allow us to have full control over who can manage them.
>
>I do not see how this is different from any other object which has managedBy
>attribute. It is not a special property of host.
We have managedBy handling in hosts and services specifically to allow
certificate issuing on behalf of another entity.

-- 
/ Alexander Bokovoy