Learn more about these different git repos.
Other Git URLs
ID does not return a successful result:
id: usser@dmain.local: no such user
[sssd] domains = dmain.local config_file_version = 2 services = nss, pam
[domain/dmain.local] ad_domain = dmain.local krb5_realm = dmain.local realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad
ldap_idmap_range_max = 2000100000
ldap_idmap_range_size = 3000000
[sssd[be[dmain.local]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. [sssd[be[dmain.local]]] [generic_ext_search_handler] (0x4000): Ref: ldap://DomainDnsZones.dmain.local/DC=DomainDnsZones,DC=dmain,DC=local [sssd[be[dmain.local]]] [generic_ext_search_handler] (0x4000): Ref: ldap://ForestDnsZones.dmain.local/DC=ForestDnsZones,DC=dmain,DC=local [sssd[be[dmain.local]]] [generic_ext_search_handler] (0x4000): Ref: ldap://dmain.local/CN=Configuration,DC=dmain,DC=local [sssd[be[dmain.local]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. [sssd[be[dmain.local]]] [sdap_search_user_process] (0x4000): Retrieved total 1 users [sssd[be[dmain.local]]] [ldb] (0x4000): start ldb transaction (nesting: 0) [sssd[be[dmain.local]]] [sdap_save_user] (0x0400): Save user [sssd[be[dmain.local]]] [sdap_get_primary_name] (0x0400): Processing object usser [sssd[be[dmain.local]]] [sdap_save_user] (0x0400): Processing user usser [sssd[be[dmain.local]]] [sdap_save_user] (0x1000): Mapping user [usser] objectSID [S-1-5-21-299502267-2049760794-725345543-2731019] to unix ID [sssd[be[dmain.local]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-299502267-2049760794-725345543-2731019] to a UNIX ID [sssd[be[dmain.local]]] [sdap_save_user] (0x0020): Failed to save user [usser] [sssd[be[dmain.local]]] [sdap_save_users] (0x0040): Failed to store user 0. Ignoring. [sssd[be[dmain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) [sssd[be[dmain.local]]] [sdap_get_users_done] (0x4000): Saving 1 Users - Done [sssd[be[dmain.local]]] [sdap_id_op_done] (0x4000): releasing operation connection [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x56245b5b9e00 [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x56245b5af0f0 [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. I've read a troubleshooting and corrected values:
https://fedorahosted.org/sssd/wiki/Troubleshooting
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-101891098-1139187330-4192773280-XXXXXX] Where XXXXXX is a number larger than 200000, then check the ldap_idmap_range_size option. You'll likely want to increase its value.
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-101891098-1139187330-4192773280-XXXXXX]
Where XXXXXX is a number larger than 200000, then check the ldap_idmap_range_size option. You'll likely want to increase its value.
XXXXXX = 2731019
so I changed ldap_idmap_range_size:
Now I hit a BUG: Range maximum exceeds the global maximum: 3947265408 > 2000100000 [sssd[be[scpetw2k.local]]] [sdap_idmap_init] (0x0100): Initializing [1] domains for ID-mapping [sssd[be[scpetw2k.local]]] [sdap_idmap_add_domain] (0x1000): Adding domain [S-1-5-21-299502267-2049760794-725345543] as slice [4178] [sssd[be[scpetw2k.local]]] [sdap_idmap_add_domain] (0x0020): BUG: Range maximum exceeds the global maximum: 3947265408 > 2000100000
How should I set ldap_idmap* settings?
Did you clean the sssd cache after changing the range size?
Can you attach your sssd.conf or format the comment better so taht we see which options are in effect?
Of course I cleaned ssd cache from /var/lib/sss/* ...
The problem is, that this is working configuration for other domains.
Everything works, server is joinded to domain, get list of users, authentication through freeradius works..., but uid/gid mapping does not. Same goes with working winbind configuration.
# Samba winbind settings security = ads password server = ad1.scpetw2k.local ad2.scpetw2k.local realm = DMAIN.LOCAL winbind separator=+ winbind:forcesamlogon = True idmap config *:backend = tdb idmap config *:range = 70001-80000 idmap config DMAIN:backend = ad idmap config DMAIN:schema_mode = rfc2307 idmap config DMAIN:range = 500-40000 winbind nss info = rfc2307 winbind trusted domains only = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes
I have this uid/gip mapping problem for this particular domain. I suppose there is problem because last (RID) value of SSID S-1-5-21-299502267-2049760794-725345543 excedes value of 200.000.
Here is sssd.conf:
[sssd] domains = dspot.us config_file_version = 2 services = nss, pam [domain/dmain.local] ad_domain = dmain.local krb5_realm = DMAIN.LOCAL realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad
Can you attach the full SSSD logs to the ticket. The initialization of the idmapping is done during startup where the used parameters are listed as well.
The log sequence with 'Initializing [1] domains for ID-mapping' really indicates that the data for the domain was read from the cache. Although it is mostly recommended to call the sss_cache utility to invalidate the cache the cache must be completely removed with e.g. rm if id-mapping parameters changed. The reason is that for any new domain the mapping data is stored in the cache and used further on to ensure persistent mapping. Unfortunately the data is not complete in the sense that it still depends on setting in sssd.conf and if they change the result might be not consistent anymore. We have to improve this but nevertheless in your case setting 'ldap_idmap_range_size = 3000000', stopping SSSD, removing the cache with 'rm -f /var/lib/sss/db/*' (feel free to backup the data before) and restarting SSSD should fix the mapping issue.
As a final comment, with the shown configuration winbind with read UID and GID data from AD. You can do the same with SSSD if you set 'ldap_id_mapping = False'.
HTH
bye, Sumit
Fields changed
owner: somebody => sbose status: new => assigned
Does the issue still persists after removing the cache with rm or can this ticket be closed?
Please reopen if you can still reproduce the issue after removing the cache with rm. Thank you for reporting the bug.
resolution: => worksforme status: assigned => closed
Metadata Update from @stfast: - Issue assigned to sbose - Issue set to the milestone: NEEDS_TRIAGE
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3825
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.