Bug 1401605 - Adding Kerberos user fails for non-domain accounts
Summary: Adding Kerberos user fails for non-domain accounts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: realmd
Version: 25
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Sumit Bose
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-05 16:28 UTC by Stephen Gallagher
Modified: 2018-06-04 11:23 UTC (History)
14 users (show)

Fixed In Version: realmd-0.16.2-7.fc25 realmd-0.16.2-6.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-15 23:32:12 UTC
Type: Bug


Attachments (Terms of Use)
journal of realmd join attempt (6.75 KB, text/plain)
2016-12-05 16:28 UTC, Stephen Gallagher
no flags Details
[PATCH] Kerberos: fall back to tcp SRV lookup (3.68 KB, patch)
2016-12-06 11:50 UTC, Sumit Bose
no flags Details | Diff

Description Stephen Gallagher 2016-12-05 16:28:07 UTC
Created attachment 1228110 [details]
journal of realmd join attempt

Description of problem:
Recently, the Fedora Project started supporting Kerberos logins for Koji and other tools. They provided instructions on how to set this up for GNOME at https://fedoraproject.org/wiki/Infrastructure/Kerberos#GUI_.28gnome.2Fworkstation.29

However, these instructions do not work: the system cannot locate the FEDORAPROJECT.ORG realm and the user cannot be authenticated.


Version-Release number of selected component (if applicable):
gnome-online-accounts-3.22.1-1.fc25.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Open settings -> Online Accounts -> Click on the + to add an account -> Click on "Other" at the end of the list -> Click on "Enterprise login (kerberos)"
2. Enter FEDORAPROJECT.ORG for the domain
3. Enter your FAS name in the name field.


Actual results:
Hitting "Connect" causes the throbber to spin briefly, then a minus icon (-) appears next to the domain.

Expected results:
The user should be prompted for their Kerberos password and then a TGT granted.

Additional info:

realmd log attached

After some discussion today with the realmd maintainer and a kerberos expert, we don't think it makes sense to have gnome-online-accounts attempt to use realmd for this setup. Realmd is intended for joining a machine to a domain (such that the user can log in as a domain user), while what we are attempting to do here is simply acquire a Kerberos TGT for a single user.

Comment 1 Sumit Bose 2016-12-05 19:55:44 UTC
It looks that GOA uses realmd only to discover the domain not trying to join it. It currently fails because realmd only check the _kerberos._udp DNS SRV record bit for fedoraproject.org only _kerberos._tcp is defined because nothing is listening on the udp port.

I'll try to add a fallback to _tcp to realmd.

Comment 2 Nathaniel McCallum 2016-12-05 20:00:15 UTC
If that is the right approach, realmd should also implement URI lookups:

  https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03

However, I still have the broader question as to why it tries to discover the domain at all. It should probably just try to acquire a ticket. This eliminates a dependency on realmd. It also means that all supported means of ticket acquisition will be supported; not just those supported by realmd.

Comment 3 Sumit Bose 2016-12-06 11:50:20 UTC
Created attachment 1228434 [details]
[PATCH] Kerberos: fall back to tcp SRV lookup

Hi Stef,

can you have a look at the attached patch? fedoraproject.org does not have _kerberos._upd.fedoraproject.org defined but the matching _tcp. Moving to _tcp in general would break 'classical' Kerberos setup where only _udp is available. Hence I think it is better to add a fallback here.

Thanks for you help.

bye,
Sumit

