Securing Your Windows Files

Introduction to Securing Your Windows Computer Files

This document is intended for people who want to know what steps they can take to protect the files on their Windows computer from people they're not sure they can trust. For more in-depth information, we strongly recommend the Microsoft whitepaper called Default Access Control Settings in Windows 2000.

Quick overview

To make a file secure you need to specify which groups or accounts can have access to the file by making changes to the file’s security settings. Your file will, by default, already be allowing certain groups and accounts to gain access, but these default settings are not always appropriate for your situation. Note that "groups" are sets of accounts. The degree of access itself can vary from "no access" to "complete control" of your file. Other people can access the files on your computer over the network by using what Windows calls a "share." A share advertises which files on your computer are available to other Windows computers. Note, however, that a share has its own security settings, in addition to the security settings of a file. A person who connects to your files using a share must therefore have access permissions in both the share's settings and the file's settings. By default, your computer doesn’t have any shares, so you can restrict remote access to your files simply by never creating any shares. To enable others to access your files, you create shares. The next section explains the concepts behind Windows access control in more detail. The last section steps through the process of creating a new share with access secured to only a small set of people.

Windows Security Concepts

Authorization

Windows has many different objects that you might like to secure. These objects include files, printers, and shares. In computer lingo, the process of securing an object is called configuring authorization or access control. To set access control on an object, you need to designate two things: who can have access and what kind of access they can have. These two pieces of information -- who can have permission and what kind of permission they can have -- comprise an "access control entry" ... ACE for short. Every account or group to which you grant file access is in a separate ACE, and each ACE can have different access permissions. The list of access control entries available for an object is called the access control list, or ACL

for short. An ACL has two parts. For the most part, you'll work with the discretionary access control list or DACL, which consists of the capabilities and functions we've discussed so far. The other part of an ACL is called the system access control list or SACL, which controls which object access should be recorded by the computer to a log file. This record of access is called auditing, and allows you to find out who has accessed sensitive objects. You can find out how more about how to use auditing in the "How to set permissions" section below.

Note: Who has access is specified with an account or a security group (which consists of accounts), but for the purposes of simplifying the explanation we’ll presume the who is a person.

The access each person has is broken into two components. The first component is whether the person is allowed or denied a permission. Deny permissions override any other permission. If somone sets both an allow permission to you, and a deny permission to you, you still won’t have any access at all. An ACE that denies everyone full permission or denies authenticated users full permission can be very dangerous, and is not recommended. The absence of an allow permission is a much safer way to keep people away from your files than explicitly denying each suspected party access. That said, circumstances do exist where you might want to ensure that a specific person never gets a certain kind of access. For example, say you know that a certain person has a history of accidentally deleting files; simply deny that person the delete permission. The second component is the actual permission. The complete list of possible permissions is large but, fortunately, there is a general list of permissions that allow the usual kinds of access you will want to grant. This general list of permissions includes Read, Read & Execute, Write, Modify, and Full Control.

Read allows one to view the object (e.g. someone would be able to read your wordprocessing document).
Read & Execute allows one to run a program (called an executable or .exe).
Write allows one to make changes to the object’s contents.
Modify allows one to modify the object itself (e.g. renaming a file).
Full Control grants all of the permissions above plus the ability to set the access control (ACL) for the object.

If you would like even more granularity in the permission you give to someone (e.g. for whatever reason, you want someone to only be able to delete a file), there are thirteen advanced permissions that break this list into smaller components. You can find out how to apply the advanced permissions in the "How to set permissions" section below.

In addition to the advanced permissions, there are three other concepts regarding access control that you should be familiar with.

Inherited Permissions This refers to permissions that are automatically passed on to your file by the directory in which your file was created. This directory, called your file's parent directory, has already had permissions set for it prior to the creation of your file. These permissions are passed on to your file by default, unless you specifically tell your file not to inherit permissions from its parent. Your file can obviously inherit a lot of different permissions if its parent directory is nested in several subdirectories. If, for example, the path to your file was c:\docs\project\myfile.doc, note that the project subdirectory is parent to your file, as is the docs subdirectory, as well as the c:\ subdirectory (known as the root). Each of them would pass their own peculiar set of access control permissions on to your file. On the other hand, you can use inheritance to your advantage. If you stored all the documents you shared with other people under a single subdirectory (say c:\docs\), you could easily give someone permission to read them all, regardless of where they were nested under that subdirectory, by simply adding a single ACE on the "docs" subdirectory (instead of adding the permission to each file one at a time).
Moving Files/Permissions When you move a file from its parent directory to another directory it may or may not retain its permissions, depending on the following: [Brian: can you give me a breakdown on this?].
Ownership When someone creates a new file, he or she is listed as the owner of that file. An owner's rights to full acces are built-in ... they don't have to grant it to themselves. Owners can also delegate ownership to someone else. That other person can then take ownership, and have full access to the file.

