How to set up /etc/group with NIS

[Gary Cooper_1]

I have about a dozen HP_UX (10.20) boxes and want to get NIS running so that I can use centrallised password administration to ease the burden of password aging.

I have about 40 user accounts in total. 30 of which belong to a group called "cgs". Approximately 15 of the "cgs" users have accounts on all machines, but the other 15 are spread over about 8 machines. By example:
Machines 1-4: cgs - user1-user15
Machine 5: cgs - user1-user15,user16-user18
Machine 6: cgs - user1-user15,user19-user21
etc.
(Clear as mud?)

I have a number of questions.

Question 1: How do I set up my /etc/group on each machine for group cgs (I don't want to have all 30 "cgs" user accounts on all machines). The 15 "cgs" users that have accounts on all machines do change rasonably frequently, so I do want to be able to use NIS to administer this group.

Question 2: (Which I think I know the answer to) One of the passwords that I wanted to administer using NIS is root. All of the stuff that I've been seeing on this forum suggests that this is a big no-no. Does this mean that I will have to log into each machine separetely and change the root password? (the root password is the same on all machines).

Any help would be gratefully received.

Thanks,

Gary Cooper

[Mark Landin]

I can answer question 2: yes, you should administer the root password on each machine. In my environement, I have another (disabled) uid-0 account defined in /etc/passwd that I serve via NIS. I use this in case I somehow forget, corrupt, or fumble the native root password on a machine ... I just enable this back-door account in the NIS master map, make and push them, and then log into the NIS client machine I'm interested in. Then I go back and disable the back-door account on the NIS master so it's not usable again.

[Jeff Schussele]

Hi Gary,

Well, I'm not sure this can be done having all users in a single NIS domain. This is because to build the master group (or passwd) file on the NIS master server you basically copy all the group (passwd) files to it from the client hosts & merge them, removing dupes, into a single file which then is used to create the group (passwd) map for NIS.

So I'd say you have to determine which users
1) will be in NIS (have access to all hosts in NIS & you'd make sure they're in the master maps)
2) won't be in NIS (Control access thru normal means - i.e. passwd/group files. They will NOT be in the master maps)

This would be based on a single NIS domain. IF you set up multiple domains such that the servers in question are in DIFF domains then you could do what you want with access.
See the following URL for more NIS detail

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B1031-90043/B1031-90043_top.html&con=/hpux/onlinedocs/B1031-90043/00/00/16-con.html&toc=/hpux/onlinedocs/B1031-90043/00/00/16-toc.html&searchterms=nis&queryid=20020613-065221

HTH,
Jeff

[S.K. Chan]

Ideally in a NIS environment the group file on local machines all look alike (unless you want to allow local accounts not administer by NIS on these machines). For example ..
root:*:0:root
other:*:1:root,hpdb
bin:*:2:bin
sys:*:3:uucp
adm:*:4:adm
daemon:*:5:daemon
mail:*:6:daemon
lp:*:7:lp
tty:*:10:
nuucp:*:11:nuucp
+:
With the "+:" entry in the last line, it's telling it to get the rest of the group entries from NIS. Once you've centralized/consolidate your group file entries to a single group file physically located on the NIS server and ready to be distributed by NIS, you would only need to modify the master group file and push it out when ever there are changes/addition/deletion.
On question 2, YES, I would suggest changing the roor password locally on all machines. Given the fact that local NIS client password file entries are going to be identical as well you might want to develope a "push" process to overwrite the local password file when ever you have to change the root password. That'll save you time from having to individually login to each machine and change it.

[Gary Cooper_1]

So, what happens if my NIS map version of /etc/group contains all "cgs" users on my network, even though they don't all have accounts on all machines?

Would this achieve what I'm trying to do? Or is HP-UX/NIS too clever and would detect that group members don't exist on some machines?

Thanks,

Gary

[Jeff Schussele]

Hi (again) Gary,

If the cgs group is listed in the /etc/group file (before the +), then group file is autoritative over NIS for *that* system IF files is before nis in the nsswitch.conf file. IF nis is first in nsswitch.conf & the user is in NIS AND in the group file then NIS is authoritative. If it's not listed in the group file then NIS rules no matter what order is in nsswitch.conf IF the user is in NIS.

