Unix shells are generally not viable access control mechanisms any more

Once upon a time, if you had a collection of Unix systems, you could reasonably do a certain amount of access control to your overall environment by forcing logins to have specific administrative shells. First, you almost certainly operate a variety of services that normally only use Unix logins as a source of authentication and perhaps a UID to operate as, and ignore the login's shell. In some cases you may be able to teach these services to look at the login's shell and do special things, but some of them are sealed black boxes and even the ones that can be changed require you to go out of your way. Second, you may operate general authentication services, such as LDAP or a Single Sign On system, and if you do these authentication services are generally blind to what they're being used for and thus to whether or not a login with a special shell should be allowed to pass this particular authentication. The only real solution is to have multiple versions of these authentication systems with different logins in them, and point systems at different ones based on exactly who should be allowed to use them. If you need certain logins to be excluded from some of these services but not others, either you need multiple htpasswd files or you need to teach each such service to do additional checks. Today, the only two measures of login access control that really work in a general environment are either scrambling the login's password or excluding the login entirely from your various authentication data sources.