This was the problem:
> This may be a standard question but...
> I have a SS5 server + 16 clasics as clients, all running Solaris 2.3,
> i am running nis+. I want to disable network logins for most of the users
> (but not ALL of them) on the serwer. The obvious answer is to
> check uids in the /etc/login (or whatever) system-wide script and
> logout unwanted users. This seems rather ugly, any other ideas ?
> Please send e-mail to: firstname.lastname@example.org thank you
Following people contributed:
Lenny Turetsky <email@example.com>
Dave Fetrow <firstname.lastname@example.org>
email@example.com (Carl Hughey)
Christian Gresser <firstname.lastname@example.org>
C.M. Fung <email@example.com>
Pamela Pledger <firstname.lastname@example.org>
Bill Maggio <email@example.com>
james mularadelis <firstname.lastname@example.org>
Ashish Desai <email@example.com>
Pom Bajar <firstname.lastname@example.org>
Richard Pieri <email@example.com>
Tom Mornini <firstname.lastname@example.org>
Robert Tag (email@example.com)
Great thanks to all of you !
the following solutions were proposed:
1) duplicate nis+ accounts in passwd/shadow files and provide /bin/false
(or a special script) shell to users we don't want on the server
Carl Hughey writes:
> In the passwd file you can change their shell from "/bin/csh" to
> "/bin/false" or a homegrown message script. Unfortunately this breaks
> ftp access as well since it wants to see a standard shell.
> If ftp's not a problem though, when the user tries to login, they'll be
> immediately logged off. I've used my own programs in the past to display
> some message like "This account has been disabled. Contact your
> system administrator..." then bump them off.
The disadvantages of this were summarized by Christian Gresser :
> - you need a different passwd-file on the server and the clients
> (perhaps don't use NIS+ on the server)
> - this disables all logins, not only network logins
2) split up the nis+ domains: nice, but a lot of work and sometimes
i want the server in the same domain !
3) make the server use only passwd & shadow files (not nis+) for passwords
- has the disadvantage of maintaining separate accounts for
the admins and priviliged people.
4) take away the execute permisions from the shells,
james mularadelis <firstname.lastname@example.org> writes:
> YOu could take away permissions to the shells,
> /bin/csh or in our case /opt/bin/tcsh and give it to only root and a
> group called say servgroup and this group will have permissions on it
> also. But nobody else will.. Put the people you want ot log into your
> server in this group.
5) This solution is the best in my opinion:
Lenny Turetsky writes:
> 1) create a netgroup containing the users who *can* login to the server
> 2) put the following in the server's /etc/passwd:
> What this does is over-ride the shells of all users (other than those in
> the netgroup) with /usr/local/bin/not_here_sh, which should be a
> program/shell script that tells the user that he can't login on this
> machine, and (optionally) makes a record of the attempt a/o e-mails the
> sysadmin about it (please note that if you go the e-mail route, you have
> to watch out for user's who have ~/.mailrc files -- that little gotcha
> had me stumped for hours!).
I tried 5) and discovered that i have to change the nsswitch.conf file
passwd entry from the standard:
passwd: files nisplus
in order for the '+' mechanism to work properly
- don't forget to update the `netgroup' nis+ map :-)
- this also breaks ftp access, but in my case that doesn't matter.
Finaly, there was an idea of using .rhosts file but: 1) this would solve
only rlogin problems 2) if .rhosts verification fails, rlogin
(unlike rsh and rcp !) uses standard prompting
for user's password, so I don't see an easy way of doing it in this
I would like to thank WU Labor. of Med. Phys. for providing me
with access to netnews.
Grzegorz Blinowski email@example.com +
Institute of Computer Science ---------------+
Warsaw University of Technology ---------------------+
Nowowiejska 15/19, 00-665 Warsaw, POLAND --------------------------+
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:16 CDT