Bug 587743 - Need to replicate pam_ldap's pam_filter in sssd.conf
Need to replicate pam_ldap's pam_filter in sssd.conf
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Stephen Gallagher
Chandrasekar Kannan
Depends On:
Blocks: 579775 621440
  Show dependency treegraph
Reported: 2010-04-30 14:35 EDT by Marc Riddle
Modified: 2015-01-04 18:42 EST (History)
7 users (show)

See Also:
Fixed In Version: sssd-1.2.0-12.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 621440 (view as bug list)
Last Closed: 2010-11-10 16:39:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marc Riddle 2010-04-30 14:35:29 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Marc Riddle 2010-04-30 14:38:06 EDT
(Sorry about comment 0, hit enter accidentally...)

Our ldap directory contains 'host' attributes for each user, which describe the type(s) of machines a user is permitted to access. A sample user record looks like:

---------------------- snip ----------------------------
dn: uid=mriddle, ou=People, dc=vclk,dc=net
updateBugzillaReference: 11111
userPassword: <-Snip->
loginShell: /bin/bash
gidNumber: 10
uidNumber: 46386
role: all
role: SuperUser
objectClass: account
objectClass: posixAccount
objectClass: vcAccount
objectClass: shadowAccount
uid: mriddle
gecos: 'Marc Riddle (VCLK-Systems)'
shadowLastChange: 1125344839
cn: mriddle
homeDirectory: /home/mriddle
host: la1.prd.core.backup.net.linux
host: la1.prd.core.mgmt.dns.linux
host: la1.prd.core.mgmt.shell.linux
---------------------- snip ----------------------------

with anywhere from zero to hundreds of 'host' entries. Our existing rhel4 and rhel5 hosts have an entry similar to the one below in ldap.conf:

---------------------- snip ----------------------------
pam_filter Host=la1.prd.core.mgmt.shell.linux
---------------------- snip ----------------------------

which only allows users with the correct host attribute to log in.

While attempting to configure sssd against an ldap back end, I needed to replicate this functionality. It would appear that 'ldap_user_search_filter' would be what I'm looking for here. This parameter isn't described in the man page, and since I've been poking at this a while I can't be sure where I found the original reference to it, it may have been in sssd.api.d/sssd-ldap.conf, or while browsing the source. However, it appears as though this parameter isn't used, I was unable to get it to work no matter what values I tried using. 

Presently I'm able to achieve this functionality by what in my opinion is an abuse of another parameter, effectively resulting in a 'ldap injection'. I currently have the following line in sssd.conf:

---------------------- snip ----------------------------
ldap_user_object_class = posixAccount)(Host=la1.prd.core.mgmt.shell.linux
---------------------- snip ----------------------------

which works, but can't be the correct way to accomplish this. Additionally, i can't feel comfortable deploying this configuration as it seems entirely reasonable that a future update will do a stricter job parsing values and prevent this from working.

Due to the lack of thorough documentation on sssd, it's entirely possible that there is a proper way to accomplish this and I've simply missed it. If not, this is an important feature that will prevent us from being able to move to sssd until it is available.
Comment 3 Stephen Gallagher 2010-04-30 15:09:43 EDT
There is no option ldap_user_search_filter. I think you were confusing it with filter_users and ldap_user_search_base. (Neither of these, unfortunately, will help you here).

I'm amused by your ldap injection workaround, but this is probably something we should be sanitizing. So chances are you won't be able to do this in an upcoming release.

Unfortunately, this feature does not exist in the current version of SSSD. I will open it as an enhancement request upstream.

I will add a new option 'ldap_access_filter' that will accept a value of the format "attribute=<value>"
Comment 4 Stephen Gallagher 2010-04-30 15:34:33 EDT
Upstream bug opened: https://fedorahosted.org/sssd/ticket/457
Comment 5 RHEL Product and Program Management 2010-04-30 15:56:19 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
Comment 11 Gowrishankar Rajaiyan 2010-09-22 17:58:44 EDT
Version: sssd-1.2.1-28.el6.
Comment 12 releng-rhel@redhat.com 2010-11-10 16:39:34 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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