Re: [TCLUG:9154] NIS server under linux

[Peter Lukas <peter@math.umn.edu>]

Shadow and MD5 passwords would not work with NIS since it uses /etc/passwd
to share information.  Shadow+MD5 uses the /etc/shadow file for pw
authentication and /etc/passwd for user information/identification.  It
will support using a shadow file locally, but by that point, you've
already rendered NIS useless (at least in terms of user authentication).
NIS+ should solve the problem although it may be more pain than it's
worth.  Besides, the idea of spewing out user account information to
anyone who claims to be a memeber of the domain seems rather silly.  In
that case, you may want to just use Samba and WindowsNT password/user
accounting mechanisms.

Other newtowk-wide account management suites are emerging these days as
well.  OpenLDAP can be used for these purposes (it can be compiled under
any linux distribution).  SRP is another (free for noncommercial use)
authentication method (it only encrypts the signon though, not the entire
session) --srp.stanford.edu/srp.  Kerberos also may work in your situation
although it may require a lot of effort to kerberize applications.

Another idea is to whip up some homebrew solution that uses a shadow
password scheme with SSH or rsync.  It can be done with a rather painless
amount of shell scripting and buys you some secure authentication, no
unencrypted password spewings across network lines and best of all, it's
free.  Here's how I'd do it:

1. Manage all user accounds from a central server.
2. Maintain all client machines with adequate ssh_host_key,
   ssh_host_key.pub identifiers from the central server.
3. Using authorized keys, securely copy a copy of the /etc/passwd,
   /etc/shadow and /etc/group files from the server to the client
   machines.
4. Use some clever scripting to enable users to change passwords in the 
   traditional manner and the scp the updated /etc/shadow, /etc/passwd and
   /etc/group files out to all client machines.

Benefits:
o Logon/Authentication is done locally on the client machine.
o Accounts are centrally managed.
o The server can be configured to specify which accounts go on which
  clients and which do not.
o If the server attempts to update a client that has been spoofed, it will
  not since the host keys do not match (unless, of course someone sweizes 
  the client box as well as the host keys -- although by that point, why
  not just run crack against /etc/shadow.
o This can work for a variety of platforms since SSH and shadow are rather
  common nowadays.

Of course, you'll need to highly maintain and monitor your client
machines and it may take a little while to set up, but in the end, it'll
be far less work -- and perhaps more secure -- than NIS*.

Peter Lukas

On Wed, 13 Oct 1999, Bob Tanner wrote:

> Summary: Shadow and MD5 passwords with NIS does not work. What do I need 
> to do in nswitch.con to get this to work? How can I keep encrypted passwords
> from flying around the network?
> 
> Details:
> 
> I am a little confused about NIS servers under linux. Since we run Solaris and
> NIS+, I do not have that much expirence with NIS. After reading the HOWTOs and
> such I am even more confused. :-)
> 
> I activated a NIS server on a Redhat 6.0 box. No shadow, no MD5. Setup the
> nswitch.conf correctly and played around with ypcat. Things looked great.
> 
> Install a NIS client on a RH 6.0 box. No shadow, no MD5, nswitch.conf, ypcat,
> all worked fine.
> 
> Put my sniffer on the Ethernet segment with these 2 linux boxes, turned
> monitor on my switch (makes 1 port on the switch receive all traffic on that
> segment, like a hub) and kringed when I saw the encrypted passwords flying
> across the wire.
> 
> Also was concerned that the encrypted password was in /etc/passwd, so being
> "smart" I actived Shadow and MD5 passwords (authconfig does a great job
> converting) on both the NIS server and client. Played with ycat and the
> sniffer some more and was happy to see no encrypted passwords on the wire.
> 
> Problem, I could not log in either. Read the HOWTO again. It looks like I
> should be able to put something into nswitch.conf to get this to work. What is
> it that I put into the nsswitch.conf? I tried the compat option but it does
> not work.
> 
> The HOWTO says NOT to use compat because the encrypted passwords get sent out
> on the wire. So, how do you prevent your encrypted passwords from being sent
> out on the wire?
> 
> NIS+ encrypts just about everything, so I did not have to worry.
> 
> Thanks.
> 
> 
> -- 
> Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
> http://www.real-time.com                | Fax   : (612)943-8500
> Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tclug-list-unsubscribe@mn-linux.org
> For additional commands, e-mail: tclug-list-help@mn-linux.org
> 
>