Bug 1561584 - RFE: Does it make sense to remove [domain_realm] section from ipa-client krb5.conf files?
Summary: RFE: Does it make sense to remove [domain_realm] section from ipa-client krb5...
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: 1644708 1647919
TreeView+ depends on / blocked
 
Reported: 2018-03-28 14:48 UTC by Brian J. Atkisson
Modified: 2019-03-27 11:26 UTC (History)
11 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description Brian J. Atkisson 2018-03-28 14:48:07 UTC
Description of problem:

The presence of a [domain_realm] profile mapping in /etc/krb5.conf prevents DNS-based kerberos referrals from working. As IdM starts supporting realm trust, it probably makes sense to not populate [domain_realm] by default, pushing clients to perform DNS realm lookups (_kerberos TXT record for realm).

Comment 5 Florence Blanc-Renaud 2018-07-10 09:11:28 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/7631

Comment 17 Alexander Bokovoy 2019-03-24 07:32:03 UTC
Based on our discussions with Robbie and others, I published an article explaining a situation with Kerberos service translation and what we need to update in MIT Kerberos to allow administrators to control name resolution order on the clients: https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/

Comment 18 Brian J. Atkisson 2019-03-24 20:57:58 UTC
(In reply to Alexander Bokovoy from comment #17)
> Based on our discussions with Robbie and others, I published an article
> explaining a situation with Kerberos service translation and what we need to
> update in MIT Kerberos to allow administrators to control name resolution
> order on the clients:
> https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/

Great article! This is very helpful for explaining the situation to our users.


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