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

[Petr Spacek]

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.


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

Sorry for not being clear. I did not mean auto-detection of domain, this
surely needs to be handled by --domain option.

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.


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


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

Okay, understood.


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

-- 
Petr^2 Spacek