(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&current 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?