Bug 1401605
Summary: | Adding Kerberos user fails for non-domain accounts | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stephen Gallagher <sgallagh> | ||||||
Component: | realmd | Assignee: | Sumit Bose <sbose> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 25 | CC: | crobinso, ctubbsii, debarshir, ignatenko, jhrozek, mcatanzaro+wrong-account-do-not-cc, npmccallum, pemensik, puiterwijk, sbose, stefw, tom, tomek, vondruch | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
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: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2016-12-15 23:32:12 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Stephen Gallagher
2016-12-05 16:28:07 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. 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. 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
(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. (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. 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.). (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. realmd-0.16.2-7.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-81125d299a realmd-0.16.2-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-43b75c5a14 realmd-0.16.2-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f5324625f 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. 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 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 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 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. 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. 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. 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. 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. 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. (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'. |