|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>|
|Version:||18||CC:||jhrozek, sbose, sgallagh, ssorce|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-12-20 15:51:00 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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.