Thank you TB0ne for your helpful response.

The office in question does consist of about 15 users, some full-time and some part-time. Manually administering so few accounts really isn't cumbersome per se, but I'm only a contracted supporter, so I'm not on-site for much of the week.

I agree that LibreOffice may do better for them, especially considering how much it will save them.

Part of the confusion of this thread also arises from my hazy understanding of things like AD, LDAP, Samba, etc. I know what they mean and what they do, but I have a foggy grasp of how they interact and how they are implemented in the detail. This whole project is designed to change that

In my perfect little naive world, there would be this drop-in *nix replacement to SBS2003 that does everything it can and more, from either a shell or a web GUI. It sounds like we're headed in that direction, but perhaps not there quite yet.

So far, it sounds like CentOS running Samba 3 will serve me well. I guess at this point I'm not clear on how all the pieces fit together.

1. I spin up a CentOS server in the existing SBS2003 domain.
2. I install Samba and SSH services.
3. I configure Samba shares to mirror the shares on the SBS server. I do likewise for print queues.
4. ??
5. ??
6. Windows and Mac clients can now authenticate to the server to access said printers and CIFS shares with centrally-managed credentials and permissions.
7. I can spin down the SBS2003 server.

you are on the right track. to be blunt is there any real reason to deal with AD for only 15 users?

use Samba/LDAP/Kerberos combination to deal with the authentication and shares for hardware and files. also run NFSv3 for your Mac clients. *side note* for your Mac clients to connect you can not use NFSv4 and you have to run NFSv3 with the insecure flag in your /etc/exports

[code][user@centos ~]$ cat /etc/exports
#
# /etc/exports

# NFS4
/exports *(rw,insecure,subtree_check,crossmnt,fsid=0)

# NFSv3
/exports/centos/public *(rw,insecure,no_subtree_check,fsid=3010)
/exports/foo *(rw,insecure,no_subtree_check,fsid=3020)[/quote]

that is my exports for my mixed network. I have Linux clients, Mac clients, and one win7 box that connects via SAMBA.

SSH btw is already installed by default with CentOS and your Mac clients will also have SSH clients/servers installed. As for SSH client for MS clients just use Putty. Not that they will need it. You will be better off with something like FileZilla or WinSCP to graphically transfer files between MS and Linux. That would be if they are transferring files that are outside of the Samba shares or administrating the server via putty.

1 members found this post helpful.

Shouldn't be much of an issue. Remote SSH access is easily done, and if you only need it every now and then, you can do it. You can also use such tools as Webmin to let a trusted (?) user do basic user management via a web browser, when you're not there.
I'd say we're about 95+% there, if not more, already. The parts of Windows that aren't there (like shoveling out updates, etc.), may NEVER work, but basic user authentication, resource sharing, etc., are ready to go now.
Omit steps 4 and 5. 1-3 should be what you need, and if you stick with basic Linux user accounts (local accounts), you won't even need LDAP. A user will be presented with a login box when they try to map network resources (the Samba share(s)), when they power up in the morning. They enter their Linux user ID/password, and they're authenticated, drives mapped, etc. Done.

LDAP would make things easier if you want to plan for growth, but it will be a little bit steeper of a learning curve. It will be worth it in the long run, though, since you can then use it for ANYTHING that supports LDAP.

Great stuff, thanks again.

Reasons I may want to keep AD:

1. GPOs are nice when I need to manage configs for multiple windows boxes. Not a huge loss, but it does make some chores much easier. But this reason alone isn't enough to keep AD.
2. I'm pretty sure that's it. What are some other things that *only* AD offers? I'm still a bit hazy as to what AD is and what it is not.

Reasons I may want to use LDAP:

1. The organization may grow, so I want to keep the solution scalable, especially if I'm going to put this much time and energy into it.
2. Keeping machine login credentials unified with shared resource credentials strikes me as very wise. In the current setup, if a user changes his/her Windows password, their shared resource password changes too (actually, they're just the same). If at all possible I want to preserve that.

Hmm, it seems reasonable that I can start without LDAP, then drop it in if/when it becomes necessary. That way I can spread out the workload over time. Mac users already map shares with separate server credentials, and users don't change their passwords very often anyway. As I recall, Windows also will cache Samba credentials, so the user doesn't have to enter a password every time they boot.

A solution is getting closer! But--

I can think of one thing that hasn't been addressed.

In the current setup, any user can login and access their personal files from any other office computer. This has been invaluable when user A's computer flips out, so she logs in to user B's computer and continues work like normal. This is only possible because they authenticate to the domain, which maps her network documents folder accordingly. To achieve something like this without the domain, I would have to manually set up every user account on every computer in the office. No way.

So the question becomes: What is the way to offer this ability with CentOS? My ideal solution will work with Windows and Mac clients seamlessly, but again, I may be naive

Yep, that is a good thing.
It MAY, but I'd disable it because.....
...if you cache it, then the users will be authenticated to ONE MACHINE. By disabling that, you'll make the log in each morning. So, if user A's computer dies, they can log in to another computer, and (after logging in), will be able to access their shares. Also be aware that if you do cache things, and users don't have to log in each morning....there will come a time when their passwords expire, and they won't get attached to their resources. When that happens you'll have to address each machine, clear cache/saved, etc., rather than just reset a password and tell them to reboot.
LDAP...install it from day one, migrate things over, and be done with it. You'll go from one centralized system to another, and your users won't really notice the difference.