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