Please include sssd_pam.log, setting {{{debug_level = 7}}} in the {{{[pam]}}} section of {{{sssd.conf}}}. The PAM provider should be detecting that this user does not belong to any of its domains before it ever gets to the HBAC resolution. I'd like to see why it thinks this user belongs to the expertcity.com domain.

description: When used in conjunction with FreeIPA, SSSD is processing local user accounts during ssh login and rejecting them.

Users are below the ignore min uid range.

I can verify that getent passwd -s sssd jr does not exist, which should cause SSSD Pam to ignore him when Pam-unix passes the auth phase. Instead, he gets processed as if he were a FreeIPA user:

(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [sysdb_search_user_by_name] (0x0400): No such entry
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [hbac_eval_user_element] (0x0020): Could not determine user memberships for [jr]
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)]
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][expertcity.com]
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][expertcity.com]
(Mon Jan 23 07:54:58 2012) [sssd[be[expertcity.com]]] [sdap_id_conn_data_expire_handler => When used in conjunction with FreeIPA, SSSD is processing local user accounts during ssh login and rejecting them.

Users are below the ignore min uid range.

I can verify that getent passwd -s sssd jr does not exist, which should cause SSSD Pam to ignore him when Pam-unix passes the auth phase. Instead, he gets processed as if he were a FreeIPA user:

{{{
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [sysdb_search_user_by_name] (0x0400): No such entry
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [hbac_eval_user_element] (0x0020): Could not determine user memberships for [jr]
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)]
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][expertcity.com]
(Mon Jan 23 07:54:44 2012) [sssd[be[expertcity.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][expertcity.com]
(Mon Jan 23 07:54:58 2012) [sssd[be[expertcity.com]]] [sdap_id_conn_data_expire_handler
}}}

btw JR confirmed off-list that he tested that the user does not exist in a sssd domain by correctly running "getent passwd -s sss jr", not "-s sssd".

attachment
sssd_domain.log

This issue also appears to effect Cron:

CRON (username) ERROR: cannot set security context

attachment
pam.d-system-auth

Domain log
sssd_expertcity.com.log

New Pam log
sssd_pam.log

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.0 NEEDS_TRIAGE

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=784864

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=784864 784864]

Fields changed

milestone: SSSD 1.9.0 NEEDS_TRIAGE => NEEDS_TRIAGE

Fields changed

feature_milestone: =>
milestone: NEEDS_TRIAGE => SSSD 1.8.0 (LTM)

I suspect this was either fully or partially solved by my patch ab2d04a1c6c8b2a618813f3e066de0e2b07f44e9

Picking up for further investigation.

owner: somebody => jhrozek

Looking at these logs, this doesn't actually appear to be a case of SSSD incorrectly answering a request for an unknown user. From the logs posted, it appears that sssd_pam has actually crashed twice, once at {{{Wed Jan 25 09:05:57 2012}}} and again at {{{Wed Jan 25 09:06:02 2012}}}

What we really need here is a backtrace from the crash.

I'm going to attempt to replicate the situation, but if I can get a backtrace from JR in the meantime, that would be very helpful.

owner: jhrozek => sgallagh
status: new => assigned

I set up a client on Fedora 16 running sssd-1.7.0-5.fc16.x86_64 using ipa-client-install (I took all of the defaults, having pointed /etc/resolv.conf at the IPA server's DNS instance).

I then attempted to log into the machine using a local user, not an IPA user. This succeeded both with a private-key authentication and a PAM password authentication.

Looking in the logs, SSSD was indeed contacted for the pam_acct_mgmt phase, but properly returned "unknown user":

(Wed Feb 22 20:53:39 2012) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [sgallagh@services]
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x1420d00
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x1420e20
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [ldb] (0x4000): tevent: Destroying timer event 0x1420e20 "ltdb_timeout"
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [ldb] (0x4000): tevent: Ending timer event 0x1420d00 "ltdb_callback"
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [pam_check_user_search] (0x0040): No matching domain found for [sgallagh], fail!
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [pam_reply] (0x0100): pam_reply get called.
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [pam_reply] (0x0100): blen: 8
(Wed Feb 22 20:53:39 2012) [sssd[pam]] [client_recv] (0x0200): Client disconnected!

I'm inclined to close this issue as WORKSFORME unless JR can provide us with either more detailed steps to reproduce or at least a backtrace for the crash.

Closing as WORKSFORME. The problem as originally reported does not exist. The presence of the sssd_pam crash is a different issue and should be opened as a new bug if it reoccurs.

resolution: => worksforme
status: assigned => 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/2190

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.