On 28.04.2017 09:32, Martin Kosek wrote:
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?

ticket is here https://pagure.io/freeipa/issue/6906


Thanks,
Martin

--
Martin Bašti
Software Engineer
Red Hat Czech

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

Reply via email to