Bug 861132

Summary:	Domains overlap in range 1 - 4294967295
Product:	[Fedora] Fedora	Reporter:	Stef Walter <stefw>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	jhrozek, sbose, sgallagh, ssorce
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-20 15:51:00 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:

Description Stef Walter 2012-09-27 15:26:48 UTC

Description of problem:

When sssd starts after being configured with realmd, I see this in the logs:

(Thu Sep 27 17:23:44:576540 2012) [sssd] [check_domain_ranges] (0x0020): Domains 'ipa.thewalter.lan' and 'AD' overlap in range 1 - 4294967295

Not sure if this is a realmd or sssd bug. Should we be configuring something different in realmd, or does sssd need better defaults when used with multiple domains?

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

Installed Packages
Name        : sssd
Arch        : x86_64
Version     : 1.9.0
Release     : 24.fc18

realmd from git master.

The configured sssd.conf file:

[domain/ipa.thewalter.lan]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.thewalter.lan
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = stef-rawhide.thewalter.lan
chpass_provider = ipa
ipa_server = _srv_, dc.ipa.thewalter.lan
dns_discovery_domain = ipa.thewalter.lan
[domain/default]

cache_credentials = True

[sssd]
domains = ipa.thewalter.lan, AD
config_file_version = 2
services = nss, pam

[domain/AD]
auth_provider = ad
ad_domain = ad.thewalter.lan
krb5_realm = AD.THEWALTER.LAN
case_sensitive = False
enumerate = False
chpass_provider = ad
re_expression = (?P<domain>[^\\]+)\\(?P<name>[^\\]+)
cache_credentials = False
id_provider = ad
full_name_format = %2$s\%1$s
krb5_store_password_if_offline = True
access_provider = simple
use_fully_qualified_names = True

Comment 1 Jakub Hrozek 2012-09-27 17:49:08 UTC

Hi Stef!

I think you're actually seeing intended behaviour. The SSSD contains min_id and max_id filters. Back when the SSSD started, the min_id parameter defaulted to something like 1000 so that the local IDs would be automatically filtered out.

However, we quickly realized that many users are running (arguably wrong) configurations where the entries stored in LDAP fall into the same ID ranges as the local users/groups, so we just lowered the min_id param to 1 so all entries that are actually stored in LDAP are returned.

Do you think there is a way to autoconfigure the min_id/max_id limits from an AD server? I'm open to suggestions, but at least in the generic LDAP case I don't think there's much do to and we just let the admin configure the limits on his own..

Comment 2 Stephen Gallagher 2012-09-27 19:49:22 UTC

I think the only real bug here is that the error message is at such a low debug level. We should probably be logging this at SSSDBG_CONF_SETTINGS, not SSSDBG_MINOR_FAILURE.

In real practice, it's not actually an error. As long as the domains don't truly have overlapping IDs, it should be okay.

One thing we might want to do though is ensure that ldap_idmap_range_min sets min_id implicitly. This would help somewhat.

Comment 3 Stef Walter 2012-10-01 12:01:26 UTC

So the upshort of this is that we can't guarantee uid/gids from multiple domains not to collide in sssd, unless those domains:

 * Coordinate their UID/GID allocations with one another.
 * Are all AD domains using the idmap stuff.

Is that a correct assumption?

Comment 4 Stephen Gallagher 2012-10-01 12:08:12 UTC

I'd say only the coordination is correct. Even if they're using the idmap stuff, there's a slight risk that separate SSSD domains would overlap, if by unlucky coincidence the two domains hashed to the same range.

If they are two domains in the forest but only handled as a single SSSD domain, then the ID-mapping hash handles collisions in a single domain properly.

Of course, right now we don't fully support multiple domains in a forest because there is not yet a subdomain provider for the AD provider.

Comment 5 Jakub Hrozek 2012-10-03 12:28:52 UTC

Sounds to me like there is no bug, is there? Can I close this bugzilla?

Comment 6 Stephen Gallagher 2012-10-03 19:01:52 UTC

(In reply to comment #5)
> Sounds to me like there is no bug, is there? Can I close this bugzilla?

I'd close it. The only question is whether we should change the log level of the message.

Comment 7 Jakub Hrozek 2012-10-04 04:24:17 UTC

(In reply to comment #6)
> (In reply to comment #5)
> > Sounds to me like there is no bug, is there? Can I close this bugzilla?
> 
> I'd close it. The only question is whether we should change the log level of
> the message.

Right, the CRIT_FAILURE is too restrictive.

Comment 8 Jakub Hrozek 2012-10-04 04:25:01 UTC

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1562

Comment 9 Fedora Update System 2012-10-07 16:25:36 UTC

sssd-1.9.1-1.fc18,libldb-1.1.13-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sssd-1.9.1-1.fc18,libldb-1.1.13-1.fc18

Comment 10 Fedora Update System 2012-10-07 19:39:25 UTC

Package sssd-1.9.1-1.fc18, libldb-1.1.13-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.9.1-1.fc18 libldb-1.1.13-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15595/sssd-1.9.1-1.fc18,libldb-1.1.13-1.fc18
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-12-20 15:51:03 UTC

sssd-1.9.1-1.fc18, libldb-1.1.13-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.