An HBAC extension would certainly be appreciated. I'm not sure how other organizations are setup but in our environment we don't give shell access unless absolutely necessary and we use a lot of SSH tunneling with target services bound to localhost. If I can figure out the correct syntax to get the perl command added to the users public key in IPA (as Honza suggested) then that will provide a work around for the time being. Ultimately it would be awesome to have the same level of granularity that the local authorized_keys file allowed while reaping the benefits of centralized management.
Albert On Mon, Dec 17, 2012 at 9:36 AM, Simo Sorce <[email protected]> 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. > > -- > Simo Sorce * Red Hat, Inc * New York > >
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
