Bug 1412170
| Summary: | sssd segfaults when /etc/sssd/conf.d permissions are incorrect | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jason <ashbyj> |
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Steeve Goveas <sgoveas> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-11 13:35:40 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: | |||
|
Description
Jason
2017-01-11 12:45:42 UTC
Sorry, the Description of Problem should read: .../var/log/sssd/sssd.log indicates a permission denied error with /etc/sssd/conf.d. I not think that crash is related to this directory crash is in sssd_be. And this process does not touch it. I would say it's a duplicate of https://fedorahosted.org/sssd/ticket/3234 BZ1392444. it's caused by id_provider = ad and auth_provider = krb5. Could you share your sssd.conf? And about conf.d Could you provide an output of following commands: sh# ls -ld /etc/sssd/conf.d sh# rpm -V sssd-common Ah yes, the permissions thing was a red herring. auth_provider = krb5 was the problem. I removed it from sssd.conf and sssd starts up fine. I left id_provider = ad in place and it works OK. Should I remove the id_provider line as well? (In reply to Jason from comment #4) > Ah yes, the permissions thing was a red herring. auth_provider = krb5 was > the problem. I removed it from sssd.conf and sssd starts up fine. > auth_provider is inherited from id_provider by defualt > I left id_provider = ad in place and it works OK. Should I remove the > id_provider line as well? NO. and could you provide an output of requested commands for issue with directory? # ls -ld /etc/sssd/conf.d drwx--x--x. 2 sssd sssd 6 Jan 11 08:01 /etc/sssd/conf.d # rpm -V sssd-common # # rpm -qa sssd sssd-1.14.0-43.el7_3.4.x86_64 Just an FYI, removing auth_provider = krb5 breaks authentication on servers running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't backward compatible. Explicitly saying auth_provider = ad breaks it as well. Its fine, I just have to work around it in puppet until I get all of our servers updated to sssd 1.14. *** This bug has been marked as a duplicate of bug 1396485 *** (In reply to Jason from comment #7) > Just an FYI, removing auth_provider = krb5 breaks authentication on servers > running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't > backward compatible. Explicitly saying auth_provider = ad breaks it as well. > Its fine, I just have to work around it in puppet until I get all of our > servers updated to sssd 1.14. Auth_provider ad should work 1.13. You might try to find a reason why auth_provider ad does not work https://fedorahosted.org/sssd/wiki/Troubleshooting But fix for BZ1396485 should be released soon and auth_provider = krb5 should work with id_provider ad also with 1.14 (In reply to Lukas Slebodnik from comment #9) > (In reply to Jason from comment #7) > > Just an FYI, removing auth_provider = krb5 breaks authentication on servers > > running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't > > backward compatible. Explicitly saying auth_provider = ad breaks it as well. > > Its fine, I just have to work around it in puppet until I get all of our > > servers updated to sssd 1.14. > > Auth_provider ad should work 1.13. You might try to find a reason why > auth_provider ad does not work > https://fedorahosted.org/sssd/wiki/Troubleshooting > most probably because of ccache validation -> krb5_validate=false should work around the issue. I don't know why would 1.14 work, but maybe disabling validation on the old serves might help (please read the description of krb5_validate in the man pages, though). If you were already using krb5 auth provider, then you don't lose anything by going with ad auth provider and disabled validation as krb5 auth provider doesn't use the validation by default. > But fix for BZ1396485 should be released soon and auth_provider = krb5 > should work with id_provider ad also with 1.14 (In reply to Jakub Hrozek from comment #10) > (In reply to Lukas Slebodnik from comment #9) > > (In reply to Jason from comment #7) > > > Just an FYI, removing auth_provider = krb5 breaks authentication on servers > > > running an older sssd (1.13.0-40.el7_2.12), so this workaround isn't > > > backward compatible. Explicitly saying auth_provider = ad breaks it as well. > > > Its fine, I just have to work around it in puppet until I get all of our > > > servers updated to sssd 1.14. > > > > Auth_provider ad should work 1.13. You might try to find a reason why > > auth_provider ad does not work > > https://fedorahosted.org/sssd/wiki/Troubleshooting > > > > most probably because of ccache validation -> krb5_validate=false should > work around the issue. I don't know why would 1.14 work, but maybe disabling > validation on the old serves might help (please read the description of > krb5_validate in the man pages, though). > > If you were already using krb5 auth provider, then you don't lose anything > by going with ad auth provider and disabled validation as krb5 auth provider > doesn't use the validation by default. > It does not explain why "auth_provider ad" works with 1.14 and does not work with 1.13 krb5_validate is true in both cases for AD For completeness, here is my sssd.conf BEFORE making any changes today: # cat /etc/sssd/sssd.conf [sssd] domains = dc.example.com config_file_version = 2 services = nss, pam, ssh, autofs [domain/dc.example.com] ad_server = ad01.dc.example.com ad_domain = dc.example.com krb5_realm = DC.EXAMPLE.COM realmd_tags = manages-system joined-with-adcli cache_credentials = false id_provider = ad auth_provider = krb5 krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False fallback_homedir = /home/%u access_provider = ad use_fully_qualified_names = False ad_gpo_access_control = disabled client_idle_timeout = 76 enumerate = true Yes, disabling validation with krb5_validate=false fixed it so that I could apply the workaround on the old servers. (In reply to Jason from comment #13) > Yes, disabling validation with krb5_validate=false fixed it so that I could > apply the workaround on the old servers. You should rather find out why validation failed with old sssd. "krb5_validate=false" should be used just for testing purposes. Especially because you have a keytab; I assume machine was enrolled with realmd due to option realmd_tags. |