RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1416528 - sssd in cross realm trust configuration should be able to use AD KDCs from a client site defined in sssd.conf or a snippet
Summary: sssd in cross realm trust configuration should be able to use AD KDCs from a ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: ipa-qe
Filip Hanzelka
URL:
Whiteboard:
Depends On:
Blocks: 1420851 1472344 1477926 1490412 1550132
TreeView+ depends on / blocked
 
Reported: 2017-01-25 17:30 UTC by Thorsten Scherf
Modified: 2022-03-13 14:11 UTC (History)
19 users (show)

Fixed In Version: sssd-1.16.2-5.el7
Doc Type: Enhancement
Doc Text:
*SSSD* on an IdM client can now authenticate against a specific AD site or AD DC The *System Security Services Daemon* (SSSD) running on an Identity Management (IdM) client in a domain with a trust relationship with Active Directory (AD) can now be pinned to authenticate against a configured AD site or a configured set of AD Domain Controllers (DC). Previously, *SSSD* relied completely on DNS SRV discovery done by libkrb5. However, this did not take AD sites into account because libkrb5 has no notion of AD sites. If the administrator wanted to pin *SSSD* to authenticate against a set of AD DCs, they had to set the correct Key Distribution Centre (KDC) in the `/etc/krb5.conf` file, which was non-intuitive. The enhancement is especially convenient for large environments, in which modifying the `/etc/krb5.conf` file on each client individually was previously the only available solution.
Clone Of:
Environment:
Last Closed: 2018-10-30 10:40:47 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4324 0 None closed RFE: sssd in cross realm trust configuration should be use AD KDC from a list or site defined in the config file 2021-01-11 12:09:39 UTC
Red Hat Knowledge Base (Solution) 3220321 0 None None None 2018-01-31 18:56:41 UTC
Red Hat Product Errata RHSA-2018:3158 0 None None None 2018-10-30 10:41:50 UTC

Description Thorsten Scherf 2017-01-25 17:30:39 UTC 
Description of problem:

In IdM/AD cross realm trust configuration, sssd running on the server is capable of retrieving identity information from local AD site DCs but sssd running on clients pick a random KDC returned from DNS SRV discovery for the actual authentication. There is currently no way to tell sssd to use a AD DC from the local client site.

A workaround exists by disabling the DNS SRV lookup and hardcode the desired servers into krb5.conf. This is not really convenient, especially for roaming users.

The ad provider has a ad_site parameter which provides the required functionality. The request is to have the same also available for the ipa provider used in cross realm trust configuration.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Jakub Hrozek 2017-02-01 10:24:49 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/3291
Comment 2 Arpit Tolani 2017-07-05 15:03:34 UTC 
Can we fix this issue using dp_options as explained in https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html