Comment 4 Sumit Bose 2016-12-06 12:01:45 UTC
(In reply to Nathaniel McCallum from comment #2)
> If that is the right approach, realmd should also implement URI lookups:
> 
>   https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03
> 

yes, I was thinking about the same. Would you mind to open a separate ticket about it for realmd? Because besides the code needed for parsing the URI it should be discussed which lookup scheme URI or SRV is the preferred one. Maybe it would be even worth to add some guidance to the draft about this?

> However, I still have the broader question as to why it tries to discover
> the domain at all. It should probably just try to acquire a ticket. This
> eliminates a dependency on realmd. It also means that all supported means of
> ticket acquisition will be supported; not just those supported by realmd.

Comment 5 Sumit Bose 2016-12-06 12:31:12 UTC
(In reply to Sumit Bose from comment #4)
> (In reply to Nathaniel McCallum from comment #2)
> > If that is the right approach, realmd should also implement URI lookups:
> > 
> >   https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03
> > 
> 
> yes, I was thinking about the same. Would you mind to open a separate ticket
> about it for realmd? Because besides the code needed for parsing the URI it
> should be discussed which lookup scheme URI or SRV is the preferred one.
> Maybe it would be even worth to add some guidance to the draft about this?
> 

glib2 lacks URI lookup support, I opened https://bugzilla.gnome.org/show_bug.cgi?id=775703.

Comment 6 Nathaniel McCallum 2016-12-06 13:44:24 UTC
I still don't understand why adding discovery support to realmd is the right way to fix this bug. GOA should just try to get a ticket and let libkrb5 perform the discovery. GOA will need to do this anyway to support any of the advanced authentication mechanisms (OTP, SPAKE, etc.).

Comment 7 Stephen Gallagher 2016-12-13 13:35:59 UTC
(In reply to Nathaniel McCallum from comment #6)
> I still don't understand why adding discovery support to realmd is the right
> way to fix this bug. GOA should just try to get a ticket and let libkrb5
> perform the discovery. GOA will need to do this anyway to support any of the
> advanced authentication mechanisms (OTP, SPAKE, etc.).

Whether or not it's the right way to fix the issue long-term, it *does* resolve the immediate problem which is affecting many users. In the interest of getting them up and running, can we just push this as a band-aid for now and move the discussion of long-term solutions elsewhere?

As near as I can tell, there's no *risk* or bad architecture decision being made in the proposed patch that would make it harder to change our approach later, so please just go ahead and fix it.

Comment 8 Fedora Update System 2016-12-13 14:16:33 UTC
realmd-0.16.2-7.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-81125d299a

Comment 9 Fedora Update System 2016-12-13 15:11:00 UTC
realmd-0.16.2-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-43b75c5a14

Comment 10 Fedora Update System 2016-12-13 15:26:13 UTC
realmd-0.16.2-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f5324625f

Comment 11 Petr Menšík 2016-12-13 18:40:21 UTC
I agree with #c2 Discovery of fedoraproject.org configuration is problematic. Even if I configure my system to accept ticket by manual configuration, kinit works but kerberos user in UI fails.

Detection of URI from DNS is problematic anyway. For example BIND 9.9.4 in RHEL7 is not able to fetch current URI from _kerberos.fedoraproject.org. Not only serve from its own zones, but also not willing to cache it.

I think if I enter domain manually, it should just try to obtain a ticket. Especially if _kerberos._udp SRV record is missing.

Comment 12 Fedora Update System 2016-12-14 02:22:35 UTC
realmd-0.16.2-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f5324625f

Comment 13 Fedora Update System 2016-12-14 02:24:14 UTC
realmd-0.16.2-6.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-43b75c5a14

Comment 14 Fedora Update System 2016-12-14 02:24:34 UTC
realmd-0.16.2-7.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-81125d299a

Comment 15 Sumit Bose 2016-12-14 11:18:27 UTC
As you can see there are realmd updates available for F23, F24 and F25 which should make goa work with realmd and FEDORAPROJECT.ORG.

Since the fallback to TCP make sense for realmd in general as well I would prefer if this ticket can be kept assigned to realmd. If you think that goa does not use realmd correctly or should not use realmd at all please open a new ticket for goa. Thank you.

Comment 16 Fedora Update System 2016-12-15 23:32:12 UTC
realmd-0.16.2-7.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2016-12-16 00:26:56 UTC
realmd-0.16.2-7.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2016-12-16 22:23:08 UTC
realmd-0.16.2-6.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Debarshi Ray 2017-11-03 19:32:38 UTC
Looks like this bug has re-appeared:
https://bugzilla.gnome.org/show_bug.cgi?id=789187

Either way, I am ripping out the realmd use from GOA. Not sure why it was done that way initially, but it makes things simpler and robust.

Comment 20 Sumit Bose 2017-11-03 21:15:33 UTC
I think this is a different issue. The Kerberos discovery went well, there is just no log message about successfully getting an address with tcp.

While trying to discover if there are LDAP servers in the domain to determine the domain type (AD, IPA, something else) realmd got stuck at 2604:1580:fe00:0:dead:beef:cafe:fed1 

You can try this manually with:

ldapsearch -h 2604:1580:fe00:0:dead:beef:cafe:fed1 -x -b '' -s base 

which will hand for some time. For other addresses returned for fedoraproject.org this returns immediately:

$ ldapsearch -h 2605:bc80:3010:600:dead:beef:cafe:fed9 -x -b '' -s base 
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

I'll try to figure out if realmd can tell the underlying LDAP library to use a shorter timeout.

Comment 21 Debarshi Ray 2017-11-04 14:08:25 UTC
(In reply to Sumit Bose from comment #20)
> I think this is a different issue. The Kerberos discovery went well, there
> is just no log message about successfully getting an address with tcp.

I see.

> While trying to discover if there are LDAP servers in the domain to
> determine the domain type (AD, IPA, something else) realmd got stuck at
> 2604:1580:fe00:0:dead:beef:cafe:fed1 

That makes sense now. While playing with the code, I did catch a few GErrors that complained about a time out. However, by then I had already set my mind on removing the realmd use that Nathaniel and others had complained about in the past, so I didn't pay much heed to it.

Thanks for the info'.


Note You need to log in before you can comment on or make changes to this bug.