Bug 1372814
| Summary: | sssd isn't able to find autofs maps in LDAP | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Kent Perrier <kperrier> |
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Steeve Goveas <sgoveas> |
| Severity: | high | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
| Priority: | high | ||
| Version: | 7.3 | CC: | grajaiya, jhrozek, kperrier, lslebodn, mkosek, mzidek, pbrezina, rrauenza |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
SSSD fails to manage autofs mappings from a LDAP tree
Previously, the System Security Services Daemon (SSSD) implemented incorrect default values for autofs mappings when using the `RFC2307` LDAP schema. A patch has been applied, which fixed the defaults to match the schema. However, users connecting to LDAP servers that contain mappings with the schema SSSD previously used, are not able to load the autofs attributes. Affected users see the following error reported in the `/var/log/messages` log file:
Your configuration uses the autofs provider with schema set to rfc2307 and default attribute mappings. The default map has changed in this release, please make sure the configuration matches the server attributes.
To work around this problem, modify the `/etc/sssd/sssd.conf` file and set your domain to use the existing attribute mappings:
[domain/EXAMPLE]
...
ldap_autofs_map_object_class = automountMap
ldap_autofs_map_name = ou
ldap_autofs_entry_object_class = automount
ldap_autofs_entry_key = cn
ldap_autofs_entry_value = automountInformation
As a result, SSSD is able to load autofs mappings from the attributes.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-09-06 20:14:15 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
Kent Perrier
2016-09-02 19:00:31 UTC
(In reply to Kent Perrier from comment #0) > Description of problem: > Customer built new RHEL 7.3 beta server with their standard config that > works for RHEL 7.2. SSSD can't find the autofs automount maps in LDAP. A > query with ldapsearch shows the map that is returned. > > Version-Release number of selected component (if applicable): > sssd-1.14.0-27.el7.x86_64 > sssd-ad-1.14.0-27.el7.x86_64 > sssd-client-1.14.0-27.el7.i686 > sssd-client-1.14.0-27.el7.x86_64 > sssd-common-1.14.0-27.el7.x86_64 > sssd-common-pac-1.14.0-27.el7.x86_64 > sssd-ipa-1.14.0-27.el7.x86_64 > sssd-krb5-1.14.0-27.el7.x86_64 > sssd-krb5-common-1.14.0-27.el7.x86_64 > sssd-ldap-1.14.0-27.el7.x86_64 > sssd-proxy-1.14.0-27.el7.x86_64 > > How reproducible: > > attempt to connect an automounted NFS filesystem > > Steps to Reproduce: > 1. build server to use LDAP for automount maps > 2. try to access automounted directories I tested and it works for me. Please provide better steps to reproduce. + provide log files with high debug_level in domain and autofs section of sssd.conf + expected¤t output of "automount -m" You can find info about how to report a bug report with the information we need here: https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs OK, I looked into the case and this seems to be a side-effect of changing the defaults in 1.14 which the customer noticed in the case, but said changing the mappings to match what's on the server didn't make a difference. Can we see logs from configuration where the attribute mappings match the autofs maps? Thank you. It might be helpful (it was for me), but this is the relevant part of the sssd source change: curl -s https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/ZN6VMFN65JWV7NMG2XEHPUI2AGSLRNGW/attachment/2/0001-LDAP-Change-the-default-rfc2307-autofs-attribute-map.patch | grep '^[+-] *{ "' | LC_COLLATE=C sort + { "ldap_autofs_entry_object_class", "nisObject", SYSDB_AUTOFS_ENTRY_OC, NULL }, + { "ldap_autofs_entry_value", "nisMapEntry", SYSDB_AUTOFS_ENTRY_VALUE, NULL }, + { "ldap_autofs_map_name", "nisMapName", SYSDB_AUTOFS_MAP_NAME, NULL }, + { "ldap_autofs_map_object_class", "nisMap", SYSDB_AUTOFS_MAP_OC, NULL }, - { "ldap_autofs_entry_object_class", "automount", SYSDB_AUTOFS_ENTRY_OC, NULL }, - { "ldap_autofs_entry_value", "automountInformation", SYSDB_AUTOFS_ENTRY_VALUE, NULL }, - { "ldap_autofs_map_name", "ou", SYSDB_AUTOFS_MAP_NAME, NULL }, - { "ldap_autofs_map_object_class", "automountMap", SYSDB_AUTOFS_MAP_OC, NULL }, The strings on the left are configuration entries in sssd.conf. The '-' lines are the old default, the '+' lines are the new default. (I'm not sure why the docs above also include ldap_autofs_entry_key) (In reply to Rich Rauenzahn from comment #12) > It might be helpful (it was for me), but this is the relevant part of the > sssd source change: > > curl -s > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted. > org/message/ZN6VMFN65JWV7NMG2XEHPUI2AGSLRNGW/attachment/2/0001-LDAP-Change- > the-default-rfc2307-autofs-attribute-map.patch | grep '^[+-] *{ "' | Here is a better link to commit https://git.fedorahosted.org/cgit/sssd.git/commit/?id=999d6066c7a96f102b692d31435d76114478e874 Thanks! Given the scope of this change (and the negative repercussions to production environments), I am surprised that instead a new schema profile wasn't created, say, 'legacy', and either the documentation updated to point people to that schema, or to change the default to legacy. Is it too late to consider this? (probably is too late to make legacy the default since that ship has sailed...), but would it be helpful for transitions to make a 'legacy' profile/schema that represents the old default? |