(Update June 4, 2005:) I've elaborated on the use of command line tools, batch files and scripts for (Windows) Network and System Administration in Automatic Network and System Administration in the Small Office, where you'll find exemples of scripts for user and computer management, Active Directory Organizational Units, Software Deployment and Management, Unattended Operating System Setups, and much more.
Assume we've set up Windows NT on a machine with at least two partitions.
The C:\ partition is Windows NT boot and system partition, it contains the winnt directory and some other files, such as boot.ini, the configuration file for the boot loader.
As this was originally a FAT partition that has been converted to NTFS during Windows NT Setup, the default NTFS permission 'Everyone - Full Control' has been set to all files and directories. So for starters, we remove 'Everyone - Full Control' from the c:\partition, leaving Full Controll to Administrators and System, and maybe 'Change' permission to ServerOperators.
As all directories on this partition have 'Everyone - Full Control', and there is no reason that any user should ever need to make changes to the configuration of our operating system or the domain, we decide to opt for 'Replace Permissions on Subdirectories' and 'Replace Permissions on Existing Files' on this partition. Newly created files and subdirectories inherit the NTFS permissions of their parent directory, so that's covered as well.
That should at least give some protection against users/intruders who want to mess with the Windows NT configuration (or wipe out the system).
As all partitions may have gotten 'Everyone - Full Control' during setup, we remove this permission from all partitions, and replace it with Full Control for Administrators. We can then work out more specific user access later. Partitions that you want to use for virtual memory (pagefile, swap file) need to allow read/write access to the operating system ("SYSTEM") as well.
The data partition D: is the partition that contains the files the users will want to read, change create, move, delete, ... In this partition, the difficult task begins of distributing files over directories and subdirectories, and setting permissions for users and user groups using both NTFS Access Control Lists, in a consistent and manageable manner. As we want the employees to use these files from their workstations, shares will need to be created, and permissions set to these shares to regulate network access to the company's resources.
Consider the Silly Software Company, a small software producing firm with a programmers team, headed by the chief programmer, a financial department consisting of a financial director and a secretary/bookkeeper, its in-house network and system administrator who's also the helpdesk of the staff, a marketing team, and a general manager. Introducing the 'users' :
We create (domain) user accounts for all users so that the'll be know in the domain and can be given access to resources. By default, all users are made member of de group Domain Users.
Next, we create Global Groups to group the users, according to their responsabilities. We thus create the following groups :
Unfortunately, people will have different role. For instance, the chief programmer, the marketing director and the financial director will share certain managerial responsabilities and therefore need to share information. We thus add a group :
Users are organized in Global Groups. Resources are managed through local groups. So we'll have to create local groups, and make the global groups member of a local group. Because the global groups alrerady reflect the structure of the company, and access to information will be organized accordingly, it makes sense to create a corresponding local group for each global group. We can not use the same group name twice, so we create local groups lg.. to match the global groups, then make the global group member of the local group : FT member of lgFT, PT member of lgPT, etc.
This seems a duplication of effort, but it does make sense, in a way. Imagine the case where the programmers would use their own file server. You would then create a local group lgPT on that server, and make the (global group) programmers member of this local group. Other global groups (and the members of those groups) would have no access at all.
On an other file server, the same global group programmers can then be made member of say, a local group 'employees' that allows them an appropriate level of access to files that all personel should be able to read. Or something along those lines ...
Global groups are also intended to make users known to other domains, or to allow users from other (trusted) domains to log on to your domain.
Local groups are only known on the machine they have been created on, and can therefore be given access to the resources on that machine. Local groups that are created on a Domain Controller (PDC or BDC)however, are known to the domain, are 'local to the domain' so to speak. Local groups created on a domain controller therefore can be used in stead of global groups to organise user accounts. They will be known to any machine that is member of the domain, making the need for global groups redundant.
Assuming that the groups reflect the way the work is organized, we can start by creating 1 directory for each group, such as data\finance, data\marketing, data\hr, etc.
Relying on NTFS security to fill the gaps in case network security fails, we set NTFS security for these directories to 'Change' permission for the corresponding local group. They've inherited access for the administrator as well.
Next, we share the directory and make it accessible to the corresponding group. Remove the 'Everyone-Full Control' that has been set by default. If necessary, access for Administrators can be set as well, although that can be misused if a user succeeds in creating an account that is member of Administrators, or through some other NT exploit. If the administrator can manage the directory locally, he does not really need network access, but it can be convenient sometimes.
When this is done,
Mind you, none of this will protect against any real intrusion attempts. A simple password cracker may well get through. NT exploit tools may use workarounds or exploit known security holes to give an intruder admin priviligues. this would consequently give the intruder quasi unlimited access to the server. However, it's a (good) start.
In compliance with the rule that global groups are made member of local groups to regulate domain user's access to local resources on a given machine in the domain / network, the group Domain Users is member of the group Users. All user accounts, including Administrator, are member of Domain Users.
We can, for now, take the Domain Users group as 'all Silly Software Company personel' and use that group to give the company staff access to directories, such as d:\personel. It may contain documents of interest for all employees, such as a 'modus vivendi' document or a list with the employee's phone extension numbers.
We may also decide to create a separate group for this purpose, so that we can distinguish between permanent staff and temporary staff, and even - within temporary staff - distinguish replacement staff from additional staff for specific tasks, or from apprentishes etc. Temporary staff may not need to have the same access priviliges as permanent staff regarding sensitive, private, confidential information, business secrets, specific projects, etc.
As explained before, membership of multiple groups creates cumulative access priviliges, which turns out to work just fine to give any user the right level of acccess according to the group or groups he belongs to. However, it may become hard to remember for each staff member which group or groups he should or shouldn't be made member of. It might be sensible to develop company policy, and document it, e.g. by adding to job titles or functional descriptions a list of the groups this person / function should be made member of.
For now, network administrator Ned has decided to use the group Domain Users / Users, and give them read permission to D:\personel. The HR group (through lgHR) gets 'Change' permission to this directory so that they can add, delete, and edit files in that directory.