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
return-user_unknown.patch

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

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.