Of course it is not implemented yet, but once it is implemented, Can we use this as fix or are we planning something else?
Comment 3 Jakub Hrozek 2017-07-10 09:09:23 UTC 
(In reply to Arpit Tolani from comment #2)
> Can we fix this issue using dp_options as explained in
> https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html
> 
> Of course it is not implemented yet, but once it is implemented, Can we use
> this as fix or are we planning something else?

This is only a partial solution, because the authentication relies on libkrb5 being configured correctly, so we'd have to put the AD DCs hostname to krb5.conf as well. The proper fix would generate snippets or kdcinfo files based on the server configuration.
Comment 11 ir. Jan Gerrit Kootstra 2018-01-31 12:00:28 UTC 
In our setup we have lots of AD servers outside the site of the IPA servers and IPA clients.

If an IPA client or IPA server finds a Windows AD server far away from the site, the id command can take upto 30 seconds for the first query of a new login-id.

running id in case an AD server in the site has been found takes less then 1 second in general or 2 seconds max.

We would benefit a lot if this Feature Extention would be implemented.
Comment 16 Jakub Hrozek 2018-06-20 19:26:29 UTC 
I changed the subject to make it clear what will be implemented in 7.6. Finding or mapping the site requires cooperation with changes on the IPA server which are currently not implemented.
Comment 20 Fabiano Fidêncio 2018-06-29 20:23:43 UTC 
master
 29bbc8e
 6f80bcc
 a9a9f39
 8971399
 1cce549
 18b7f0a
 014e7d8
Comment 22 Jakub Hrozek 2018-06-30 10:17:31 UTC 
For testing, you can follow the description in the design page:
https://docs.pagure.org/SSSD.sssd/design_pages/kdcinfo_improvements.html
Comment 25 Sudhir Menon 2018-09-03 10:38:30 UTC 
Fix is seen. Verified on Red Hat Enterprise Linux Server release 7.6 Beta (Maipo)
using the below 

ipa-server-4.6.4-7.el7.x86_64
sssd-1.16.2-12.el7.x86_64
samba-4.8.3-4.el7.x86_64
389-ds-base-1.3.8.4-12.el7.x86_64
pki-server-10.5.9-6.el7.noarch
ipa-client-4.6.4-7.el7.x86_64


Scenario1: SSSD running on an IPA client 

1. With ad_site value set in sssd.conf

cat /etc/sssd/sssd.conf
[domain/venus.test/ipaad2016.test]
ad_site = Default-First-Site-Name

#systemctl stop sssd.service
#systemctl start sssd.service

[root@client pubconf]# pwd
/var/lib/sss/pubconf
[root@client pubconf]# ls -l
total 8
-rw-r--r--. 1 root root 14 Sep  3 15:44 kdcinfo.IPAAD2016.TEST
-rw-r--r--. 1 root root 14 Sep  3 15:44 kdcinfo.VENUS.TEST

[root@client pubconf]# cat kdcinfo.IPAAD2016.TEST 
<ip-address-of trusted AD domain>:88

===Logs===
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [dp_get_options] (0x0400): Option ad_site has value Default-First-Site-Name
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [krb5_service_new] (0x0100): write_kdcinfo for realm IPAAD2016.TEST set to true
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [ipa_subdomains_write_kdcinfo_domain_step] (0x0100): Resolving site Default-First-Site-Name for domain ipaad2016.test
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'kerberos'. Will use DNS discovery domain 'Default-First-Site-Name._sites.ipaad2016.test'
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_kerberos._tcp.Default-First-Site-Name._sites.ipaad2016.test'
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [sdap_process_result] (0x2000): Trace: sh[0x563112d5e6c0], connected[1], ops[(nil)], ldap[0x563112d617a0]
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [be_ptask_online_cb] (0x0400): Back end is online
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [be_ptask_enable] (0x0080): Task [SUDO Smart Refresh]: already enabled
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [be_ptask_online_cb] (0x0400): Back end is online
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [be_ptask_enable] (0x0080): Task [SUDO Full Refresh]: already enabled
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_getsrv_done] (0x1000): Using TTL [600]
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [request_watch_destructor] (0x0400): Deleting request watch
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [fo_discover_srv_done] (0x0400): Got answer. Processing...
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [fo_discover_srv_done] (0x0400): Got 1 servers
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_is_address] (0x4000): [idm-qe-ipa-ci1.ipaad2016.test] does not look like an IP address
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_gethostbyname_step] (0x2000): Querying DNS
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'idm-qe-ipa-ci1.ipaad2016.test' in DNS
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [request_watch_destructor] (0x0400): Deleting request watch
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [resolv_hostport_list_step] (0x2000): Done
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [ipa_subdomains_write_kdcinfo_write_step] (0x0100): Will write [:88] for ipaad2016.test
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/pubconf/.krb5info_dummy_S9vPhY]
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/pubconf/.krb5info_dummy_S9vPhY]
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [sss_domain_get_state] (0x1000): Domain ipasub2016.ipaad2016.test is Active
(Mon Sep  3 15:44:41 2018) [sssd[be[venus.test]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x563112d71120

2. with ad_server option set in sssd.conf

[domain/venus.test/ipaad2016.test]
ad_server = <ip-parent-domain>, <ip-child-domain>

(Mon Sep  3 15:29:51 2018) [sssd[be[venus.test]]] [dp_get_options] (0x0400): Option ad_server has value <ip-parent-domain, ip-child-domain>
(Mon Sep  3 15:29:51 2018) [sssd[be[venus.test]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55d0df48c4e0
(Mon Sep  3 15:29:51 2018) [sssd[be[venus.test]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55d0df48bb90
(Mon Sep  3 15:29:51 2018) [sssd[be[venus.test]]] [ldb] (0x4000): Running timer event 0x55d0df48c4e0 "ltdb_callback"
(Mon Sep  3 15:29:51 2018) [sssd[be[venus.test]]] [ldb] (0x4000): Destroying timer event 0x55d0df48bb90 "ltdb_timeout"
(Mon Sep  3 15:29:51 2018) [sssd[be[venus.test]]] [ldb] (0x4000): Ending timer event 0x55d0df48c4e0 "ltdb_callback"
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [dp_get_options] (0x0400): Option ad_site has no value
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [krb5_service_new] (0x0100): write_kdcinfo for realm IPAAD2016.TEST set to true
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [ipa_subdomains_write_kdcinfo_domain_step] (0x0100): Resolving servers [.....] for domain ipaad2016.test
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [resolv_hostport_list_step] (0x2000): Done
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [ipa_subdomains_write_kdcinfo_write_step] (0x0100): Will write [] for ipaad2016.test
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [ipa_subdomains_write_kdcinfo_write_step] (0x0100): Will write [] for ipaad2016.test
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/pubconf/.krb5info_dummy_KXSWZ8]
(Mon Sep  3 15:31:37 2018) [sssd[be[venus.test]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/pubconf/.krb5info_dummy_KXSWZ8]

[root@client pubconf]# pwd
/var/lib/sss/pubconf
[root@client pubconf]# ls -l
total 8
-rw-r--r--. 1 root root 11 Sep  3 15:32 kdcinfo.IPAAD2016.TEST
-rw-r--r--. 1 root root 14 Sep  3 15:32 kdcinfo.VENUS.TEST

[root@client pubconf]# cat kdcinfo.IPAAD2016.TEST 
<ip-address of parent trusted domain>
<ip-address of child trusted domain>

Scenario2: SSSD running on an IPA master with a trust established towards an AD domain

[root@master ~]# ipa trust-add --two-way=true
Realm name: ipaad2016.test
Active Directory domain administrator: administrator
Active Directory domain administrator's password: 
-------------------------------------------------------
Added Active Directory trust for realm "ipaad2016.test"
-------------------------------------------------------
  Realm name: ipaad2016.test
  Domain NetBIOS name: IPAAD2016
  Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

[root@master ~]# getent passwd aduser1
aduser1:*:1577604272:1577604272:aduser1 ads:/home/ipaad2016.test/aduser1:

[root@master ~]# cd /var/lib/sss/pubconf
-rw-r--r--. 1 root root 11 Sep  3 15:12 kdcinfo.IPAAD2016.TEST
-rw-r--r--. 1 root root 11 Sep  3 15:12 kdcinfo.IPASUB2016.IPAAD2016.TEST

[root@master ~]# cat /var/lib/sss/pubconf/kdcinfo.IPAAD2016.TEST 
<ip-address of AD server>

[root@master ~]# cat /var/lib/sss/pubconf/kdcinfo.IPASUB2016.IPAAD2016.TEST
<ip-address of child AD Server>
Comment 27 errata-xmlrpc 2018-10-30 10:40:47 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3158
Note You need to log in before you can comment on or make changes to this bug.