#149 PAM conversations should support local and network auth configurations
Closed: wontfix 2 years ago by pbrezina. Opened 13 years ago by sgallagh.

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

Fields changed

milestone: SSSD 0.6.0 => SSSD Deferred

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

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.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0

We need to do design first.

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

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.

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

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.

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

Fields changed

milestone: NEEDS_TRIAGE => SSSD 2.0

Fields changed

rhbz: => 0

Fields changed

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

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.

Metadata Update from @sgallagh:
- Issue assigned to jzeleny
- Issue set to the milestone: SSSD Patches welcome

5 years ago

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.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

2 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/1191

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.