-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/16/2013 12:27 PM, Russell Jones wrote:
Hi all,
SSSD 1.9.2 on CentOS 6.
I am attempting to configure SSSD to authenticate against AD via
LDAP. When starting the daemon though, the logs get filled with
failure messages about being unable to convert the SID properly for
every user. The extra strange part is the SID it says it cannot
convert is the same for every user. Example:
(Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_user]
(0x1000): Mapping user [REDACTED] objectSID to unix ID (Mon Apr 15
15:52:47 2013) [sssd[be[LDAP]]] [sdap_idmap_sid_to_unix] (0x0080):
Could not convert objectSID
[S-1-5-21-3220130920-4012199101-135577023-1153286127] to a UNIX ID
(Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_user]
(0x0040): Failed to save user [REDACTED] (Mon Apr 15 15:52:47 2013)
[sssd[be[LDAP]]] [sdap_save_users] (0x0040): Failed to store user
988. Ignoring.
Looking at that SID, the RID portion of it is is *really* large. The
last section there is 1153286127 (split up, that's 1,153,286,127).
Given that you've set an ldap_idmap_range_max of 1,000,000, this
pretty much explains why you can't convert this user. The conversion
of this should be 1153286127+100000 (your ldap_idmap_range_min is the
base, which leaves it at 1,153,386,127, which is FAR above the
1,000,000 you have allocated.
I'm at a loss to explain why some of your users have IDs in the
billion-RID range, but if you want these to be handled properly, I
think you're going to need to set the following values:
ldap_idmap_range_min = 100000
ldap_idmap_range_max = 2000100000
ldap_idmap_range_size = 2000000000
This will allow you to convert all entries in this domain. However,
because it requires reserving all 2 billion possible IDs for one
domain, you won't be able to handle a multi-domain forest.
I'd contact your Microsoft representatives to figure out why you have
entries with such high RID values.
Where can I get more information on why it's failing? The following
is my sssd.conf:
[sssd] domains = LDAP services = nss, pam config_file_version = 2
;debug_level = 0x1310
[nss] filter_groups = root filter_users = root
[pam]
[domain/LDAP] ldap_id_use_start_tls = True id_provider = ldap
chpass_provider = ldap ldap_uri = ldap://REDACTED ldap_search_base
= REDACTED auth_provider = ldap cache_credentials = true
ldap_schema = ad enumerate = True ldap_id_mapping = True
ldap_user_objectsid = objectSid ldap_idmap_range_min = 100000
ldap_idmap_range_max = 1000000
ldap_default_bind_dn = REDACTED ldap_default_authtok_type =
password ldap_default_authtok = REDACTED
ldap_tls_cacertdir = /etc/sssd/cacerts
debug_level = 9
ldap_force_upper_case_realm = True
Also, here's what ObjectSID looks like from LDAP (via ldapsearch)
for one of the users it's complaining about: objectSid::
AQUAAAAAAAUVAAAAaEzvv71MJe+/vRQI77+9RE1a77+977+9AAA=
Be aware, this is a base-64 conversion of a raw proprietary value.
What you see in the SSSD logs are the results of converting that into
the human-readable SID format. Attempting to compare this value
directly to any other SID value will provide you very little
information. You need to look at the decoded version (the S-1-5-21-*
representation).
When comparing this to the other user's not being mapped, the
objectSid coming from LDAP, at initial glance, is not the same.
Could you elaborate on this? Can you show me some examples of
objectSIDs that *do* work and several that do not as well?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlFtmyIACgkQeiVVYja6o6P73QCdF++U8ybyRrNFJ0M8ObntiMIj
q2cAoJQ1bVa0QYxi+uCis6o2mCR5hOad
=2MKZ
-----END PGP SIGNATURE-----