Bug 1298629 - ID mapping - bug in computing max id for slice range
ID mapping - bug in computing max id for slice range
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Pavel Reichl
Steeve Goveas
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-14 10:20 EST by Jakub Hrozek
Modified: 2016-05-10 16:26 EDT (History)
10 users (show)

See Also:
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 16:26:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jakub Hrozek 2016-01-14 10:20:28 EST
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2922

There seems to be a bug in the way we assign ranges for domain when we algorithmically perform id mapping.

In sss_idmap_calculate_range() we compute the upper limit for ids *max* as being 'min + range' which means that actual range of ids is:
{{{
max - min + 1 = min + range - min + 1 = range + 1
}}}
And this differs from range by 1.

We should be even be able to see some mapping issue with secondary ranges. The last POSIX ID from a range and the first POSIX ID from the next range should return the same SID/RID. 

In the IPA code there is 'range.max = r->base_id + r->id_range_size -1;' We should amend code to the same.
Comment 2 Lukas Slebodnik 2016-01-20 12:19:20 EST
master:
* 7db89d44b5582a0cb0a61a7aa42a2fac7ca9408f

sssd-1-13:
* 645933bcfd4acfb1729fcee2fee6c37b1acbfb92
Comment 3 Sumit Bose 2016-01-27 10:44:46 EST
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@ad.domain

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.
Comment 6 Niranjan Mallapadi Raghavender 2016-03-18 22:23:07 EDT
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@winpki1.testpki.test is  still shown,  

Is the above expected ?
Comment 7 Sumit Bose 2016-03-19 07:18:46 EDT
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.
Comment 8 Niranjan Mallapadi Raghavender 2016-03-19 21:16:41 EDT
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@winpki1.testpki.test
administrator@winpki1.testpki.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@winpki1.testpki.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.
Comment 9 Sumit Bose 2016-03-20 07:43:00 EDT
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.
Comment 11 errata-xmlrpc 2016-05-10 16:26:29 EDT
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

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