Bug 1221358 - SSSD doesn't work with ID mapping and disabled subdomains
Summary: SSSD doesn't work with ID mapping and disabled subdomains
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.6
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-13 20:24 UTC by Jakub Hrozek
Modified: 2018-05-10 10:54 UTC (History)
11 users (show)

(edit)
Setups with "subdomains_provider=none" set for AD domains did not sometimes work as expected. Now, the ldap_idmap_default_domain_sid option value is used for the SSSD main domain, thus fixing the bug. Note that ldap_idmap_default_domain_sid must be set for SSSD to function correctly in this situation.
Clone Of:
(edit)
Last Closed: 2015-07-22 06:46:19 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1448 normal SHIPPED_LIVE sssd bug fix and enhancement update 2015-07-20 18:43:53 UTC

Description Jakub Hrozek 2015-05-13 20:24:37 UTC
Description of problem:
Lukas found out that SSSD doesn't work properly if it's connected to a forest member domain (not the forest root), ID mapping is used and subdomain provider is disabled.

Disabling the subdomain provider is a valid choice very often because the other domains might not be reachable due to firewall restrictions. SSSD should be able to work well even with disabled subdomains provider

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

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jakub Hrozek 2015-05-13 20:25:33 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2635

Comment 3 Lukas Slebodnik 2015-05-14 07:06:58 UTC
* master: 21687d1d553579e81aa43bfa20f2e70fb39e8461
* sssd-1-12: 2bf32678c96304d04e69813fd6d317d981ad2c41

Comment 4 Jakub Hrozek 2015-05-14 12:40:35 UTC
Steps to reproduce:
 - Enroll SSSD to a member domain of an AD forest
 - Use the AD provider
 - set subdomains_provider=none

Comment 6 Jakub Hrozek 2015-05-22 09:01:58 UTC
* master: 21687d1d553579e81aa43bfa20f2e70fb39e8461
* sssd-1-12: 2bf32678c96304d04e69813fd6d317d981ad2c41

Comment 8 Kaushik Banerjee 2015-06-02 16:59:55 UTC
Tested with sssd-1.12.4-43.el6.x86_64

User lookups fail on connecting to the child domain with the following config:
[domain/child1.sssdad.com]
debug_level = 0xFFF0
id_provider = ad
ad_domain = child1.sssdad.com
cache_credentials = True
krb5_store_password_if_offline = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
subdomains_provider=none

Domain log shows:
(Tue Jun  2 22:21:27 2015) [sssd[be[child1.sssdad.com]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=user1_dom3-970205]
(Tue Jun  2 22:21:27 2015) [sssd[be[child1.sssdad.com]]] [be_req_set_domain] (0x0400): Changing request domain from [child1.sssdad.com] to [child1.sssdad.com]
(Tue Jun  2 22:21:27 2015) [sssd[be[child1.sssdad.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)]
(Tue Jun  2 22:21:27 2015) [sssd[be[child1.sssdad.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)]

Workaround:
Since the autodiscovery fails, add the domain sid manually i.e. "ldap_idmap_default_domain_sid = S-1-5-21-3406858696-2348136156-2230084869"

Comment 9 Jakub Hrozek 2015-06-02 18:00:35 UTC
(In reply to Kaushik Banerjee from comment #8)
> Workaround:
> Since the autodiscovery fails, add the domain sid manually i.e.
> "ldap_idmap_default_domain_sid = S-1-5-21-3406858696-2348136156-2230084869"

Lukas would know this better, but I think it's expected with disabled subdomains provider.

However, it /is/ something we should document.

Comment 10 Lukas Slebodnik 2015-06-02 18:04:08 UTC
The title of this BZ is not the proper.

The fix allows to use workaround with ldap_idmap_default_domain_sid
previously it was not possible to use this workaround.

Comment 11 Jakub Hrozek 2015-06-02 19:27:22 UTC
I fixed the doc text, can we move back to ON_QA ?

Comment 12 Kaushik Banerjee 2015-06-03 06:56:57 UTC
I used an unpatched build sssd-1.12.4-40.el6.x86_64 and see that the workaround of manually defining ldap_idmap_default_domain_sid works in it.

Was this supposed to be broken in sssd-1.12.4-40 ?

Comment 13 Lukas Slebodnik 2015-06-03 07:43:26 UTC
(In reply to Kaushik Banerjee from comment #12)
> I used an unpatched build sssd-1.12.4-40.el6.x86_64 and see that the
> workaround of manually defining ldap_idmap_default_domain_sid works in it.
> 
> Was this supposed to be broken in sssd-1.12.4-40 ?

ID mapping worked in case when user had posix attributes,
but it did not worked for users *without* posix attributes.

IIRC the reproducer should be:
* create user without posix attributes.
* disable subdomains
* configure ldap_idmap_default_domain_sid
* get ID info about user WITHOUT posix atributes.

Comment 14 Kaushik Banerjee 2015-06-03 09:42:20 UTC
I see that non-posix groups were not returned earlier. Here is my test result.

On sssd-1.12.4-40
# id user1_dom3-970205@child1.sssdad.com
uid=201898(user1_dom3-970205@child1.sssdad.com) gid=200513(domain users@child1.sssdad.com) groups=200513(domain users@child1.sssdad.com)

On sssd-1.12.4-43
# id user1_dom3-970205@child1.sssdad.com
uid=201898(user1_dom3-970205@child1.sssdad.com) gid=200513(domain users@child1.sssdad.com) groups=200513(domain users@child1.sssdad.com),201901(group1_dom3-970205@child1.sssdad.com)

In the above test, user1_dom3-970205 and group1_dom3-970205 do not have posix attributes. The sssd.conf has:
[domain/child1.sssdad.com]
debug_level = 0xFFF0
id_provider = ad
ad_domain = child1.sssdad.com
cache_credentials = True
krb5_store_password_if_offline = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
subdomains_provider=none
ldap_idmap_default_domain_sid = S-1-5-21-3406858696-2348136156-2230084869

Please turn this bug to ON_QA if the above test results are as expected.

Comment 15 Kaushik Banerjee 2015-06-03 11:32:56 UTC
Verified in sssd-1.12.4-43 as per comment #14

Comment 17 errata-xmlrpc 2015-07-22 06:46:19 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://rhn.redhat.com/errata/RHBA-2015-1448.html


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