[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: NIS, shadow, and pam?



 
> Jim Hebert writes:
>> I always hear varying things on this, so I'm going to stick my neck out
>> and someone either confirms or denies this. =)
>> 
>> I've heard, on one hand, that "shadow" for YP is really not shadow in the
>> traditional sense, and that instead it's a trick in the library where it
>> check's who is asking for the password map from yp and if it's not root,
>> it sends it the user:*:.... looking map, while if it is root it will give
>> you the normal looking map with the passwords.
>> 
>> Then on the other hand I've actually seen threads where people were
>> running with /etc/shadow containing the passwords, and they were trying to
>> get that working.
>> 
>> So, I dunno. How's that saying go? The best way to get information is to
>> post misinformation?
> 
> To NIS and shadow, I could tell you a lot. But I don't know, how it
> works with PAM.
> 
> At first, shadow over NIS isn't much safer then normal passwd over
> NIS. But you could configure my Linux ypserv in a way, that some
> fields are mangled with a *, if the request doesn't come from a
> reserved port. If a DOS or Windows client has access to this server,
> you have losed.
> With this, you could send an entry like user:*:... from passwd to the
> client, if the request comes from a normal user. root will get the
> correct entry (port greater or less then 1024).
 

	Wouldn't it be nice to use NIS (with SRA) or NIS+ just
	for distribution of username/group (and related info)
	--- without *any* authentication.  Then to use Kerberos
	as the authentication system.

	I guess PAM would accept the identity data, using it
	to query the local files and pwdb elements and the NIS/NIS+ 
	(and RADIUS/TACACS and whatever else) to get the 
	user account data (group membership, home directory
	etc).  Then PAM would relay the authentication data
	and pass it to local shadow, OPIE, SecurID or other
	authentication modules, and/or relay it to a Kerb. ticket
	server for the authentication.

	It sure would be nice to have something like this nailed
	together in a form that was suitable to include in
	distributions "out-of-the-box" --- so we sysadmin's don't 
	have to continually be mucking with these thorny 
	integration issues all the time.

	As far as I know NIS authentication data is passwd
	over the wire in plain text (even with SRA).  If that's
	true that the potential attacker just needs a sniffer
	anywhere on the segment --- and use of shadowing is
	of *no* consequence.  (Unless there's some way to force
	all your RPC traffic to go over SSH links!).

	Does NIS+ provide strong, cryptographic protection?

	I sure hope they get IPSec working soon.  Maybe we'll be
	able to configure and enforce a policy to require all of
	our local systems to do all of their traffic over IPSec
	after that point.  As it is our LAN security is just
	a house of cards to anyone on the inside.

--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org
        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []