On 12/17/2012 09:36 AM, Simo Sorce wrote: > On Mon, 2012-12-17 at 09:07 -0500, Albert Adams wrote: >> Thank you for the responses. I was initially attempting to set this >> value via the web UI and if I entered anything other than the hash >> value of the user's public key it would get rejected. After thinking >> about your response I realize that I really need to determine a method >> of doing this via a HBAC rule. If I accomplish this with >> authorized_keys then the user is restricted across the board and would >> not be able to gain a shell on any system whereas HBAC would allow me >> to restrict thier access as needed. We currently require users to >> tunnel over SSH to gain access to certain sensitive web apps (like >> Nessus) but those same users have shell access on a few boxes. >> Thoughts?? > One thing you could do is to use the override_shell parameter in sssd. > However this one would override the shell for all users so just > putting /sbin/nologin there would not work if you need some users to be > able to log in (if you care only for root logins it would be enough). > > However you can still manage to use it to point to a script that would > test something like whether the user belongs to a group or not, and if > so run either /bin/bash or /bin/nologin > > This seem like a nice feature request for FreeIPA though, maybe we can > extend HBAC to allow a special option to define a shell, maybe creating > a special 'shell' service that sssd can properly interpret as a hint to > set nologin vs the actual shell. > > Dmitri, should we open a RFE on this ? > > > Simo. > OK , RFE would make sense.
-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users