#3533 [RFE] use URI records from DNS for Kerberos/IPA discovery
Closed: cloned-to-github 3 years ago by pbrezina. Opened 6 years ago by jh23453.

I'm running FreeIPA for my internal net with SRV-discovery for my
Kerberos servers. For the road warrior setup I provide a KDC-Proxy at
my external host. Kerberos/LDAP ports are not accessible from the outside.
The client is running Ubuntu 17.10 and enrolled into the IPA domain.
sssd release is 1.15.2-1ubuntu3.

The following snipplet in my /etc/krb5.conf works:

[libdefaults]
  default_realm = EXAMPLE.ORG
  dns_lookup_realm = true
  dns_lookup_kdc = false
...
[realms]
  EXAMPLE.ORG = {
    kdc = https://kdcproxy.example.org/KdcProxy

This means that the laptop handles all authentication access through
our exposed host - which I don't really like. And we need to decide
upfront if that system is used by a road warrior.

Since FreeIPA 4.5 we have support for URI records, so I've added a
record to my external DNS, but no SRV records:

_kerberos.example.org.   6835    IN      URI     100 1 "krb5srv:m:kkdcp:https://kdcproxy.example.org/KdcProxy"

When I change /etc/krb5.conf to

[libdefaults]
  default_realm = EXAMPLE.ORG
  dns_lookup_realm = true
  dns_lookup_kdc = true
...
[realms]
  EXAMPLE.ORG = {
    #kdc = https://kdcproxy.example.org/KdcProxy

I can get a kerberos ticket with kinit. So I think that up to this
point my configuration works and looks correct. And I hoped to get
authentication working inside and outside of my local net with the
same configuration.

Next try was to authenticate with sssd from gdm. The first
configuration works fine and asks for First and Second Factor for my
OTP enabled user. The second configuration only asks for my password
and accepts only that[1]. So my guess is that sssd is going offline
and authenticates me with my cached password. After logging in I
(rightly) don't have a kerberos ticket, but can get one with kinit.

When looking at the sssd source I think that SRV discovery is
implemented, but no support for URI discovery. Do you think that
should be implemented? I did not find a ticket for that.

[1] My user in IPA has password and radius authentication enabled. The
password works only for LDAP binds, kerberos tickets need password+OTP
via radius.


Hi @rharwood, do you have some suggestion here? Should a client like SSSD also honor the URI records?

@jh23453 do you have some debug logs to share, please?

Well, my general feeling is that if krb5 supports discovery in a certain way, the SSSD probably also should (unless there's some reason not to). It's pretty confusing to the user when it doesn't, if nothing else.

It is a more generic issue with the locator plugin API in krb5. While both internal locator plugins knows how to handle https-based URLs in a profile and DNS URI RR correspondingly, external locator plugins cannot supply information about uri path and port the same way.

See module_callback() in locate_kdc.c -- it uses add_addr_to_list() to add an address returned by an external locator plugin while internal plugins use add_host_to_list().

SSSD locator plugin, in its turn, only supports reading address:port lists from the file generated by SSSD. As result, we need:

  • extend krb5 locator plugin API to allow returning information about hosts, not addresses
  • extend sssd to write down DNS URI RR details into a locator plugin cache file
  • extend sssd locator plugin to use extended API to provide the information written in the previous section

Thanks abbra. Would it be useful to sssd if we extended the locate plugin interface in this way? i.e., before I consider doing that work, is this something sssd wants?

@rharwood, would libkrb5 be able to find the KDC proxy URI and use it if 'dns_lookup_kdc = true'?

As an alternative SSSD can also created config snippets which contain the discovered URI. But here long running kerberized processes which only call krb5_init_context() once at startup would not see if there are any changes after startup.

@sbose KRB5 calls to k5_locate_kdc every time anything is sent to KDC. This means that locator plugins are called every time too.

@abbra, sure, but I was thinking that SSSD might just not create the information for the locator plugin for the given domain if a KDC proxy URI was detected. So the plugin will be called every time but does not return anything so that libkrb5 can figure out the KDC by other means. The question is libkrb5 would be able to figure out the KDC proxy UIR on its own and use it before trying other ways?

Yes, if any locator plugin returns 0 servers, other methods then tried. If dns lookup is enabled in krb5.conf, then first URI and then SRV records are tried.

The current order is: profile first (i.e., config files), then any modules we have loaded, and then DNS. Since this is me making a new interface in krb5, I will double check the capabilities with you before we finalize it.

Since this ticket depends on a feature of libkrb5, I'm filing it into the future releases milestone.

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Future releases (no date set yet)

6 years ago

Metadata Update from @thalman:
- Issue tagged with: Future milestone

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4559

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @pbrezina:
- Issue close_status updated to: cloned-to-github
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata