[Freeipa-devel] KDC proxy URI records

Post by Martin BaÅ¡ti
Hello all,
I'm going to implement automatic URI records for kdc proxy and I'd
like to clarify if following URI records are the right one.
_kerberos-adm.example.com. IN URI <prio> 0
"krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy"
_krb5kdc.example.com. IN URI <prio> 0
"krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy"
_kpasswd.example.com. IN URI <prio> 0
"krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy"
I assume we want to use "kkdcp" and "https", and "M" flag as all IPA
servers are masters, please confirm.
https://k5wiki.kerberos.org/wiki/Projects/KDC_Discovery
https://tools.ietf.org/id/draft-mccallum-kitten-krb-service-discovery-02.txt
Thank you

I found out that wiki page differs from the RFC draft and from the
source in git

There is "_kerberos.REALM" record instead of "_krb5kdc.REALM"

And I'm not sure if _kerberos-adm should be included as we don't really
support kadmin.

Simo Sorce

2017-04-26 18:41:47 UTC

I found out that wiki page differs from the RFC draft and from the
source in git
There is "_kerberos.REALM" record instead of "_krb5kdc.REALM"
And I'm not sure if _kerberos-adm should be included as we don't really
support kadmin.

We shouldn't.

Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

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

Martin Bašti

2017-04-27 12:00:35 UTC

I found out that wiki page differs from the RFC draft and from the
source in git
There is "_kerberos.REALM" record instead of "_krb5kdc.REALM"
And I'm not sure if _kerberos-adm should be included as we don't really
support kadmin.

We shouldn't.
Simo.

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?

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

....
Realm: IPA.TEST
DNS Domain: ipa.test
IPA Server: master.ipa.test
BaseDN: dc=ipa,dc=test

Continue to configure the system with these values? [no]: y
Skipping synchronizing time with NTP server.
User authorized to enroll computers: admin
Password for ***@IPA.TEST:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=IPA.TEST
Issuer: CN=Certificate Authority,O=IPA.TEST
Valid From: 2017-04-27 11:02:28
Valid Until: 2037-04-27 11:02:28

Enrolled in IPA realm IPA.TEST
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm IPA.TEST
trying https://master.ipa.test/ipa/json
Forwarding 'schema' to json server 'https://master.ipa.test/ipa/json'
Major (851968): Unspecified GSS failure. Minor code may provide more
information, Minor (2529639068): Cannot contact any KDC for realm 'IPA.TEST'
The ipa-client-install command failed. See
/var/log/ipaclient-install.log for more information

[***@client1 ~]# KRB5_TRACE=/dev/stderr kinit admin
[25690] 1493293387.746616: Getting initial credentials for ***@IPA.TEST
[25690] 1493293387.750307: Sending request (164 bytes) to IPA.TEST
[25690] 1493293387.751468: Resolving hostname master.ipa.test
[25690] 1493293387.765261: TLS certificate error at 1 (O=IPA.TEST,
CN=Certificate Authority): 19 (self signed certificate in certificate chain)
[25690] 1493293387.765680: TLS error: error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed
[25690] 1493293387.765807: HTTPS error sending to https 192.168.138.101:443
[25690] 1493293387.766873: Terminating TCP connection to https
192.168.138.101:443
kinit: Cannot contact any KDC for realm 'IPA.TEST' while getting initial
credentials

IMHO we have to update krb5.conf or add IPA CA cert to trusted
certificates, I'm afraid that URI records may break already installed
clients (when updated to krb5-workstation), I have to test it.

Christian Heimes

2017-04-27 12:19:03 UTC

Post by Martin BaÅ¡ti
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?

Post by Martin BaÅ¡ti
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

--
Christian Heimes
Senior Software Engineer, Identity Management and Platform Security

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander

Petr Vobornik

2017-04-27 13:56:40 UTC

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?

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.

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.

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

Simo Sorce

2017-04-27 14:16:23 UTC

Post by Petr Vobornik

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?

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

Simo.

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://w

Martin Kosek

2017-04-28 07:32:20 UTC

Post by Petr Vobornik

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?

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.

Post by Petr Vobornik
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

Martin Bašti

2017-04-28 07:34:25 UTC

Post by Martin Kosek

Post by Petr Vobornik

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?

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.

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

Post by Martin Kosek
Thanks,
Martin

Martin Bašti

2017-04-27 14:16:07 UTC

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?

It should use 88/TCP, 88/UDP then, it can be a way how to avoid issues
with clients.

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.

Most likely, I haven't checked deeper

Post by Christian Heimes
Christian

Christian Heimes

2017-04-27 15:12:25 UTC

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?

It should use 88/TCP, 88/UDP then, it can be a way how to avoid issues
with clients.

Small correction: Kerberos should prefer UDP over TCP.

Christian

Christian Heimes

2017-04-28 08:34:27 UTC