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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
