[Freeipa-devel] KDC proxy URI records

[Martin Bašti]

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