Bug 822404 - sssd does not provide maps for automounter when custom schema is being used
sssd does not provide maps for automounter when custom schema is being used
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
Unspecified Unspecified
high Severity low
: rc
: ---
Assigned To: Jakub Hrozek
Kaushik Banerjee
Depends On: 820979
Blocks: 782183
  Show dependency treegraph
Reported: 2012-05-17 05:42 EDT by Jakub Hrozek
Modified: 2014-07-23 04:19 EDT (History)
9 users (show)

See Also:
Fixed In Version: sssd-1.9.1-1.el6
Doc Type: Bug Fix
Doc Text:
C: The SSSD did not use the correct attribute mapping when a custom schema was used. C: If the administrator configured SSSD with custom attribute map, the autofs integration didn't work F: The attribute mapping was fixed R: The SSSD now works even with a custom attribute schema
Story Points: ---
Clone Of: 820979
Last Closed: 2013-02-21 04:23:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0508 normal SHIPPED_LIVE Low: sssd security, bug fix and enhancement update 2013-02-20 16:30:10 EST

  None (edit)
Description Jakub Hrozek 2012-05-17 05:42:46 EDT
+++ This bug was initially created as a clone of Bug #820979 +++

Description of problem:
sssd does not provide maps for automounter when AD schema (RFC2307) is being used.
My config:

[root@dorado3 ~]# ldbsearch -H /var/lib/sss/db/config.ldb
server_sort:Unable to register control with rootdse!
# record 1
dn: cn=default,cn=domain,cn=config
auth_provider: krb5
autofs_provider: ldap
cache_credentials: True
chpass_provider: krb5
cn: default
debug_level: 17
dns_discovery_domain: Prague._sites.dublin.ad.s3group.com
id_provider: ldap
krb5_canonicalize: False
krb5_renew_interval: 3600
krb5_renewable_lifetime: 30d
ldap_autofs_entry_key: cn
ldap_autofs_entry_object_class: nisObject
ldap_autofs_entry_value: nisMapEntry
ldap_autofs_map_name: nisMapName
ldap_autofs_map_object_class: nisMap
ldap_autofs_search_base: CN=prague,CN=NIS,DC=dublin,DC=ad,DC=s3group,DC=com
ldap_group_object_class: group
ldap_id_use_start_tls: False
ldap_sasl_authid: DORADO3$@DUBLIN.AD.S3GROUP.COM
ldap_sasl_mech: GSSAPI
ldap_schema: rfc2307bis
ldap_search_base: dc=dublin,dc=ad,dc=s3group,dc=com
ldap_tls_cacertdir: /etc/openldap/cacerts
ldap_user_home_directory: unixHomeDirectory
ldap_user_object_class: user
distinguishedName: cn=default,cn=domain,cn=config

# record 2
dn: cn=sssd,cn=config
cn: sssd
config_file_version: 2
debug_level: 17
domains: default
services: nss, pam, autofs
distinguishedName: cn=sssd,cn=config

# record 3
dn: cn=config
version: 2
lastUpdate: 1336729570
distinguishedName: cn=config

# record 4
dn: cn=nss,cn=config
cn: nss
distinguishedName: cn=nss,cn=config

# record 5
dn: cn=example.com,cn=domain,cn=config
access_provider: ipa
auth_provider: ipa
cache_credentials: True
chpass_provider: ipa
cn: example.com
id_provider: ipa
ipa_domain: example.com
ipa_server: _srv_, polaris.example.com
distinguishedName: cn=example.com,cn=domain,cn=config

# record 6
dn: cn=autofs,cn=config
cn: autofs
debug_level: 10
distinguishedName: cn=autofs,cn=config

# record 7
dn: cn=pam,cn=config
cn: pam
distinguishedName: cn=pam,cn=config

# returned 7 records
# 7 entries
# 0 referrals

The sssd_default.log shows that maps were found successfully, but no maps are located in sssd cache as per:

ldbsearch -H /var/lib/sss/db/cache_default.ldb '(|(objectclass=nisMap)(objectclass=nisObject))'

Version-Release number of selected component (if applicable):
[root@dorado3 ~]# rpm -qa | grep sss

