Bug 1116758
Summary: | ldap_id_mapping = False causes SSSD service startup failure | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Cowley <chris> | ||||||
Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> | ||||||
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 20 | CC: | abokovoy, chris, iain.t.morris, jhrozek, john.w.baird, lslebodn, pbrezina, preichl, sbose, sgallagh, ssorce, viggiani | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2014-09-10 08:30:57 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Chris Cowley
2014-07-07 09:02:13 UTC
Could you upload your sssd.conf? You can make attachment private. You can also try to add "debug_level = 9" into AD domain section and you should see more verbose debug messages in sssd log files. I actually have the same issue. Below is my entire sssd.conf file. Any assistance would be great! Thanks! ##### [sssd] services = nss,pam,ssh,autofs config_file_version = 2 domains = CORP.VMWARE.LOCAL [domain/CORP.VMWARE.LOCAL] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ad_server = dc01.corp.vmware.local ad_hostname = ipa01.corp.vmware.local ad_domain = corp.vmware.local ldap_id_mapping = False ldap_schema = ad cache_credentials = true ldap_disable_referrals = true debug_level = 9 [pam] reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 ###### Created attachment 924249 [details]
Centos 6 SSSD.CONF
I just wanted to actually attach my sssd.conf file as requested. Also, I have compiled the sssd-1.11.6 RPM for Centos 6 from source and I have the same issue that is seen in the FC20 RPM.
Can you also attach the logs we requested with debug_level=9 The config file looks good to me and I was able to run sssd just fine with a similar one.. Created attachment 924473 [details]
SSSD Debug Domain Log
Added debug_level = 9 to start up. Nuked logs prior to service start attempt so everything in the log is directly from the failed start attempt. No other files had any logging associated with them.
@jakub, have you been able to take a look at this? I am hoping to test a 1.10 release of sssd to see if that cleans it up. I will let you know what I find. Thanks for your help! I don't have much more to add but to say this is happening to me on a CentOS 7 system attaching to an AD domain with Identity Management for Unix extensions. Almost identical sssd.conf config to the users above. Switching to ldap_id_mapping = True removes the problem and all AD users are available, but using AD sid mapping rather than POSIX. Relevant versions: rpm -qa | grep sssd sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 (In reply to John Baird from comment #5) > Created attachment 924473 [details] > SSSD Debug Domain Log > > Added debug_level = 9 to start up. Nuked logs prior to service start > attempt so everything in the log is directly from the failed start attempt. > No other files had any logging associated with them. I would like to apologise for late reply. I checked log files and this art is interesting and at least we need to improve logging [sysdb_idmap_get_mappings] (0x4000): cn=id_mappings,cn=CORP.VMWARE.LOCAL,cn=sysdb [sdap_idmap_init] (0x0100): Initializing [1] domains for ID-mapping [sdap_idmap_add_domain] (0x0020): Could not add domain [CORP.VMWARE.LOCAL] to the map: [11] If I read source code correctly, return code 11 means: New domain collides with existing one [sdap_idmap_init] (0x0020): Could not add domain [CORP.VMWARE.LOCAL][S-1-5-21-71412705-2218169384-2449183948][6147] to ID map: [Input/output error] In sssd.conf, option ldap_id_mapping is disabled, but there is old idmapping range in sssd cachec. Could you try to: * remove file rm -f /var/lib/sssd/db/* * start sssd one more time. (In reply to Lukas Slebodnik from comment #8) > In sssd.conf, option ldap_id_mapping is disabled, but there is old idmapping > range in sssd cachec. > > Could you try to: > * remove file rm -f /var/lib/sssd/db/* > * start sssd one more time. This fixed the problem for me. Thank you for your time on this. (In reply to Iain Morris from comment #9) > (In reply to Lukas Slebodnik from comment #8) > > > In sssd.conf, option ldap_id_mapping is disabled, but there is old idmapping > > range in sssd cachec. > > > > Could you try to: > > * remove file rm -f /var/lib/sssd/db/* > > * start sssd one more time. > > > This fixed the problem for me. Thank you for your time on this. BTW it is already documented in manual page. man sssd-ldap -> ID MAPPING -> (3rd paragraph) Please note that changing the ID mapping related configuration options will cause user and group IDs to change. At the moment, SSSD does not support changing IDs, so the SSSD database must be removed... Do you have the same problem as John Baird described in Comment 8 ? I'm sorry for the late response. I did not have the sssd debug logs turned up as high as John Baird's output so it's difficult to say if it is the same problem scanning through his attachment. The sssd service simply wouldn't start with ldap_id_mapping enabled. It would be interesting to know if his problem was resolved with clearing out the sssd db directories. Thanks again. The system is now in production so I can't change it back to troubleshoot this with you, unfortunately. I am pretty sure it will help; this is a reason why it is written in manual pages (@see Comment 10) Kindly reopen the bug if you believe removing the cache didn't fix your problem. We are experiencing same bug and removing the cache doesn't fix the problem. Any help? (In reply to Mimmus from comment #15) > We are experiencing same bug and removing the cache doesn't fix the problem. > Any help? In this case, you are hitting another bug. See comment 10. Feel free to open another BZ with attached log files. |