I'll have a go :)
My 2p:
A Windows domain is an authentication-and-authorisation space, defined
by a database of all usernames known within that space, together with
their passwords, group memberships and much more related stuff. The
username database (held as a set of files of course) is managed by one
or more servers dedicated to the task of processing logon attempts,
verifying passwords, authorising filesystem access requests, etc.
This type of server is known as a domain controller (or domain server
if you like).
The domain will also contain, in general, many workstations used by
the end-users, and a number of servers holding files, services and
other objects available for the use of the users. The files and
services have permission settings which define which users can access
them and in which ways. The permission settings reference the
usernames defined in the username database.
Any machine (workstation or server) needing to make use of the
username database must be "joined to the domain" (which means
exchanging keys, so that secure communication can occur); we call such
machines "members of the domain" member servers, member
workstations. In a medium to large organisation there are usually
quite a few member servers dedicated to file serving, some to web
serving, some to print serving, and a few to more esoteric tasks (SQL,
DNS, DHCP, WINS [does that still exist ?], etc. etc.).
You could refer to these servers as fileservers, webservers,
printservers, SQLservers, DNS servers, etc. you see the pattern
here ? :-)
You /can/ combine some of these server roles (including domain
controller) in one physical server, but you must be careful about
performance, especially in geographically dispersed networks. Note
that all access requests must ultimately effectively be processed and
approved by the domain controllers, which can make them pretty busy
machines - so that job is often done by dedicated servers.
There may also be other Windows servers owned by the organisation,
which are not members or controllers of the domain - these servers are
known as stand-alone servers, and their users will not share the same
username & password database as is used within the domain.
Steve> Are there any guidelines for this sort of stuff?
Yes. In the Microsoft world, typically the sysadmins all go on [gulp]
"MCSE" (Microsoft Certified System Engineer) training programmes,
where all this stuff is taught in some detail - including how to
estimate performance requirements from expected user population &
required data flows, and thus how to arrive at an effective network
and domain design. Usually you discover that you need an unbelievable
number of servers, and that the cost of server licenses and "client
access licenses" (an iniquitous concept) is likely to bankrupt your
employer ;-) After your boss has had a heart attack, you think
about Samba
I don't know whether or not there are FOSS-world courses which teach
the same (CIFS/SMB/AD) concepts.
You can also find any number of $50 text books on the subject
("Windows Active Directory") in any decent bookstore.
e.g. http://shop.oreilly.com/product/0636920028932.do
Active Directory Cookbook, 4th Edition
Solutions for Administrators & Developers
(but they will usually be focused on Microsoft products).
BTW: if you don't already know about it, you really should also try to
learn as much of the stuff on this website as you possibly can :
http://ubiqx.org/cifs/
It's more about the protocols, rather than domain design - but still
important for a sysadmin (and it's by one of the Samba team).
[I hope this helped ... maybe you already know all this stuff, and I
didn't understand your question .. it was fun trying anyway :)]
Good luck.
Nick
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
