Linux – Central authentication and /home storage with caching

While I can't speak to having multiple profiles for the same user across multiple workstations, I will say that if SBS2008 is anything like SBS2003 it should do a pretty nice job of joining the computers to the domain and migrating the individual user profiles to domain profiles. Of course I'm talking about a scenario where there's one primary user per workstation, not multiples like you have. IMHO this is one of the strong points of SBS, making a migration from a workgroup to a domain as painless as possible. The "Add User Wizard" does a fairly nice job of assisting you in creating user and computer accounts based on your current user and computer names. I might suggest that you pick a "primary" user per workstation and use the "Add User Wizard" to "migrate" those users and profiles to the domain, as well as joining their computers to the domain. You can then go in after the migration and pick out the pieces you need from the various user profiles leftover that are scattered across the workstations.

Authentication, authorization, and directory information

This isn't a complete answer to your question, but I thought it might help address your questions about NIS vs. LDAP vs. Kerberos.

Start with this, which provides a good overview of the difference between authentication and authorization, which is important to understand for this sort of discussion.

Kerberos is, as you say, just an authentication protocol. Given a set of credentials -- e.g., a username and password -- it will tell you whether they're valid or not. This is all it does.

In contrast, both NIS and LDAP are directory services. They allow a client to query them for information about users (what is your home directory? What is your user ID?). Both can be used as authentication sources with varying degress of problems.

NIS doesn't really perform any authentication for you on its own. Rather, it exposes a password hash to client machines, and your local system performs the actual authentication step the same way it would for local accounts. The problem here is that anyone with an account on one of your NIS clients can grab all your password hashes, and then mount a brute-force attack on them at their leisure.

LDAP is somewhat more secure, since the authentication step is actually performed on the server. You have to make sure you're encrypting your LDAP sessions with SSL or TLS, otherwise the password is exposed in cleartext on the wire, where it is vulnerable to packet sniffing.

It is very common to use Kerberos for authentication and then either NIS or LDAP for authorization (typically this means "group membership") and directory information. I would argue that NIS, once you have removed the password hashes (by moving your authentication to Kerberos) is not really less secure than LDAP, and has the advantage of being available "out of the box" on any modern Linux distribution.

LDAP, on the other hand, is generally far more extensible, scales better if you have a large number of users (or other directory objects), provides for rich queries, and is generally more manageable. LDAP is also supported natively in a variety of applications, while NIS has a weird incestuous relationship with the core operating system that may be undesirable.

If you are building things from scratch, I would suggest Kerberos for authentication and LDAP for your directory service.

Filesystems

NFS has a big advantage: you already have it, it's widely deployed, and it's generally stable. There are two primary downsides to NFS:

• It doesn't scale well for parallel i/o. If you've got a large number of machines hitting the same filesystem, your single NFS server may have a hard time keeping up. This is why larger clusters typically use a cluster filesystem (like Lustre, GlusterFS, GPFS, GFS, etc) that has been designed to supported parallel i/o.

• It has a bad security model. Generally, NFS security decisions are based entirely on your numeric user ID. If you have root on a system that can mount an NFS filesystem, you have access to all of the files -- because you can always create a local user with the appropriate user ID. This isn't strictly true, because both NFSv3 and NFSv4 have various levels of support for Kerberos authentication, but I have yet to meet anyone using this...so your milage may vary.

For small deployments, most people just use NFS despite its limitations.

There are a variety of other solutions -- the cluster filesystems I mentioned above, as well as AFS and others -- but most of these will require some work on your part to get them running on whatever distribution you have selected. I've heard good things about GlusterFS recently, so if I were looking for an NFS alternative that might be the first place I look.