Bug 587743

(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.

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>"

Upstream bug opened: https://fedorahosted.org/sssd/ticket/457

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
inclusion.

Verified. 
Version: sssd-1.2.1-28.el6.

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.