#2585 [RFE] shared accounts without shared passwords
Closed: Invalid None Opened 9 years ago by jcpunk.

My site has the same sort of problem again and again: sharing a group account. Here is an example of the problem in more detail.
The control room workstations are used by various support staff – some staff is short term, some is long term, most are not Linux savvy, and none have root. The applications they run for detector control must be run within a very specific environment – XWindows and all. So to simplify this we created a shared account for them to use. However, getting them all authenticated is more complex.
Setting a standard password creates challenges when the password changes, or a user - thinking they were changing their private password – changes the shared password.
Setting no password allows unauthorized users access.
There is a bit too much staff turnover to force the runtime environment into dedicated local accounts for each user, and this also creates some challenges in keeping each account's settings in sync. Plus, if a user is running some of the applications in an X session with a locked screen, killing those via a system reboot causes issues. Giving them access to kill someone else's processes is not on the table.
Multiple user accounts with the same UID and home, but different names and passwords caused meaningful problems with X Applications.

The best solution we've found is to utilize 'prompt_principal' from www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html and control write access to the shared account's .k5login. In this way any user authorized to utilize a given control toolkit can unlock any workstation running as the correct user.

It would be nice if sssd could provide a solution to this problem.


Hi,

So, in essence, you want to have ability to use multiple credentials to unlock the same account/existing session while operating on a console (X terminal) rather than remotely log-in into the system since remote
log-on under the single account is easy with Kerberos or public SSH keys.

With FreeIPA v4.1 in Fedora and upcoming RHEL 7.1 (already in RHEL 7.1beta) we already have this implemented with multiple tokens per user: a shared PIN and separate tokens give you ability to login under same user. OTP tokens can be either soft-tokens managed on your phones (FreeOTP application is maintained by FreeIPA team on Android and iOS) or hardware tokens. For hardware tokens, Yubikey provisioning is supported out of the box.

Same can be implemented with external RADIUS server because in that case token check would be delegated to something external which can do similar checks for multiple pins per account, with other types of hardware tokens or other types of secondary factors, whichever you could imagine and implement.

See http://www.freeipa.org/page/V4/OTP for more details.

Did you try to use sudo -i for this? You can allow multiple users to sudo as the shared group account.

user1$ sudo -i -u groupacc
groupacc$ startx

-> X is running under user "groupacc", do whatever you want

IMHO the result is the same as shared account with shared password and it uses only ancient sudo so it does not depend on anything new.

For use of tokens you need to disable password-only login so that a shared PIN alone could not be used to get access.

The data from comment 1 is darn close to what I'm aiming at.

Possibly close enough to get the job done!

I was hopeful for something similar to using .k5login to auth for X and not just ssh, but this OTP token setup may be workable. I'll have to play with it a bit.....

Given there are several alternatives that could be used without patching SSSD, I'm closing this ticket. Kindly reopen if you disagree.

resolution: => wontfix
status: new => closed

Metadata Update from @jcpunk:
- Issue set to the milestone: NEEDS_TRIAGE

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

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.

Metadata