On 04/27/2017 04:16 PM, Simo Sorce wrote: > On Thu, 2017-04-27 at 15:56 +0200, Petr Vobornik wrote: >> On 04/27/2017 02:19 PM, Christian Heimes wrote: >>> On 2017-04-27 14:00, Martin Bašti wrote: >>>> I would like to discuss consequences of adding kdc URI records: >>>> >>>> 1. basically all ipa clients enrolled using autodiscovery will >>>> use >>>> kdcproxy instead of KDC on port 88, because URI takes precedence >>>> over >>>> SRV in KRB5 client implementation. Are we ok with such a big >>>> change? >>> >>> Does the client also prefer KKDCP if you give the Kerberos 88/UDP >>> and >>> 88/TCP URIs a higher priority than the KKDCP HTTPS URIs? >>> >>>> 2. probably client installer must be updated because currently >>>> with >>>> CA-full installation it is not working. >>>> >>>> ipa-client-install (with autodiscovery) failed on kinit, see >>>> KRB5_TRACE >>>> bellow that it refuses self signed certificate >>> >>> Actually it is not a self-sigend EE certificate. The validation >>> message >>> is bogus because FreeIPA TLS configuration is slightly buggy. We >>> send >>> the trust anchor (root CA) although a server should not include its >>> trust anchor in its ServerHello message. OpenSSL detects an >>> untrusted >>> root CA in the ServerHello peer chain and emits the message. >>> >>> If I read the 600 lines (!) function >>> ipaclient.install.client._install >>> correctly, then ipa-client-install first attempts to negotiate a >>> TGT and >>> then installs the trust anchor in the global trust store. It should >>> be >>> enough to reverse the order and inject the trust anchor first. >>> >>> Christian >>> >> >> By reading this, even if we do the change in client install, I'd >> rather >> not generate the DNS records in 4.5.1 release and rather make sure >> that >> everything works during 4.6 development.
I agree. My original assumption why I suggested this RFE was that it would be very contained change and only used only by clients that do not have classic Kerberos ports available. Given how much it influences rest of the framework, we indeed should not push on it in a bugfix release. >> The reason is that there might also be something else not working and >> it >> is better to time test it + the fix would not fix older clients. >> >> If anybody wants to use/try it, then the records can be created >> manually. > > > > We need to ix clients regardless, o someone enabling it will find the > same issues. Right. Can someone please file the ticket so that it can be triaged later? Thanks, Martin -- 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
