Bug 1298629
Summary: | ID mapping - bug in computing max id for slice range | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jakub Hrozek <jhrozek> |
Component: | sssd | Assignee: | Pavel Reichl <preichl> |
Status: | CLOSED ERRATA | QA Contact: | Steeve Goveas <sgoveas> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.0 | CC: | grajaiya, jhrozek, lslebodn, mkosek, mniranja, mzidek, pbrezina, preichl, sbose, sgoveas |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | sssd-1.13.3-14.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-10 20:26:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jakub Hrozek
2016-01-14 15:20:28 UTC
master: * 7db89d44b5582a0cb0a61a7aa42a2fac7ca9408f sssd-1-13: * 645933bcfd4acfb1729fcee2fee6c37b1acbfb92 The SSSD configuration option ldap_idmap_range_size defines the number of POSIX IDs available in a range i.e. how may RIDs can be mapped to a POSIX ID. E.g. if ldap_idmap_range_size=5 we can map the RIDs 0,1,2,3,4 because counting starts with zero. Without the patch the RID 5 could be mapped as well although it is already the 6th ID. To check this in a real setup with id_provider=ad set 'ldap_idmap_range_size=513' (cache must be removed is SSSD was used with a different value before). Now the RID 513 which belongs to the AD 'Domain Users' group should not be mapped anymore and getent passwd Administrator should return nothing because although the RID of the Administrator 500 can be mapped the RID of the primary group cannot be mapped. Without the patch getent passwd will return a result with the patch applied it will return nothing. While using the below configuration [sssd] config_file_version = 2 domains = winpki1.testpki.test services = nss, pam [domain/winpki1.testpki.test] id_provider = ad auth_provider = ad access_provider = ad default_shell = /bin/bash fallback_homedir = /home/%d/%u use_fully_qualified_names = True debug_level = 9 enumerate = False ldap_idmap_range_size = 513 ldap_id_mapping = True ad_server = WIN-Q8VKBEJ7H39.winpki1.testpki.test ad_domain = winpki1.testpki.test I have set ldap_idmap_range_size = 513, after clearing sssd cache and restarting sssd, getent Administrator.test is still shown, Is the above expected ? Which SSSD version did you use? How does the output look like? With older cersion of SSSD is is expected that the output is show. With newer versions of SSSD you might need to set 'ldap_idmap_helper_table_size=0' to disable the new feature which automatically adds new ranges if the configured range size is too small. sorry about not specifying the version: Version: sssd-1.13.3-22.el6.x86_64 Before specifying the ldap_idmap_helper_table_size=0 [sssd] config_file_version = 2 domains = winpki1.testpki.test services = nss, pam [domain/winpki1.testpki.test] id_provider = ad auth_provider = ad access_provider = ad default_shell = /bin/bash fallback_homedir = /home/%d/%u use_fully_qualified_names = True debug_level = 9 enumerate = False ldap_idmap_range_size = 513 ldap_id_mapping = True ad_server = WIN-Q8VKBEJ7H39.winpki1.testpki.test ad_domain = winpki1.testpki.test [root@dhcp201-105 mc]# getent passwd Administrator.test administrator.test:*:503810548:979787864:Administrator:/home/Administrator:/bin/sh #stopped sssd and cleared everything from /var/lib/sss/db/* and /var/lib/sss/mc/* start sssd service $service sssd start [root@dhcp201-105 db]# getent passwd Administrator.test [root@dhcp201-105 db]# I don't see the output in getent passwd. I see the following in the logs (Sun Mar 20 06:37:16 2016) [sssd[be[winpki1.testpki.test]]] [sdap_idmap_sid_to_unix] (0x0040): Object SID [S-1-5-21-2826619844-1825486024-3854887371-513] has a RID that is larger than the ldap_idmap_range_size. See the "ID MAPPING" section of sssd-ad(5) for an explanation of how to resolve this issue. Yes, this makes sense. Since there already was an entry in the cache it was returned before you removed the cache. I think you can move the ticket to verified. 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-2016-0782.html |