PAM conversations should support local and network auth configurations

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/149

• Created at 2009-09-02 13:33:29 by sgallagh
• Closed at 2020-03-24 14:23:44 as wontfix
• Assigned to jzeleny

---

The PAM conversation in the SSSD should support separate configurations depending on whether the auth is occurring locally or during a network login.

Comments

---

Comment from sgallagh at 2009-10-01 16:19:46

Fields changed

milestone: SSSD 0.6.0 => SSSD Deferred

---

Comment from sgallagh at 2011-02-03 19:49:13

Moving back to NEEDS_TRIAGE

As we're now working on two-factor authentication, it makes sense to revisit the concept of location-aware auth configurations.

coverity: =>
milestone: SSSD Deferred => NEEDS_TRIAGE
upgrade: => 0

---

Comment from dpal at 2011-02-03 19:56:13

We need to be able to differentiate which domians are available to which services for auth and identity purposes. We need to start with PAM and make sure that only allowed domains are queried for authentication.

---

Comment from dpal at 2011-02-07 14:14:12

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0

---

Comment from dpal at 2011-02-07 14:26:23

We need to do design first.

owner: simo => jzeleny
type: enhancement => task

---

Comment from jzeleny at 2011-03-15 10:55:20

Are there any other requirements besides allowing/denying certain domains for local/remote authentication? The only other requirement I can see is distinguishing which service is asking for auth.

---

Comment from sbose at 2011-03-21 14:49:08

A short discussion with Simo, Jan, Jakub and Sumit had the following results:

- it need to be clear how multiple authentication methods for a single user are handled in sssd (#366) before a final solution to this ticket can be made
- the pam_sss module should support the options 'local' and 'network' so that a new pam service, which is unknown to sssd, can use them as a hint to indicate if it is a local or a network service
- the first time pam_sss() is called it should send a request to the pam responder with the 'local' or 'network' option and all available PAM items expect the password (PAM_USER, PAM_SERVICE, PAM_TTY, PAM_RUSER, PAM_RHOST)
- sssd then can decide which authentication methods must be used by this user and this services; the result is returned as a response to the initial request
- pam_sss can then prompt the user for it's password, fingerprint, OTP token etc.
- special care has to be taken for services which do not support PAM conversations or only if configured accordingly, e.g. ssh

---

Comment from sbose at 2011-03-22 09:33:00

Dmitri made an interesting comment. If a user is logged in via ssh is sudo/passwd/su still a 'local' or a 'network' service because e.g. fingerprint readers wouldn't be possible in this setup. Also gdm can be 'local' and 'network'.

For the gdm case it might be sufficient to check PAM_TTY to determine if it is 'local' or 'network'. I'm not sure if this will work for the other example, too. Maybe we need to keep track of the whole user session and label it as 'network' or 'local'?

Since this ticket depends on #366 I would like to suggest that we move it at least to the same milestone as #366.

---

Comment from sgallagh at 2011-03-23 12:19:30

For the record, this is an existing problem. If I have fingerprint scanning set up on my laptop (which is configured only for local account logins, no SSSD) and I ssh in from a remote machine and then try to run sudo, I am prompted for the fingerprint input.

The PAM stack does not have a clearly-defined way to resolve these issues, and it is one of the primary reasons for our plans to reinvent the InfoPipe as a PAM replacement. We could (and should) build into the new interface a complete session-tracking mechanism.

I'm going to move this back into NEEDS_TRIAGE. We should probably consider deferring this until 2.0.

milestone: SSSD 1.6.0 => NEEDS_TRIAGE

---

Comment from sgallagh at 2011-03-23 12:46:10

BZs related to my above comment:
- https://bugzilla.redhat.com/show_bug.cgi?id=506058
- https://bugzilla.redhat.com/show_bug.cgi?id=666804

---

Comment from sgallagh at 2011-03-24 14:07:13

Fields changed

milestone: NEEDS_TRIAGE => SSSD 2.0

---

Comment from dpal at 2012-01-19 03:13:38

Fields changed

rhbz: => 0

---

Comment from dpal at 2012-08-16 19:54:05

Fields changed

blockedby: =>
blocking: =>
feature_milestone: =>
milestone: SSSD 2.0 => SSSD Deferred
patch: => 0
proposed_priority: => Optional

---

Comment from dpal at 2012-09-04 23:25:04

This ticket has been evaluated for inclusion into SSSD 1.10 release and was decided to be excluded since it does not match the main goals and themes of the release. It might be considered for later releases.

---

Comment from sgallagh at 2017-02-24 14:26:49

Metadata Update from @sgallagh:

• Issue assigned to jzeleny
• Issue set to the milestone: SSSD Patches welcome

---

Comment from pbrezina at 2020-03-24 14:23:43

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

Comment from pbrezina at 2020-03-24 14:23:44

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)