How reproducible:

Steps to Reproduce:
1. configure automounter to get maps from sss
2. try 'automount -m'
Actual results:
Maps should be visible in the output

Expected results:
no maps are seen

Additional info:

--- Additional comment from sgallagh@redhat.com on 2012-05-14 08:51:23 EDT ---

Upstream ticket:

--- Additional comment from jhrozek@redhat.com on 2012-05-15 10:18:24 EDT ---

(In reply to comment #0)
> ldbsearch -H /var/lib/sss/db/cache_default.ldb
> '(|(objectclass=nisMap)(objectclass=nisObject))'

This search wouldn't return anything, because even if you override the default attributes in the SSSD config file, the SSSD internally translates them into harcoded cache attributes.

What you want to run is:
# ldbsearch -H /var/lib/sss/db/cache_ipaldap.ldb '(|(objectclass=automount)(objectclass=automountMap))'

Also, can you include a more complete log (than the one sent privately) ?  In the domain log, I'm interested in everything between "be_autofs_handler" until "be_autofs_handler_callback".

That should tell us whether the back end saves the data correctly into the cache and whether we should be looking at a bug in the responder or in the back end next.

--- Additional comment from jhrozek@redhat.com on 2012-05-15 10:20:35 EDT ---

(In reply to comment #2)
> # ldbsearch -H /var/lib/sss/db/cache_ipaldap.ldb

Err, obviously, replace the path to a real one to your cache. Sorry.

--- Additional comment from ondrejv@s3group.cz on 2012-05-16 10:24:06 EDT ---

Requested details were sent privately by mail.
Comment 1 Jakub Hrozek 2012-05-17 05:43:46 EDT
A patch is available upstream, very low risk (one-liner).

Ondrej confirmed privately that the patch provided in a Koji scratch build fixed the issue for him.
Comment 8 Kaushik Banerjee 2012-11-21 11:51:00 EST
Verified in version 1.9.2-21

Output of beaker automation run:
:: [   LOG    ] :: autofs7 - bz822404 non-default values of all ldap attributes

Stopping sssd:                                             [  OK  ]
Starting sssd:                                             [  OK  ]
:: [21:57:44] ::  Sleeping for 5 seconds
:: [   PASS   ] :: File '/var/log/sssd/sssd_LDAP.log' should contain 'Option ldap_autofs_map_object_class has value nisMap'
:: [   PASS   ] :: File '/var/log/sssd/sssd_LDAP.log' should contain 'Option ldap_autofs_map_name has value nisMapName'
:: [   PASS   ] :: File '/var/log/sssd/sssd_LDAP.log' should contain 'Option ldap_autofs_entry_object_class has value nisObject'
:: [   PASS   ] :: File '/var/log/sssd/sssd_LDAP.log' should contain 'Option ldap_autofs_entry_key has value cn'
:: [   PASS   ] :: File '/var/log/sssd/sssd_LDAP.log' should contain 'Option ldap_autofs_entry_value has value nisMapEntry'

autofs dump map information

global options: none configured

Mount point: /export/home


  instance type(s): sss 
  map: auto.home

  * | -fstype=nfs,rw kau63.kautest.com:/export/home/&

Mount point: /-


  instance type(s): sss 
  map: auto.direct

  /proj1 | -fstype=nfs,rw kau63.kautest.com:/export/project1
  /directtest | -fstype=nfs,rw kau63.kautest.com:/export/directtest1
  /folder1/folder2/projects | -fstype=nfs,rw kau63.kautest.com:/export/projects
  /proj2 | -fstype=nfs,rw kau63.kautest.com:/export/project2

Mount point: /share1


  instance type(s): sss 
  map: auto.share1

  key1 | -fstype=nfs,rw kau63.kautest.com:/export/shared1/key1
  key2 | -fstype=nfs,rw kau63.kautest.com:/export/shared1/key2

Mount point: /share2


  instance type(s): sss 
  map: auto.share2

  key1 | -fstype=nfs,rw kau63.kautest.com:/export/shared2/key1

:: [   PASS   ] :: Running 'automount -m'
Comment 9 errata-xmlrpc 2013-02-21 04:23:47 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.