Re: [Hampshire] Domain Controllers

On Sat, Oct 03, 2009 at 11:16:39AM +0100, Rob Malpass wrote:
> Can someone tell me please if what I'm trying to do is
> overcomplicating things? I'm thinking of setting up some sort of
> domain controller for the Linux part of my network i.e. to have my
> own (and any other family member's) user area under a remote box as
> opposed to at present where it's located on each box under /home.
>
> The advantages of this are basically to make a backup I just need to
> do one thing - back up the server - and it'll be more secure.
>
> This differs from the current arrangement where all important files
> are copied across to a NAS and backed up when I think about it. So
> working files are under /home/whoever but it relies on me copying
> important stuff across to my NAS as and when.
>
> When I was at Uni - there was a "primary YP master" which handled
> all of this sort of thing but that was (can't quite believe it's so
> long but it is) 17 years ago and things have probably moved on.
> Should I still be thinking about setting this sort of thing up?
>
> It's basically a question of - what do I google for? Linux domain
> controller is just pointing me toward samba sites.
>
> Final question - is this solution going to be any better than my
> current setup - i.e. I could just put more thought into my NAS
> configuration? The trouble is my NAS boxes have interfaces that are
> just so darn bad (NSLU2 and Bufallo Linkstation) that I think anyone
> that knew anything about security could get in with no problem.

You have two (actually, three) distinct issues here. Firstly,
you're asking about how to store and access your data. Your second
question is about administering user accounts across your network.

For storing and accessing data, your main (simple) options are:

* Local storage (your current solution)
* CIFS (Samba/SMB/"Windows networking")
* NFS

Other solutions are available (AFS, Lustre, OCFS2), but those are
going to be massive overkill for almost any home network that I can
conceive of.

The essence of both the CIFS and NFS solutions is that you have a
central point which stores your users' files (a NAS, or a server). The
user files are shared across the network, typically without
encryption, but often with some kind of authentication/authorisation
(authN/authZ) mechanism.

Pros and cons of the two options:

CIFS will work out of the box on Windows clients (and probably
MacOS ones, too), but (IMO) is harder to set up than NFS. NFS is dead
easy to set up on Linux, but requires additional software to use it
under Windows -- it's downlaodable free of charge, but hard to find.

CIFS generally works on the principle of user-authenticated access,
so you'd give each user a separate share, and they'd authenticate to
that share. NFS authenticates *machines*, and then assumes that each
machine shares the same set of UIDs/GIDs for each user, and uses the
normal Unix file security semantics that we all know and love. (*)

Most cheap consumer-grade NAS systems will serve up CIFS shares.
Many support NFS as well.

This brings us on to the question of authN and authZ.

Let's assume, for a moment, that you're using NFS to share a
directory. NFS assumes that the security labels on each file
(user/group, and the rwxrwxrwx flags) are going to apply correctly
across every machine that is allowed to mount that directory. This
means that every machine must have the same mappings of uid to users,
and gid to groups. Otherwise, if you have username "rob", uid=1001 on
one machine, and I have username "hugo", uid=1001 on another machine,
I can mount the /home file share on my machine and access all of your
files as if I were you. There are similar kinds of issues with CIFS, I
believe.

The simplest way of handling this is manually -- if you have a
small number of machines and users, and they don't change often, you
can just ensure that the /etc/{passwd,group,shadow,gshadow} files all
match up, and your job is done.

There are three main alternatives to this, suitable for larger
setups: NIS+, LDAP, and ActiveDirectory. NIS+ is the oldest of the
three, and is part of the same Sun toolset that NFS comes from. (YP is
an earlier form of the same protocol, and was renamed NIS for
trademark reasons, I believe). LDAP is a much newer technology that
allows you to store a wide range of data about entities, typically
individuals and groups, including Unix-style username/uid/gid
information. ActiveDirectory is an MS technology based on LDAP and
Kerberos(**).

Any of these will allow you to push out a common set of usernames
and uid/gid settings across all of your machines, with a small amount
of setup on each machine. The only one I've got any direct experience
of administering is LDAP, and I've found it awkward to get working.
Once it's up, however, it seems to work well.

For a small home network, my recommendation would be to have
uids/gids set across the individual machines by hand (as they're not
likely to change much, nor to have many machines coming and going),
and then to use NFS to mount a single common /home directory,
restricted to named machines that you know are configured correctly.

If you have more stringent security requirements (say, you can't
trust the owner/administrator of a particular machine, but still need
to give them restricted access to their bit of /home), you should
probably use something else -- I hope someone else in here will be
able to advise, but I would expect it to involve LDAP and either NFSv4
or CIFS.

Hugo.

(*) Note: Neither of these is strictly true -- NFSv4 can, I believe,
do user-level security on shares, and I recall seeing options in Samba
for mount-level security. However, I know little about either of those
options.

(**) ActiveDirectory uses LDAP for authN, and Kerberos for authZ,
which is actually a better design than the common Unix configuration
of LDAP for both authN and authZ. One thing that MS did get
right... :)

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
                       ---   __(_'>  Squeak!   ---