Hi
Below is my summary for making NIS to work under C2 security in OSF1 v3.2a.
1. Setup the NIS as described in the Network Configuration manual. Note
that the setting described there is only for normal security. To test
out first, I recommend not to include any slave server in the master
server setup. When NIS on the master server is running fine, then you
can modify the NIS master server to include slave server.
2. Edit the /etc/svc.conf file. The file should look
like this :
auth=local,yp
aliases=local,yp
group=local,yp
hosts=local,bind,yp
netgroup=local,yp
networks=local,yp
passwd=local,yp
protocols=local,yp
rpc=local,yp
services=local,yp
SECLEVEL=BSD # for backwards compatibility ONLY
Note that the auth is not generated by the system. You will need to type
it in.
3. Next you will need to generate the prpasswd file. Activate
/usr/tcb/bin/XSysAdmin and use it to add an account into the NIS. This
will generate a prpasswd file in the /var/yp/src directory. Note that
the change password option in this XSysAdmin is not working properly,
you can use the passwd command to change NIS account password. Note that
this prpasswd file is a substitute for the /tcb/files/auth/[a-k] in the
enhanced security. Every NIS user account should have an entry in the
/var/yp/src/passwd and /var/yp/src/prpasswd file, and the entry should
NOT be in the /etc/passwd and /tcb/files/auth/[a-k].
The entry in the passwd should be like this :
test:*:200:50:Test:/home/test:/bin/csh
The entry in the prpasswd should be like this :
test:u_name=Test:u_id#200:u_oldcrypt#0:u_pwd=hdte#deeds%:u_succh
g#836456484:u_pwdict=dGrr%tfDE3,Dfd4$%F%RD:u_pwchanger=root:u_unsucl
og#74646474:u_unsuctty=ttyp5:u_numunsuclog#1:chkent:
4. If you make any changes to the passwd and the prpasswd files, you
need to execute a "make passwd" and "make prpasswd" under the /var/yp
directory.
5. Try to su to the NIS account. If no problem, then you are ready to
setup your client server and slave server. Note that currently, the
prpasswd is not being propapagated from the master to the slave server.
An Enhanced Security NIS Slave cannot operate independently of the
Enhanced Security NIS Master. This is because the prpasswd file
is updated with every login attempt, and is only mastered on the
NIS Master. In other words, there's no point having a Slave because
it won't be able to function without the Master running.
6. Do not use the secure option (-s and -S) for the NIS client and
master server. I seems to have some problem with this option.
7. Attached is a reply from Jon Buchanan, Zuerich of Switzerland who has
given me quite a lot of aid in making my NIS to work under enhanced
security.
Thank you.
Have a nice day.
Regards
Chua Koon Teck
koonteck_at_singnet.com.sg
SingNet
URL="
http://www.singnet.com.sg/"
Singapore Telecom
>From Jonathan.Buchanan_at_ska.com Mon Jun 5 15:32:55 1995
Date: Tue, 09 May 95 10:49:32 +0200
From: Jon Buchanan <Jonathan.Buchanan_at_ska.com>
To: koonteck_at_singnet.com.sg
Subject: Re: NIS on OSF1 v3.2 with C2 security
Hello Chua Koon
We struggled for months to get NIS working with Enhanced Security,
receiving many patches from DEC, and eventually got it to work. I
believe the patches are probably incorporated into 3.2 (we have 3.0).
With enhanced security, your user, group and password databases are
divided into many places:
/etc/passwd
This contains entries for local users not defined under NIS.
Passwords are not stored here - a * appears in place of each password.
Typically you would leave the system users like root, deamon etc here.
NIS-defined users must not appear in this file!
At the end of this file is +: for NIS to be searched.
/tcb/files/auth directories
Users defined in /etc/passwd have security profiles in these
directories. Their passwords, and things like successful/unsuccessful
login info are stored here. No NIS users have profiles in these
directories.
/etc/group
This contains entries for local groups not defined under NIS.
At the end of this file is +:
/var/yp/src/passwd
This is your NIS passwd file.
Local users, defined in /etc/passwd, should NOT appear here!
Passwords are not stored here - a * appears in place of each password.
The file should not contain +:
/var/yp/src/prpasswd
This is the 'protected password' NIS file, which functions like the
/tcb directory but for NIS users instead of local users. All users
with an entry in the NIS password file have an entry here.
/var/yp/src/group
This is the NIS group file.
Local groups, defined in /etc/group, should NOT appear here!
The file should not contain +:
When you are using the advanced security XIsso and XSysAdmin tools you
choose whether to manage the local or NIS registered users by clicking on
the 'N
etwork Control' button. It then updates only the
appropriate files, and in the case of the NIS files, does a make for
you.
The main problem with switching Enhanced Security/NIS on and off is in
restoring the information to the correct place. Above all, Enhanced
Security passwords CANNOT be re-inserted into the passwd files (in place
of the *'s) - you need to give all users a new password.
Problems that took us a long time to solve:
- The file /etc/auth/system/files must contain entries for
prpasswd and prpasswd:t. We have added them like this:
/var/yp/src/prpasswd:\
:f_type=r:f_mode#0660:f_owner=auth:f_group=auth:\
:chkent:
/var/yp/src/prpasswd\:t:\
:f_type=r:f_mode#0660:f_owner=auth:f_group=auth:\
:chkent:
- An Enhanced Security NIS Slave cannot operate independently of the
Enhanced Security NIS Master. This is because the prpasswd file
is updated with every login attempt, and is only mastered on the
NIS Master. In other words, there's no point having a Slave because
it won't be able to function without the Master running.
DEC have refused to acknowledge this as a problem, so a fix is
unlikely for the forseeable future. We have worked around it by
setting up a second Master and copying certain files from the
'real' master to the 'second' master periodically using rdist.
It is not an altogether satisfactory solution but it works and we
prefer it to being dependent on the availability of one machine.
Let me know if you would like more details on setting this up.
Good luck!
Regards,
Jon Buchanan, Zuerich, Switzerland
[ Jonathan.Buchanan_at_ska.com ]
Received on Mon Jun 05 1995 - 12:21:29 NZST