Accounts

In the note above we stated that the "who" part of an ACE can be an account or a security group (which consists of accounts), but for the purposes of simplifying the explanation we said that the "who" was a person. This is an oversimplification, because an account or security group doesn’t necessarily map to a person. For example, the reader could have 7 or 8 accounts, and belong to several dozen security groups. By themselves, none of those accounts or groups would define all of the access control that you have. The accounts and groups are simply vehicles you would use to access resources, and that other people can use to grant access to you. You might also log into multiple accounts and use them to access different resources (via the Run As … command).

In Windows, accounts can belong to two different kinds of contexts. They can belong to domains or local computers. What “belong” means in this context is that either the domain or the local computer verifies the account. So if you log in with a domain account, the domain checks your password. If you log in with a local computer account, the local computer checks the password. This process is called authenticating or verifying your credentials. There are many different domains and computers out there that have accounts, so you will need to know more than simply a username or group name ... you must also know the context. For example, if you wanted to give me access to your files, you would have to specify win\barkills (where win is the domain, and barkills is the username). You might also specify bobafett\brian (where bobafett is a computer, and brian is the username). But in general, you’d give the win domain account access, because that is what most Stanford people will use during their regular business.

Security groups also belong to either a domain or local computer context. There are several different types of groups, and the different types determine which accounts can be a member, and whether you can use that type of group on a resource. The following table shows the common types of groups, with examples. If this is your first introduction to the group types, just skim the table for now—you can always come back later.

Name	Where can you use this group?	Accounts/Groups from which context can belong to this group?	Which type of groups can be members
Computer local group	That computer only	Local accounts and any domain account/group	All types
Example: Bobafett\administrators	Only on the Bobafett computer.	Bobafett\brian, win\barkills, it\mygroup and win\mygroup can all belong.	Computer local group Bobafett\Users, domain local group it\cams, and domain global group win\mygroup can belong.
Domain local group	Same domain only	Any domain account/group (except domain local groups in another domain)	Domain local and global
Example: IT\cams	Only on computers which belong to the IT domain	win\barkills, it\mygroup, and win\mygroup can belong.	Domain local group it\cams, and domain global group win\mygroup can belong.
Domain global group	Anywhere	Accounts/groups from same domain only	Global
Example: IT\Domain Admins	Any computer in any domain	It\mygroup and it\visitoraccount	Domain global group it\mygroup can belong.

Local groups should always be used in ACLs on your resources. Then you control which accounts have access by adding accounts, domain local groups or domain global groups to the local group. We’ll be demonstrating that in the next section, "How to set permissions", and also go over the other concepts we’ve discussed.

You should be aware of one last set of information to complete your overview of the basics. There is a set of default accounts and groups that are standard on every Windows computer and domain. All of these default accounts and groups are listed here, with a short description of what they are. Several are worth noting specifically, because they are very useful or widely used. ‘Everyone’ stands for every possible account (whether or not they are from Stanford or across the Internet). It can be a dangerous group to use, but can be useful when you want to give open access, say to some files on a website. ‘Authenticated Users’ stands for all accounts that have been authenticated by some trusted system (i.e. they are from somewhere connected to Stanford). It is a more secure alternative than ‘Everyone’ for a public access setting. ‘Domain Users’ is the set of all user accounts in that domain. If you used WIN\Domain Users, it would be the set of all SUNet accounts. It is worth noting that SUNet accounts are available to people who are loosely affiliated with Stanford. ‘Users’ is a group local to your computer comprised of user accounts which are allowed some basic level of access to the local computer. By default, ‘Domain Users’ are a member of ‘Users.’ You may not like this default setting, because it lets someone other than yourself log into your computer. ‘Administrators’ is the group local to your computer comprised of user accounts which have full access to all resources on the local computer. By default, ‘Domain Administrators’ is a member of ‘Administrators.’ Again, you may not like this setting. ‘System’ stands for the account that the operating system on your local computer uses. Don’t remove it from any ACLs, unless you want serious problems.

How to set permissions

The following section in detail steps through the process of securing shared Windows files. The steps that will be illustrated include: creating a file share, setting share permissions, creating a local group, setting membership of a local group, setting file permissions, removing inherited permissions, using the advanced permission list, and setting file auditing.

As an example scenario, let’s say we are managing ProjectX, for which there are several important files which need to be shared among the project members. We would like to let project members read them, let an assistant modify them (but not delete them, as he has a history of doing), and keep full control for ourself. No one else should have access, and we’d like to monitor any attempt to delete the files.

