Bug 1416528

Summary:	sssd in cross realm trust configuration should be able to use AD KDCs from a client site defined in sssd.conf or a snippet
Product:	Red Hat Enterprise Linux 7	Reporter:	Thorsten Scherf <tscherf>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED ERRATA	QA Contact:	ipa-qe <ipa-qe>
Severity:	medium	Docs Contact:	Filip Hanzelka <fhanzelk>
Priority:	medium
Version:	7.3	CC:	atolani, clasohm, fhanzelk, gparente, grajaiya, jangerrit.kootstra, jbnance, jhrozek, lslebodn, mkosek, mzidek, nsoman, ovasik, pasik, pbrezina, ryan, sbose, sgoveas, sumenon
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-30 10:40:47 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:
Bug Depends On:
Bug Blocks:	1420851, 1472344, 1477926, 1490412, 1550132

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