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

[Alexander Bokovoy]

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.

>I'm very interested in implementation details & usability of it. Can we make
>this setup easier to achieve by changing ipa-client-install?
>
>Some ideas:
>- populate krb.conf only with
>[domain_realm]
>canonical hostname = IPA.EXAMPLE.COM
>
>and enable DNS auto-detection for everything else.
We already have auto-detection working. For non-SSO case
'ipa-client-install --domain=ipa.example.com' on ipa-client.example.com
will automatically configure everything. The only change is indeed by
setting 'ipa-client.example.com = IPA.EXAMPLE.COM'. For SSO case we
simply discover that AD DC is not IPA LDAP server so we refuse to
operate unless you provide manual options. 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.


>I think that:
>a) For normal setups with disjoint domains this should just work as usual.
>
>b) For setup without CNAME for IPA client it should work because example.com
>will be detected as AD domain and scenario described in the section 'No single
>sign-on required' will work.
>
>c) For setup with CNAME the user will need to add ignore_acceptor_hostname but
>krb5.conf will be configured properly.
>
>
>
>BTW why is it needed to use ignore_acceptor_hostname if there is a CNAME? MIT
>Kerberos should see the correct name as it detects CNAMEs. Does AD ignore the
>CNAME when requesting a ticket? What else?
No, it does not ignore, it resolves CNAME to A/AAAA name. However, there
are cases when people want to have both principals from IPA and AD
realms in /etc/krb5.keytab and want to support both ways to access it.

>If it is needed, can we detect the CNAME and turn on ignore_acceptor_hostname
>automatically? (This depends on security considerations section, of course.)
Exactly because it is part of the behavior defined by application
frontend considerations, we can only document it and not do automated
handling.

>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.

-- 
/ Alexander Bokovoy