TCLUG Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TCLUG:9154] NIS server under linux
Here a little info about securing NIS. I haven't tried it yet but
hopefully will find some free time to play around with it.
http://www.eng.auburn.edu/users/doug/nis.html
Clay
Peter Lukas wrote:
>
> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tclug-list-unsubscribe@mn-linux.org
> For additional commands, e-mail: tclug-list-help@mn-linux.org
--
Clay Fandre
cfandre@maddog.mn-linux.org
Twin Cities Linux Users Group
http://www.mn-linux.org