NIS+ passwd table protection
2007-12-25 8:42:00
My original request:
>
> We've got Solaris 2.3, SS 10 as NIS+ server, several
> Sparc Classics as NIS+ clients; and the following problem:
> NIS+ passwd table is set according to this:
>
> master:/# niscat -o passwd.org_dir
> Object Name : passwd
> Owner : zeus.dcs.fmph.uniba.sk.
> Group : admin.dcs.fmph.uniba.sk.
> Domain : org_dir.dcs.fmph.uniba.sk.
> Access Rights : ----rmcdrmcd----
> ......e. t. c. .......
>
> But __SOME__ of our users are not able to log into clients,
> just on the master server. (Please note the word "some").
> Following message appears on the client's console:
>
> Permission on the password database may be too restrictive.
>
> Also applications such as xlock don't work. They can't read
> the user's encrypted password.
>
> When I do:
>
> master:/# nischmod w+r passwd.org_dir
>
> then things go well, but with read permission to world ordinary
> users can see encrypted passwords of others. Is there any other
> way to restrict read access to passwd database to ordinary users
> in such way that they will be still able to login to clients
> and run xlock etc..? Because world readable password table
> is now quite large security hole.
>
> Besides, this message appears from time to time on the console:
>
> Feb 18 13:59:02 client1 syslog: authdes_validate: verifier mismatch
>
Well, it turned out we have several problems. The greatest one
- world readable passwd table - was solved in very elegant way
(according to Zdzislaw.Meglicki@arp.anu.edu.au): I added all
NIS+ clients into admin NIS+ group (nisgrpadm -a admin client1.domain)
and set passwd table ----rmcdrmcd----(readable only by owner and group).
steve@gec-epl.co.uk (Steve_Kilbane) pointed out (but this wasn't our
problem - all users were added through nisaddent and nisaddcred)
that there is bug in admintool: credentials for users are
owned by whoever ran admintool, not by the new user. There's a patch
101384-01 which fixes this, and Steve also gave me a shell script
which fixes ownership of credentials in the cred table. His
posting is at the end of this summary.
But one problem is still unresolved: some users were not able to
change their passwords (for example me). But suddenly (not after
any change to NIS+ setup) they can! I suspect this problem will
occur again (after adding new users). Also I don't have any
explaination for the message
"syslog: authdes_validate: verifier mismatch" and
"nis_cachemgr: authdes_validate: verifier mismatch".
Many many thanks to all who replies - it was a great help for us!
Here is the mail from Steve_Kilbane:
>From steve@gec-epl.co.uk Tue Feb 22 13:31:44 1994
Date: Tue, 22 Feb 1994 12:28:21 +0000
From: steve@gec-epl.co.uk (Steve_Kilbane)
Message-Id: <9402221228.AA01112@zombie.gec-epl.co.uk>
To: misik <misik@alpha.dcs.fmph.uniba.sk>
Subject: Re: NIS+ passwd table protection
i suspect that you've fallen foul to the bug in admintool - it
creates credentials for newly-added users, but the creds are
owned by whoever ran admintool, not by the new user. there's
a patch, and you may have applied it (i don't know the number).
instead of the patch, sun support sent me the following script,
which goes through the cred table and fixes the ownership. this
will be needed if you fixed the admintool bug, but still have
user accounts from before then.
steve
-----------------------------------------------------------
#!/bin/ksh
#From Ian.Herd%sun-microsystems.co.uk@gec-epl.co.uk Mon Jan 31 17:40 GMT 1994
#Date: Mon, 31 Jan 1994 17:31:39 +0000
#From: Ian.Herd%sun-microsystems.co.uk@gec-epl.co.uk (Ian Herd - Sun UK - Answer Centre)
#To: ian.herd@sun-microsystems.co.uk, steve_kilbane@gec-epl.co.uk
#Subject: credential fix script
# ******************************************************
# * *
# * DISCLAIMER *
# * *
# ******************************************************
#
#
# The contents of this file are intended to be read as
# an example. This is not a supported product of Sun
# Microsystems and no hotline calls will be accepted
# which directly relate to this information.
#
# NO LIABILITY WILL BE ACCEPTED BY SUN MICROSYSTEMS FOR
# ANY LOSS (DIRECT OR CONSEQUENTIAL) INCURRED IN ANY WAY
# BY ANY PARTY THROUGH THE USE OF THIS INFORMATION.
#
# NO WARRANTY OF ANY SORT IS IMPLIED OR GIVEN FOR ANY
# CODE DERIVED FROM THIS INFORMATION.
#
#
#
DOMAINNAME=$(nisdefaults -d)
fix_cred()
{
IFS=": $IFS"
while read cname auth_type auth_name public_data private_data
do
if is_owner $cname
then
:
else
nischown $cname [cname=$cname,auth_type=DES]cred.org_dir.$DOMAINNAME
fi
done
}
is_owner()
{
owner=$(nismatch -o cname=$1 auth_type=DES cred.org_dir.$DOMAINNAME |\
awk '{ if ( $1 == "Owner" ) { print $3 }}' )
if [ "$1" = "${owner}" ]
then
return 0
fi
return 1
}
nismatch auth_type=DES cred.org_dir.${DOMAINNAME} | fix_cred
exit
Comments
Got something to say?
You must be logged in to post a comment.
