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