(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.
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=
When comparing this to the other user's not being mapped, the
objectSid coming from LDAP, at initial glance, is not the same.