#1081 pam_sss should return user_unknown when it can't match pam_ldap_filter
Closed: Invalid None Opened 9 years ago by marcriddle.

I have an internal redhat ticket open on this, but in lieu of fighting back and forth with them I figured I'd go straight to the source. Here's an excerpt from most recent comment from that ticket, which I think does a pretty good job explaining my issue:


Kindly note that the pam_filter does not affect user lookup, it only comes into picture when the account section is called(ie; authorization), so the user is known to pam_ldap.
In pam_ldap.c, _get_user_info(), specifically line 2693 (from nss_ldap-253-37.el5) , returns a PAM_USER_UNKNOWN if it is unable to match an ldap lookup that includes the pam_filter. This wi
ll be called whether the pam type is auth, account, or session.

We then determine access based on the validity of the password section just below that. However, pam_sss returns a value equivalent to "PAM_PERM_DENIED" causing the account to be rejec
ted at that line>> The password section is read/used only during a password change, normal authentication/authorization process are not affected by the entries in password section.

This was a misstatement by my colleague, however the general idea is still accurate. While the 'password' pam type is only used for password changes, when using our pam configs described below pam_ldap returns a user_unknown in the 'account' type, resulting in an eventual login failure for users not matching the pam_filter at the pam_ldap 'session' pam type several lines lowe
r. This is different from pam_sss's behavior, where pam fails at the 'account' type.

It's worth pointing out that the stock redhat pam configs appear to expect modules (or at least pam_sss) to behave similarly to pam_ldap. If you look at the pam config from the attached sos
report, you'll see the below two files:
There are a couple specific lines that are worth taking note of here. The most obvious is the pam_succeed_if.so line in the 'session' section. This is there to ensure that pam is allowed to
succeed even if pam_sss fails when the service being requested is crond. If you believe that pam_sss's behavior is correct, can you explain to me why a stock config as created by authconfi
g would skip pam_sss's authentication for the crond service? It seems to me that the reason for this line is the exact case we're dealing with here, which if pam_sss were replaced with pam_
ldap and no other changes were made, would allow cron jobs for users not matching the ldap_filter to run, assuming that they were allowed access in access.conf.

I believe the behavior of pam_sss is correct here, anyway I'll check with senior member and get back to you with more details.

If nothing else, the behavior of pam_sss is inconsistent with pam_ldap's behavior.


I've thrown together a quick patch which I believe better mimics pam_ldap's behavior here, and attached it to this ticket (basically just changes the return value for an unmatched search with a filter). I'm not sure if this is the preferred place to fix it, but it seemed reasonable based on a quick browsing of sssd's source.

Note that this is a patch against redhat's 1.5.1-34el6, it's simple enough that I didn't bother making a new version for the current release

Would you mind including a link to the RHEL bug? I don't see it in Bugzilla.

We will assess the patch in 1.7.

milestone: NEEDS_TRIAGE => SSSD 1.7.0

Fields changed

owner: somebody => sgallagh

I was thinking about this earlier and realized that this ticket is pretty short on details without access to the redhat ticket. I don't have a publicly viewable redhat bugzilla ticket, the internal redhat issue tracker case number is 00557961 if that is of any use.

I can provide a bit more detail, and maybe best of all, an easy reproducer that should make this more clear.

We use pam_access to restrict which accounts can run cron jobs on our servers, by adding a line similar to:
-:ALL EXCEPT root nagios munin cacti:cron
to access.conf.

On our rhel5 machines using pam_ldap, this allows all users listed in this line to run cron jobs. however, we found that on rhel6 boxes using pam_sss, only some of the users worked. Further investigation found that is a user had a local passwd entry, they worked, but a user that only existed in ldap did not. We initially looked at pam_access, but early on ruled that out as the problem, and focused on pam_sss. For testing, we removed all references to pam_access to ensure that this didn't confuse things.

We use an ldap_access_filter of 'Host=$hostname' in sssd to limit which users can log into a server, and do not add this attribute for role/service accounts like 'nagios' or 'munin', as we do not want them to be able to log into a server, but we do need them to run cron jobs.

If you take a stock rhel6 pam config as created by authconfig (using '--enablesssd' and '--enablesssdauth'), add an ldap_access_filter that a role account doesn't have, and try to 'sudo crontab -l -u $account', it will succeed for an account that exists in /etc/passwd and fail for one that exists in ldap. If you then replace pam_sss with pam_ldap in the pam configs and make no other changes, the same command will succeed for both users.

Let me know if that is at all unclear, it's pretty straightforward but feels a little clumsy to explain.

So I did a little digging today (as well as having a long talk with the pam_ldap maintainer).

Basically, the fact that pam_ldap returns PAM_USER_UNKNOWN here is because, given the way it's designed, they don't actually have enough information to determine success or failure in terms of access-control.

Basically, pam_ldap uses the pam_filter option as a filter on all of its lookups internally, which means that it cannot differentiate between "user is nonexistent" and "user exists but is missing this attribute".

The architecture of SSSD is such that we DO have access to this information. For us, we'll only return PAM_USER_UNKNOWN if our initial check of the user using ldap_user_search_filter (or, on the upcoming SSSD 1.7.0 using the new multiple ldap_search_base feature). So we always know that the user is there. We can then determine that an additional filtered search on this user means that the intended attribute is not present, and that we should therefore deny access.

The literal meaning of PAM_USER_UNKNOWN is that the PAM module is replying that it has no knowledge of the user in question. This is done so that the PAM stack can be configured how to deal with it (i.e. whether the lack of this knowledge should be ignored or treated as a failure).

In pam_ldap's case, since all of the lookups are done with the filter applied, they have no ability to determine if it's properly a denial or a missing user. So they treat it as a missing user. Since SSSD has the capability to know this for certain, we always return the definitive answer.

I have to say here that we're functioning as designed. In order to accomplish what you're looking for here, I'd say you should just add a line

account sufficient pam_succeed_if service in crond quiet

just before the pam_sss line in the account stack.

That's reasonable, and a good explanation. Thanks for the quick response.

I'm curious to know if you think that this should be added as a default to authconfig then run with '--enablesssd', it feels that way to me given the similar pam_succeed_if 'session' line that authconfig adds.

That last comment should have read ...'default to authconfig when run with'...

That's probably a better question to ask the authconfig upstream, rather than here.

I will say that in general, I'm not sure what you're doing is something we want to treat as a "standard" case. It really sounds more like an exception to me.

The design of the default PAM stack should (to me at least) be that all PAM services get equal treatment with regard to access-control (aka pam_acct_mgmt). It certainly strikes me as odd that a user with no privilege to log into the machine has privilege to run cron jobs on that machine. I'd be curious to hear the reasoning for it (as well as how those cron jobs even get there).

Since I think we have an understanding of the situation here, I'm going to mark the bug as WONTFIX. (If you have other comments, you can still add them).

resolution: => wontfix
status: new => closed

Metadata Update from @marcriddle:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.7.0

3 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to 0

3 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to 0

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2123

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.