ldap_idmap_range_size - different defaults between versions?

[Richard Collins]

Hi,

Running Red Hat Enterprise Linux Server release 6.5 (Santiago) - 2.6.32-431.el6.x86_64

When running version sssd-1.9.2-129.el6.x86_64 users with objectSID/RID outside the
default range (200,000) fail to convert and therefore cannot be authenticated. For
example:


sssd-1.9.2-129.el6.x86_64 domain mapping:
(Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_init] (0x0100): Initializing
[1] domains for ID-mapping
(Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_add_domain] (0x0100): Adding
domain [###################-3828131906] as slice [9122]
(Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sysdb_idmap_dn] (0x4000):
objectSID=###################-3828131906,cn=id_mappings,cn=MYDOMAIN,cn=sysdb


sssd-1.9.2-129.el6.x86_64 failed attempt:
(Tue Sep 20 14:39:52 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_sid_to_unix] (0x0080): Could
not convert objectSID [###########################-200676] to a UNIX ID
(Tue Sep 20 14:39:52 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x0040): Failed to save
user [12345]


However, upgrading to version sssd-1.13.3-22.el6_8.4.x86_64 the problem disappears (no
other changes to config have been made)
Note: I manually deleted the sss cache in /var/lib/sss/db before restarting with the new
version:

sssd-1.13.3-22.el6_8.4.x86_64 domain mapping:
(Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_init] (0x0100): Initializing
[1] domains for ID-mapping
(Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_add_domain] (0x1000): Adding
domain [S-1-5-21-1000884740-1136923486-3828131906] as slice [9122]
(Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sysdb_idmap_dn] (0x4000):
objectSID=###################-3828131906,cn=id_mappings,cn=MYDOMAIN,cn=sysdb


sssd-1.13.3-22.el6_8.4.x86_64 successful attempt:
(Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x1000): Mapping user
[12345] objectSID [[###########################-200676] to unix ID
(Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x2000): Adding
originalDN [CN=12345,OU=Users,OU=WAVE,OU=BusinessUnits,DC=MYDOMAIN] to attributes of
[12345].
(Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x0400): Adding original
memberOf attributes to [12354].


According to the docs, the defaults for ldap_idmap_range_min, ldap_idmap_range_max and
ldap_idmap_range_size haven't changed between versions.

While the issue is resolved - i.e. users with RID in excess of 200,000 can authenticate,
I'm not clear why this now works and want to ensure I won't hit another limit in
the near future. I'd like to avoid changing the mapping parameters as this alters the
uid mapping and there will be a big task to clean up permissions on the file system.

Can anyone work out why this now works?

Thanks


Relevant server info:

AD controllers are WIN2012R2

SSSD is configured with a single domain

######begin sssd.conf#####
[sssd]
config_file_version = 2
services = nss, pam, sudo

domains = MYDOMAIN
debug_level = 9

[nss]
default_shell = /bin/bash
debug_level = 9
filter_users = root
filter_groups = root

[pam]
debug_level = 9

[sudo]
debug_level = 9

[domain/MYDOMAIN]
 id_provider = ldap
 access_provider = simple
 cache_credentials = false
 debug_level = 9
 ldap_server = _srv_
 ldap_search_base = #########
 ldap_id_use_start_tls = true
 ldap_tls_reqcert = allow
 ldap_default_bind_dn = #########
 ldap_default_authtok_type = password
 ldap_default_authtok = #########
 ldap_user_search_base = ou=BusinessUnits,dc=ad,dc=aib,dc=pri
 ldap_user_object_class = user
 ldap_id_mapping = true
 ldap_schema = ad
 ldap_group_search_base = #########
 ldap_group_object_class = group
 ldap_referrals = false
 enumerate = false
 override_homedir = /export/home/%u
 ldap_group_nesting_level = 5
 ldap_use_tokengroups = false
 simple_allow_groups = sasi,sasadmin,sasmgt
 ldap_access_order = expire
 ldap_account_expire_policy = ad

######end sssd.conf#####
This document is strictly confidential and is intended for use by the addressee unless
otherwise indicated. Allied Irish Banks AIB and AIB Group are registered business names of
Allied Irish Banks p.l.c. Allied Irish Banks, p.l.c. is regulated by the Central Bank of
Ireland. Registered Office: Bankcentre, Ballsbridge, Dublin 4. Tel: + 353 1 6600311;
Registered in Ireland: Registered No. 24173. ~~~~~~~Please consider the environment before
printing this Email~~~~~~~~ This email has been scanned by an external Email Security
System. This Disclaimer has been generated by CMDis

[Lukas Slebodnik]

On (22/09/16 12:22), Richard Collins wrote:
> Hi,
>
> Running Red Hat Enterprise Linux Server release 6.5 (Santiago) - 2.6.32-431.el6.x86_64
>
> When running version sssd-1.9.2-129.el6.x86_64 users with objectSID/RID outside the
> default range (200,000) fail to convert and therefore cannot be authenticated. For
> example:
>
>
> sssd-1.9.2-129.el6.x86_64 domain mapping:
> (Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_init] (0x0100): Initializing
> [1] domains for ID-mapping
> (Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_add_domain] (0x0100): Adding
> domain [###################-3828131906] as slice [9122]
> (Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sysdb_idmap_dn] (0x4000):
> objectSID=###################-3828131906,cn=id_mappings,cn=MYDOMAIN,cn=sysdb
>
>
> sssd-1.9.2-129.el6.x86_64 failed attempt:
> (Tue Sep 20 14:39:52 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_sid_to_unix] (0x0080): Could
> not convert objectSID [###########################-200676] to a UNIX ID
> (Tue Sep 20 14:39:52 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x0040): Failed to save
> user [12345]
>
>
> However, upgrading to version sssd-1.13.3-22.el6_8.4.x86_64 the problem disappears (no
> other changes to config have been made)
> Note: I manually deleted the sss cache in /var/lib/sss/db before restarting with the new
> version:
>
> sssd-1.13.3-22.el6_8.4.x86_64 domain mapping:
> (Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_init] (0x0100): Initializing
> [1] domains for ID-mapping
> (Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_add_domain] (0x1000): Adding
> domain [S-1-5-21-1000884740-1136923486-3828131906] as slice [9122]
> (Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sysdb_idmap_dn] (0x4000):
> objectSID=###################-3828131906,cn=id_mappings,cn=MYDOMAIN,cn=sysdb
>
>
> sssd-1.13.3-22.el6_8.4.x86_64 successful attempt:
> (Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x1000): Mapping user
> [12345] objectSID [[###########################-200676] to unix ID
> (Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x2000): Adding
> originalDN [CN=12345,OU=Users,OU=WAVE,OU=BusinessUnits,DC=MYDOMAIN] to attributes of
> [12345].
> (Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x0400): Adding original
> memberOf attributes to [12354].
>
>
> According to the docs, the defaults for ldap_idmap_range_min, ldap_idmap_range_max and
> ldap_idmap_range_size haven't changed between versions.
>
> While the issue is resolved - i.e. users with RID in excess of 200,000 can authenticate,
> I'm not clear why this now works and want to ensure I won't hit another limit in
> the near future. I'd like to avoid changing the mapping parameters as this alters the
> uid mapping and there will be a big task to clean up permissions on the file system.
>
> Can anyone work out why this now works?
>  
Because ticket https://fedorahosted.org/sssd/ticket/2188
was implmemented in upstream sssd-1.13.4 (but is also in el6.8)

Here is a link to desing page
https://fedorahosted.org/sssd/wiki/DesignDocs/IdmapAutoAssignNewSlices

If you would like to have older behaviour compatible with
older version of sssd then then you need to change value
of the option ldap_idmap_helper_table_size from default 10 -> 0

LS