-----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?