Here’s a folder on our C:\ drive with all the project files within it:

To share these files, we need to right click on the folder, and choose “Sharing …” as shown below:

The sharing tab of the folder’s properties window should come up. We need to select the radio button to “Share this folder.” By default, the name of the folder is used as the share name, but we could change it if we wanted.

By clicking on the permissions button, we can view and modify the share permissions. Note that the default share permissions give everyone full control. We’ll leave this alone, because we can use file permissions to secure the files.

After choosing OK to both the permissions window and folder property window, we now see that a new icon is on our c:\ProjectX folder. This new hand icon indicates that a share is active.

Now we need to create a local group to use when setting file permissions. Right click on “My Computer,” and choose “Manage.”

The “Computer Management” MMC tool should load. There are many things you can do here, but we want to choose the “Local Users and Groups” option, and choose the Groups. Under the Action menu, we want to choose the “New Group …” command.

We call our new group ProjectX, and see a window displaying that there are currently no members of the group. Using the Add button, we will soon change this.

The “Select Users or Groups” window appears, and we need to choose what context we want to “Look in.” We want to add a group in the SU domain, so we choose it. After choose the “Domain Users” group from the SU domain context, we change the context to the WIN domain, and add a few other project member’s user accounts.

After selecting users or groups to add and clicking OK, we see a list of all the members of the group. Click OK to this window as well.

Right click on the c:\projectX folder to see the following menu. We want to choose the properties option.

On the ProjectX properties windows which opens, select the “Security” tab. Here you will probably see the default ACLs set, with Everyone given full control. To change this, we need to uncheck the box “Allow inheritable permissions ….”

You should see the following warning window when you uncheck that box. Go ahead and choose to copy. This will copy all the inherited ACEs, and then we can manually remove the undesired ones.

After this, you notice that the check boxes under the “Permissions” section for the Everyone entry are no longer grey. When you see grey checkboxes, it is a visual indication that there are inherited permissions of some kind. Go ahead and click the remove button, and remove the Everyone group. Then click the add button.

You should see the Select Users or Groups window again, just as you did when choosing members of the local ProjectX group. Now we need to give that ProjectX group access, so we’ll pick the local computer as the context (Note that my computer is named Bobafett—your computer will be named something different) and select the ProjectX group. I’m also going to add myself and my assistant.

By default, new entries will have the Read & Execute, List, and Read permissions as below. This happens to be the permissions I want to give the ProjectX group members.

However, I need to give myself Full Control permissions. Simply checking the Full Control box will fill in all the other permission boxes automatically. For the time being, I will also give my assistant full control.

Click on the “Advanced …” button. Below you see the windows which opens, entitled “Access Control Settings for ProjectX”, with my assistant’s Full Control permissions selected.

By clicking on the “View/Edit …” button, I can see all the incremental advanced permissions possible in the windows entitled “Permission Entry for ProjectX.” Note how I can choose that my modifications apply to different contexts. By default, modifications are applied to “This folder, subfolder, and files.”

You’ll recall that my assistant has a problem deleting files that shouldn’t be deleted. So I’m going to take away that permission by selecting the Deny checkbox under both “Delete Subfolders and Files” and “Delete.”

After clicking OK to the Permission Entry window, note how the modifications are listed. My assistant has two different entries (ACEs), one for the permissions he is allowed, and one for the permissions he is denied.

After clicking on the OK button, you should see this warning message. This is normal, and is warning you that the deny permission can cause unintended effects when used with groups. Go ahead and choose Yes, because we are applying a deny permission to a single user.

Note that my assistant’s entry in the “ProjectX Properties” window on the Security tab does not completely display the permissions he has. This is normal, but you should remember this and look at the advanced permissions whenever you encounter a situation that doesn’t work as expected.

Go ahead and click the “Advanced …” button again, and select the “Auditing” tab. We now want setup auditing for any file deletions or attempts.

Click the “Add ..” button, and select the options below. This will let us know when someone successfully deletes a file (our account should be the only with that permission), or unsuccessful attempts (maybe our assistant or the other project members).

Go ahead and click OK to the “Auditing Entry” Window, OK to the “Access Control Setting” window, and OK to the “ProjectX Properties” window. We’re done! To see auditing entries from file deletions in our project folder, we would need to monitor the Security log via the Event Viewer. Obviously there won’t be any entries until a file deletion is attempted.

Some ideas taken from Adding Domain Users/Groups to Local Computer Groups document

at UCB, University of Colorado, http://www.colorado.edu/its/windows2000/adminguide/OUdesign.html

Last modified by barkills at 8/22/2001 2:05:32 PM