#853 [RFE] Better error messages when a user is denied by the simple access provider
Closed: Fixed Opened by sejeff.

Given a configuration like this:

[domain/LDAP]
auth_provider = ldap
access_provider = simple
simple_allow_users = jschroeder
simple_allow_groups = admin

When trying to login as a user other than "jschroeder" who is not in the admin group, it properly denies the user, but the logs just show a System error such as:
pam_sss(sshd:account): Access denied for user ssmith2: 4 (System error)

Could this be made a bit more human friendly for those of us who have automated methods in place to grok logs?


Can you please give an example of the message that you would expect in such case?

Good question. Anything other than "System Error" seems good to me.

For comparison, a pam_access deny looks like this:
<83> Apr 25 11:05:37.419230 -07:00 dev022.lax04.int sshd[13288]: pam_access(sshd:account): access denied for user `testuser' from `jschroeder2.lax01.int'
<82> Apr 25 11:05:37.420846 -07:00 dev022.lax04.int sshd[13291]: fatal: Access denied for user testuser by PAM account configuration

That output at least tells me that it is pam_access denying the login and greatly helps with troubleshooting. Do you have any ideas? Perhaps there is an easy way to reference the simple access provider in that?

Fields changed

description: Given a configuration like this:

[domain/LDAP]
auth_provider = ldap
access_provider = simple
simple_allow_users = jschroeder
simple_allow_groups = admin

When trying to login as a user other than "jschroeder" who is not in the admin group, it properly denies the user, but the logs just show a System error such as:
pam_sss(sshd:account): Access denied for user ssmith2: 4 (System error)

Could this be made a bit more human friendly for those of us who have automated methods in place to grok logs? => Given a configuration like this:
{{{
[domain/LDAP]
auth_provider = ldap
access_provider = simple
simple_allow_users = jschroeder
simple_allow_groups = admin
}}}

When trying to login as a user other than "jschroeder" who is not in the admin group, it properly denies the user, but the logs just show a System error such as:
pam_sss(sshd:account): Access denied for user ssmith2: 4 (System error)

Could this be made a bit more human friendly for those of us who have automated methods in place to grok logs?

I just attempted to reproduce your complaint and got:

Apr 25 14:28:02 sgallagh su: pam_sss(su-l:auth): authentication success; logname=sgallagh uid=<redacted> euid=0 tty=pts/2 ruser=sgallagh rhost= user=sgallagh
Apr 25 14:28:02 sgallagh su: pam_sss(su-l:account): Access denied for user sgallagh: 6 (Permission denied)

You should actually NEVER see "System Error" there unless there was an internal error. If you're seeing that consistently, it probably indicates a bug. I'd like to see some logs in this case.

Fields changed

version: 1.5.6 => 1.5.4

I spent some time today debugging this with Jeff on IRC.

The root cause of the problem is that his users have a non-LDAP primary group. So when we attempt to look up their primary group in the cache for authorization, we cannot find it and throw an error.

We need to make the primary group lookup a best-effort.

component: SSSD => Simple Provider
owner: somebody => sgallagh
status: new => assigned

Fields changed

patch: 0 => 1

With the patch applied, the error looks more reasonable:

<85> Apr 25 13:24:30.079061 -07:00 dev022.lax04.int sshd[20281]: pam_sss(sshd:account): Access denied for user testuser: 6 (Permission denied)

Thanks for the quick turnaround!

Fixed by 2ffb41c6a16892fccc39fcae7f203bccb8c72dfc

milestone: NEEDS_TRIAGE => SSSD 1.6.0
priority: trivial => major
resolution: => fixed
status: assigned => closed

Backported to sssd-1-5

6a21eb70c4d2b5b64aa52af9e8690eb68ccbdd76

milestone: SSSD 1.6.0 => SSSD 1.5.8
rhbz: =>

Fields changed

rhbz: => 0

Metadata Update from @sejeff:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.5.8

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/1895

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.

Metadata