Allowing a subset of NIS users on a group of hosts

[Steve Bonds]

What is the most commonly used way to restrict the set of users who can log in via NIS to a particular set of hosts? Ideally we would have it set up so that all users in a particular set of UNIX groups could log in, but nobody else. I have not found a way to do this.

In my NIS refresher reading I came across three options for allowing limited access:

1) Use /etc/netgroups, compat mode, and +@netgroup entries for the users who will be allowed access
2) Create a separate NIS domain containing only the users allowed access
3) Use individual +user entries in compat mode

Each seems to have different advantages and disadvantages, and I'd appreciate your thoughts on each:

1) Good: central place for storing all the info
Bad: need to remember to add each user to netgroups when created
2) Good: only need to add the user in one place
Bad: likelihood of UID collisions with other NIS domains causing problems on NFS shares, etc.
Bad: many users will need to exist in both domains, creating additional chances to have them misconfigured
3) Good: don't need to add a new map to the NIS master
Bad: need to change each host when a user is added

What do you all suggest?

Thanks,

-- Steve Bonds

[Steven E. Protter]

Shalom Steve,

Define login.

telnet and ssh can be handled with tcpwrappers. sshd_config has some very good filtering options.

Another option is a trap scrip in /etc/profile, but these can be avoided by a well timed ctrl-break.

LDAP may also have more options for granularity. There are several open source versions that will run on HP-UX.

SEP

[Steve Bonds]

> Define login.

Both of these are true:

1) A supplied username matches the one obtained via the use of getpw* library calls (e.g. getpwent()) AND
2) the provided password when salted and hashed with crypt() matches the entry obtained via getpw* library calls.

> telnet and ssh can be handled with tcpwrappers. sshd_config has some very good filtering options.

I'm looking for an OS-wide solution that will encompass all apps. I don't mind if the OS knows the other users exist (e.g if the username/uid mapping is present) but I don't want users other than those named to pass the above login test.

> Another option is a trap scrip in /etc/profile, but these can be avoided by a well timed ctrl-break.

Indeed. Though if our company leadership was concerned about security, would we even be running NIS? (Don't get me started...)

> LDAP may also have more options for granularity. There are several open source versions that will run on HP-UX.

Aye, I'd much rather be using LDAP + Kerberos, as you probably gathered from my above comment. However, it's not up to me. All I can do is advise. :-)

I'm currently leaning towards option 1) given the large number of users that will be involved.

[Steven Schweda]

My first suggestion would be the separate
NIS domain (2).

My NIS is getting pretty rusty, but ...

You might keep one global passwd source file,
and filter it to create the more limited
passwd source file(s) for the more restricted
NIS domain(s). Creating all the users in one
file should avoid the UID collision problem.

If you can sneak in some easy-to-recognize
string (so that a simple "grep" (or something
close) could extract the subset lines from
the global passwd source file), then it might
be practical to automate the creation and
propagation of the subset-domain data.

Some cleverness may be required. Not sure
how this might affect the yppasswdd.