Learn more about these different git repos.
Other Git URLs
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.
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
BZs related to my above comment: - https://bugzilla.redhat.com/show_bug.cgi?id=506058 - https://bugzilla.redhat.com/show_bug.cgi?id=666804
milestone: NEEDS_TRIAGE => SSSD 2.0
rhbz: => 0
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
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.