Subject: Re: Centralized User and Password Management
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Tillman Hodgson <tillman@seekingfire.com>
List: netbsd-users
Date: 11/25/2004 16:18:25
On Thu, Nov 25, 2004 at 04:50:50PM -0500, Greg A. Woods wrote:
> [ On Wednesday, November 24, 2004 at 07:51:34 (-0600), Tillman Hodgson wrote: ]
> > Subject: Re: Centralized User and Password Management
> >
> > I tend to prefer Kerberos + NIS, with NIS run over an IPsec'd VLAN
> > (transport mode). I modify NIS maps have "krb5" or "*" in the password
> > field so that they're invalid as Kerberos will handle the
> > authentication. I use IPsec to provide secure confirmation that I'm
> > talking to the right host and that the packet hasn't been modified in
> > transit.
> 
> Indeed NIS over some kind of private network -- over an IPsec secured
> VLAN if you want to keep your interfaces and wiring down to a minimum
> and over IPsec anyway if you don't trust your local wiring -- is
> reasonably secure.  There may be weaknesses in the software
> implementations, but at least with a private network the inter-host RPC
> traffic over the network infrastructure is reasonably secure.
> 
> If I'm not mistaken you also need to keep all your system clocks in sync
> for NIS (or Kerberos) to be trusted....  Or am I thinking of NIS+?

Kerberos. But it's only "in sync" to within a 5 minute window, and even
that is configurable in the config file.

> > This gives a traditional "feeling" system that's very easy to set up and
> > maintain (NIS) and provides both signle-sign-on and reasonable security
> > (Kerberos and IPsec).
> 
> You should not need Kerberos for the "single-sign-on" feature if you're
> using NIS.
> 
> Oh -- perhaps you mean that other meaning of "single sign on" -- the one
> which actually reduces your overall security unless (and even sometimes
> if) your users are extremely and consiously aware of all security issues
> at all times.

No, I mean that Kerberos uses a ticket-based system. I log "into the
network" in the morning, and am not required to enter my password again
until my ticket expires (defaults to 10 hours, just long enough to cover
a working day.

Have you worked with Kerberos at all?

For any readers who are unfamiliar with it, a gentle introduction is
http://web.mit.edu/kerberos/www/dialogue.html. It's actually quite a fun
read. I maintain have more information (links and docs I've written) at
http://www.seekingfire.com/projects/kerberos/.

> Regardless given all the problems and complexities with Kerberos I'd
> suggest that it should only be used in reasonably large organizations
> that can truly dedicate the resources necessary to run a proper and
> truly secure KDC and to do all the other things necessary to keep the
> entire Kerberos infrastructure running.

Here's the in-progress draft of my revised FreeBSD Handbook entry on
Kerberos5. Most of it applies directly to NetBSD:

http://www.seekingfire.com/freebsd-doc/kerberos5.html

Kerberos isn't rocket science, seriously.

I use an old SparcStation 10 running NetBSD to act as my KDC. Securing
it is dirt simple: I run no services on it other than the KDC itself and
access it through a serial console. Your slowest, oldest machine is more
than adequate to the task. A 25Mhz DECStation (ah, I miss mine) will
easily support tens of thousands of users.

-T


-- 
Even innocents carry within them their own guilt in their own way.  No one 
makes it through life without paying, in one fashion or another.
	- Lady Helena Atreides, her personal journals