Anyway you look at it you'd *have* to admin the group/passwd & nsswitch.conf files on the client hosts. NIS is an "all or none" kind of thing. If the host is in the NIS domain the the NIS master map will be authoritative UNLESS you manually control the local files & the nsswitch.conf file.

Rgds,
Jeff

[S.K. Chan]

I see what you're saying .. the group file entries remain the same. With NIS running all users would be able to logon to all machines that are part of it's NIS domain. The question is when the user login will he/she be able to access his/her home directory ? Now that depends on how the home directory is accessed. For example when NIS is running, user16 logs onto machine1. He will be able to logon but he will not be able to access his home direcotry since that is only available on machine5. So what will happened is user16 gets into machine1 and it'll say something like .. "home directory not found" and he will be defaulted to root directory. The question is do you want this behavior because the whole purpose on an NIS environment is to allow users to logon to any mchines in the domain, whether the home dir of that user is available or not on a specific machine is a separate thing to deal with. If you do not want this behavior, you would have to put an entry in local /etc/passwd file (not /etc/group) on machine1 that would restrict user16 from login in (ie NIS search for this user on machine1 will not be performed) and I think that entry would look like ..
-user16::-1:0:::
I'm not sure of the exact syntax, you need to look in up in the manual.

[Jeff Schussele]

Hi S.K.,

I think what he's asking is:

Can NIS, alone, control user access to individual systems in it's domain?
i.e. Can it let user A into server A but NOT server B?

And I think the answer is No. You have to use the local files, nsswitch.conf file search order as well as search action parameters to do this.

What he wants can be done - just not by NIS all by itself.

Rgds,
Jeff

[Gary Cooper_1]

Hi Guys

A little clarification here...

What I want to do is prevent user16 from logging in anywhere except Machine 5. user16 is a member of the group "cgs" as are user1-user30. User1-user15 can log into any machine.

My intention was to put user1-user15 in the (passwd) NIS map and put user16-user18 into /etc/passwd on machine 5, user19-user21 into /etc/passwd on machine 6 etc. Which I believe should be relatively straight forward.

The sticky bit, as far as I can see is what to do about the group that user1-user30 belong to (i.e. "cgs"). Can I put group "cgs" in the NIS map, with user1-user30 all being members? Even though machine 1 knows nothing about user15-user30?

Thanks for your patience and perseverence.

Gary

[S.K. Chan · Accepted solution]

Alright .. it seems straight forward then what you're trying to achieve. The answer is yes, proceed with putting group "cgs" in the NIS master group file. For users, put all users in NIS master password file except user16-18 and user19-21 because these will NOT be managed by NIS since you want them to be local on mchine5 & 6 respectively. When you edit the password entry for user16 for example in machine5, for GID use "cgs" GID that you got defined in your master group file. Make sure local UIDs do not clash/conflict with that in the NIS map. Last entry in local password file should be
+::0:0:::
bacause you still want user1-15 to be able to log on to machine5 for instance. Finally in your /etc/nsswitch.conf the entry should be ..
passwd: compat
group: compat
because you would want to enforce the "+" syntax in both /etc/passwd and /etc/group.

[Steve Labar]

Gary,
Another way you could implement your NIS users. If you make the entry in your /etc/nsswitch.conf file of
passwd:compat

Then at the end of your /etc/passwd file you can identify which NIS users are permitted to login to that station by adding
+user1
+user2
+user3
...etc

This would need to be defined for each client station. If your cgs group is defined in your NIS master's /etc/group file, you only need a "+" at the end of your clients /etc/group file.

Good Luck

Steve

[Mark Landin]

Perhaps the best method is a brute-force one: Push a login script out to each machine that immediately logs off users who log into the wrong machine. Depending on how many not-this-user-on-this-machine combinations you have, this may in fact be simpler to manage (and easier to understand) than mucking about with NIS maps.

[Gary Cooper_1]

Hi Guys,

Well, I've finally started the roll out! After a few teething problems and some quality help from Dave "The Man" Shakespeare at HP (UK), I've got my master server set up for group & passwd. Being late on a Friday afternoon, I've decided to leave nsswitch.conf & the other servers/clients until Monday.

Thanks for the help. Will let you know how I get on.

Cheers,

Gary