Share and NTFS Permissions


Microsoft Windows has both Share and NTFS permissions to secure access control to its protected objects. Each permission can be configured as Allow or Deny. Deny overrides Allow if set at the same level (see the "Inheritance" section below). Permissions can be set per file (except shares), per folder, per user, and per group.

Contrary to popular belief, Microsoft has some of the best security of any popular operating system on the market today. I challenge anyone to find a popular OS that has 28 different permission settings per file or folder. What Microsoft doesn't always have perfect are the default security settings. This section discusses Share and NTFS permission in detail.

Share Permissions

Share permissions apply only when a resource is contacted over a network connection (or even when accessed locally through Network Neighborhood or a NetBIOS connection). Share permissions are available whether the file system is FAT or NTFS but can only be set at the folder and printer level. If you want to share a file or group of files, you must place them in a folder and share them. If your file system does not use NTFS, the Share permissions are the only security permissions you have.

There are only three folder share permissions (see Figure 3-9):

  • Full Control

  • Change

  • Read

image from book
Figure 3-9

When permissions are set at the folder level, they are inherited (covered below) by the objects contained in the folder and below by default, but objects permissions can be set to differ. And, of course, if there are underlying NTFS permissions, they apply as well.

Most people think the Read permission only allows a security principal to view an object, when in fact a lot more can be accomplished. The Read permission allows a security principal to view, copy, and print (if applicable) the resource. If the share contains a program, the security principal can execute the program. The Read permission also allows the user to traverse a folder to get to another folder below it (more on traversing follows). The copy operation can be problematic securitywise.

If a user has Read access to an object, then that user can copy it to a new location and, in most cases, get Full Control to the new copy. This is because when an object is copied, a new, second copy ends up in the new destination. If the destination has Creator Owner permissions with Full Control (as is often the case), the security principal who copied the object is the Creator Owner of the new copy and gets Full Control. This is security as designed. The copier cannot copy the object, modify it, and then copy it back over the original object — the original object's integrity is protected. However, most administrators are surprised that Read access allows the reader to gain Full control of the copy, so be aware that every-where users have Read access, they can make a copy of the object and do with it what they want.

Note 

Microsoft has a new digital rights management feature called Rights Management Services (www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx) that can help prevent users from copying and printing objects, although it is not foolproof.

The Change permission allows the related object (and any subfolders or files) to be added, viewed, copied, printed, modified, and deleted. No surprises here, although some administrators aren't always sure whether the Change permission allows the object to be deleted. It does. The Full Control permission allows a security principal to modify the share permissions (and any contained files or subfolders) as well, but the user must be a power user or administrator to access Share permissions in the first place, so usually this isn't a problem. This issue becomes more important when setting NTFS permissions (see below). Full Control share permissions also allow a user to Take Ownership if the underlying NTFS permissions allow it.

New Shares

Shares can be created by an administrator or power user by right-clicking any folder or printer object. The creator can then assign Share permissions and choose whether or not to limit the number of concurrent connections (Microsoft Windows workstation OSs are limited to 10 concurrent connections by default). Home editions of Microsoft operating systems are often limited to a maximum of five concurrent connections.

Regular end users cannot create shares. Sharing requires that the NetBIOS protocol and the File and Printing Sharing service be enabled.

The Everyone group is automatically given Read share permissions with new shares in Windows XP and later. In Windows 2000 and NT, the Everyone group was given Full Control share permissions, although in either case the underlying NTFS permissions control the effective rights given to a security principal. A commonly held mistaken belief is that all users get Full Control to all files and folders on a Windows PC. That was never true. As stated above, it was true for share permissions but never for NTFS permissions. The controlling NTFS permissions were whatever the administrator assigned them to be, or whatever the security principal inherited. If NTFS permissions are not set, then the most commonly inherited permission is Read & Execute. While this might be more permissions than an administrator might mean to give, it is a far cry from Full Control of all files and folders on the Windows PC.

Note 

A FAT-formatted volume would not have any offsetting NTFS permissions so the Full Control permissions of any shares would apply.

New Share Recommendations

Whenever creating new shares, administrators should remove the Everyone has Read permission and replace it with whatever is the least privileges necessary. Many resources recommend setting all shares with Everyone Full Control permissions, but this voids the least-privilege principle. You should strive to set the tightest permissions you can on both the share and NTFS permissions side.

Unfortunately, Microsoft has not made it easy to change the default share permissions on new shares to something other than Everyone Read. Microsoft did release a nonpublic regedit hack that allowed administrators to set new defaults for new shares, but the registry hack was wiped out accidentally by a hotfix and wasn't all that accurate anyway. It is hoped that Microsoft is renewing plans to allow administrators more granular control over new share permissions. Lastly, most non-admin users never need Full Control to a share. Consider giving Change permissions instead.

Hidden Shares

Since Windows 3.1x, Microsoft has allowed administrators to make hidden shares. By placing a $ (dollar sign) at the end of a share name when creating it, it becomes "invisible" to NetBIOS browsing. But if you know the name of the hidden share and the correct logon credentials, you can map a drive letter to the hidden share. Just be advised that several enumeration tools will reveal hidden shares. For the most part, hidden shares are just used to keep interested end users from discovering them too easily. By default, Windows makes a hidden drive share (called an admin share) for each active drive letter on a Windows system (i.e., C$, D$). Also, an administrator can create a published share in Active Directory that points to a NetBIOS share. They cannot be made hidden by placing the $ at the end of the name, and are not present in NetBIOS sharing lists. Active Directory published shares only show up in Active Directory object enumeration (e.g., Active Directory Users and Computers).

All drive shares, regular and hidden, should be password protected and require strong passwords. Many scanning worms look for drive shares and do password guessing against them. Weakly password-protected shares can result in compromised files. Conversely, password-guessing worms can sometimes cause inadvertent DoS attacks if account lockouts is enabled (see Chapter 4).

Note 

This section does not cover printer shares, which are at low risk for attack; nor does it cover other available file-sharing mechanisms such as FTP or Distributed File System (DFS).

NTFS Permissions

NTFS permissions are available to protect files, folders, registry keys, and other objects when the NTFS file system is installed. As long as NTFS is being used, NTFS permissions apply, whether the resource is being accessed locally or remotely. There are few legitimate reasons why NTFS can't be installed as the file system, with the notable exception of dual-booting machines with other operating systems that don't understand NTFS and troubleshooting issues that arise when NFTS used (i.e., a normal FAT boot disk can't be used to access NTFS-protected drives). NTFS must be installed to enable many Windows features, including the following:

  • NTFS permissions — file and folder level

  • Auditing

  • Active Directory

  • Disk quotas

  • EFS encryption

  • Compression

To modify NTFS permissions, simply right-click the object and choose Properties ð Security. There are seven different "summary" file and folder NTFS permissions (see Figure 3-10) created by a combination of 14 special permissions (see Figure 3-11).

image from book
Figure 3-10

image from book
Figure 3-11

The seven summary file and folder permissions are described in Table 3-5.

Table 3-5
Open table as spreadsheet

Permission

Effect

Read

View, copy, print, and rename files, folders, and objects. Cannot launch executable programs unless executing a script file that launches another executable with Read & Execute permissions.

Can read object permissions, read object attributes and extended attributes (e.g., EFS, Archive bit, etc.). Lists files and subfolders in a folder.

Write

Read permissions, plus create and overwrite files and folders

List (Folders Only)

Allows viewing file names and subfolder names within the folder

Read and Execute

Read permissions, plus allows the execution of program files

Modify

Allows all permissions except the ability to Take Ownership and set permissions. Allows reading, deleting, changing, and overwriting of files and folders.

Full Control

Full control over this file or folder, including the ability to set permissions and Take Ownership

Special

Selected when the underlying 14 more granular permissions are selected or combined in ways that don't make up one of other six summary permissions. Also, includes the Synchronize permission.

Table 3-6 discusses what each special permission allows.

Table 3-6
Open table as spreadsheet

Permission

Effect

Traverse Folder/Execute File

Traverse Folder allows moving through folders to reach other files or folders, even when the security principal has no permissions for the traversed folders. (Applies to folders only.)

Traverse folder takes effect only when the security principal is not granted the Bypass traverse checking user privilege (which the Everyone group is given by default).

For files: Execute File allows or denies running program files.

Setting the Traverse Folder permission on a folder does not automatically set the Execute File permission on all files within that folder.

List Folder/Read Data

List Folder allows viewing file and subfolder names within the folder.

List Folder only affects the contents of that folder and does not affect whether the folder you are setting the permission on will be listed.

Read Data allows or denies viewing, copying, and printing files.

Read Attributes

Allows or denies a security principal the capability to see an object's attributes (e.g., Read-only, System, Hidden, etc.)

Read Extended Attributes

Allows or denies a security principal the capability to see an object's extended attributes (e.g., such as EFS, Compression, etc.)

Create Files/Write Data

Create Files allows or denies creating files within the folder. (Applies to folders only.)

Write Data allows or denies making changes to the file and overwriting existing content. (Applies to files only.)

Create Folders/Append Data

Create Folders allows or denies creating folders within the folder. (Applies to folders only.)

Append Data allows or denies making changes to the end of the file but not changing, deleting, or overwriting existing data. (Applies to files only.)

Write Attributes

Determines whether the security principal can write or modify standard attributes (e.g., Read-only, System, Hidden, etc.) of files and folders. Does not deal with writing files or folders, only their attributes.

Write Extended Attributes

Determines whether the security principal can write or modify extended attributes (e.g., EFS, Compression, etc.) of files and folders. Does not deal with writing files or folders, only their attributes.

Delete Subfolders and Files

Allows or denies deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file. See below for unexpected consequences of this permission.

Delete

Allows or denies deleting the file or folder. If you do not have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files on the parent folder. See below for unexpected consequences of this permission.

Read Permissions

Allows or denies reading permissions of the file or folder, such as Full Control, Read, and Write. Does not involve reading the file itself.

Change Permissions

Allows or denies modifying permissions of the file or folder, such as Full Control, Read, and Write. Does not involve reading the file itself.

Take Ownership

Determines who can take ownership of a file or folder. Owners can always have Full Control, and their permission to the file or folder cannot be taken away permanently unless their ownership is taken away as well.

Synchronize

Not manipulated much by administrators. Deals with synchronization issues with multi-threaded, multiprocess programs and how multiple threads trying to access the same resource cooperate.

Windows Vista will also have the Creator Owner special permission, as discussed above.

Table 3-7 shows how the 14 underlying "special" permissions make up the seven summary permissions.

Table 3-7
Open table as spreadsheet

Permission

Full Control

Modify

Read & Execute

List

Read

Write

Traverse Folder/ Execute File

X

X

X

X

   

List Folder/Read Data

X

X

X

X

X

 

Read Attributes

X

X

X

X

X

 

Read Extended Attributes

X

X

X

X

X

 

Create Files/Write Data

X

X

    

X

Create Folders/ Append Data

X

X

   

X

Write Attributes

X

X

    

X

Write Extended Attributes

X

X

   

X

Delete Subfolders and Files

X

     

Delete

X

X

     

Read Permissions

X

X

X

X

X

X

Change Permissions

X

      

Take Ownership

X

        

Synchronize

X

X

X

X

X

X

Note 

Registry permissions are covered in Chapter 6.

Each possible access control permission that a protected resource can have is called a Discretionary Access Control (DAC) permission. There are also auditing permissions called System Access Control (SAC) permissions that are involved in object auditing, but this chapter doesn't cover them. A DAC is a specific permission descriptor, such as Read, Write, or Modify. When the DAC is related to a specific security principal (using the SID), it is considered an Access Control Entry (ACE) or permission. An example ACE is the Authenticated Users group having Read permissions to a particular folder. The collection of all the security principals and their permissions to a particular object is called the object's Access Control List, or ACL (pronounced "ack-kul"). If the ACL deals with only security ACLs, it can also be called a Discretionary Access Control List, or DACL (pronounced "dack-kul"). Most of the time when people are referring to an object's associated permissions, they call it ACL or DACL. When determining a security principal's access to an object, the principal's security access token is compared to the objects DACLs).

Note 

Starting with Windows Server 2003 SP1 (and in Vista), NTFS permissions (DACLs and SACLs) can be set programmatically on a per-socket basis. Essentially this means that permissions can be set on a per-connection basis. See http://blogs.msdn.com/michael_howard/archive/2005/10/23/484026.aspx for a quick discussion.

Interesting Permission Interactions

Here are some other interesting permission interactions you may not have known.

Read Permissions vs. Read Attributes vs. Read Data

Must administrators get confused by all the Read labels in NTFS permissions. Read Permissions allows a security principal (or program impersonating them) to read the file or folder's NTFS permissions, and only the permissions. Without that permission, the object's permissions can't be read; the Security tab is grayed when viewing the object in Windows Explorer. Read Attributes and Read Extended Attributes refer to whether a security principal can read the NTFS attributes attached to a particular object. The attributes attached to an object change per object. File attributes are things such as Read-only settings, EFS, and files marked as System files. Read Data is the permission most people are referring to when they intend to let a security principal read the object's contents. The same thing applies to Write (i.e., Write Data, Write Attributes, Write Permissions) permissions. Don't be confused.

Read vs. Read & Execute

The Read permission alone will not allow a program to be executed unless the file to be executed is a script or data file associated with another program to which the security principal does have Read & Execute permissions. For example, if the user only has Read permissions to a folder, but the folder contains VBS script files, double-clicking on the script file will read it into memory and launch its associated program, Wscript.exe, to run the file. This rule holds true for IIS too. Script files do not need Read & Execute permissions, only Read.

What Full Control Really Means

If the user has every NTFS permission but Full Control, that user will lack only the Take Ownership and Change Permissions permissions. Unfortunately, this also means that any user with NTFS Full Control can change the permissions of the file or folder to which they have Full Control. Non-admin users are frequently given Full Control permissions to shares, files, their home directories, their My Document folders, etc. In most cases, you do not want users to be able to change their permissions on those folders. But they can, and they can even (temporarily) remove or deny permissions to administrators.

Note 

If administrators are ever prevented from accessing a resource because their permissions are removed, they can take ownership of the resource and reset permissions.

You Can Write, But Not Read

You can be allowed to write to a file, once, without ever being able to read or view it. The write permission allows a user to overwrite a file, but modifying a file requires the user to have the Read permission as well.

What Is File Traverse?

File transversal allows a security principal to view or execute a file in a folder it would not otherwise have permissions to or see. The security principal or process must know the exact location to the folder and file to reach. By default, the Everyone group has the group policy setting that allows file and folder traversal by default. This privilege should not be modified unless you really, really know what you are doing. The File Traverse right is helpful when you want to allow users into a subfolder without seeing all the information in a parent folder. As Table 3-8 shows, the traversal permission is assigned to the Users group for \Windows\Task and \Windows\Temp folders. Because these are areas that can be common among several users, Windows attempts to keep non-admin users from seeing the others' content.

Table 3-8

File or Folder

Default Permissions (beyond Administrators, System, and Creator Owners having Full Control)

%SystemDrive% (i.e., C:\ most often)

Users-Read & Execute, Create Folders-This folder and below

Users-Create Files-Subfolders only

Everyone-Read & Execute-This folder only

\Autoexec.bat

Users-Read & Execute

\Config.sys

Power Users-Modify

\Boot.ini

Power Users-Read & Execute

\Ntbootdd.sys

Users have no permissions to these files

\Ntdetect.com

 

\Ntldr

 

\Documents and Settings

Users, and Everyone-Read & Execute, Read, List Folder Contents

Power Users-all permissions but Full Control

\Documents and Settings\Administrator

Administrator, Administrators, System-Full Control

\Documents and Settings\All Users

Users and Everyone-Read & Execute, Read, List Folder Contents

Power Users-Modify, Read & Execute, List Folder Contents, Read, and Write

\Documents and Settings\Default User

Everyone- Read & Execute, Read, List Folder Contents (inherited)

No Creator Owner permissions

\Documents and Settings\%UserName%

%Username%-Full Control No Creator Owner permissions

\Program Files

Power Users and Terminal Server User-Modify

\Program Files\Common Files

Users-Read & Execute, List Folder Contents

\Program Files\Windows Update

Power Users=Read & Execute, Write

\RECYCLER

Users-Read & Execute, List Folder Contents (inherited)

\System Volume Information

None for non-admin users

\Windows

Users-Read & Execute, List Folder Contents Power Users-Modify

In W2K, the Everyone group has Read & Execute

\Windows\System32

Users-Read & Execute, List Folder Contents Power Users-Modify

\Windows\System32\Drivers

Users and Power Users-Read & Execute, List Folder Contents

\Windows\System32\Netmon\ Netmon.exe

Everyone, Users, and Power Users-Read & Execute

\Windows\System32\Spool\Printers

Users and Power Users-Traverse Folder/Execute File, Create Files, Read

\Windows\Tasks

Backup Operators-Traverse Folder\Execute Files, Read, Create Files

In XP and later, non-admin users can't create tasks. In W2K, non-admin users can create tasks.

\Windows\Temp

Users-Traverse Folder\Execute Files, Create files and folders

Power Users-Modify

\Windows\Regedit.exe

Users and Power Users-Read & Execute

\Windows\Repair

Users-Read & Execute

Power Users-Modify

\Windows\Security

Power Users and Users-Read, Traverse Folder and Execute File

\Windows\System.ini

Users and Power Users-Read & Execute

\Windows\Prefetch

No access for non-admin users

\Windows\Help

Power Users-Modify

Users-Read & Execute

Terminal Server User-Read & Execute, Write

\Windows\System32\Config

Users and Power Users-Read & Execute

\Windows\System32\Catroot

 

\Windows\System32\DHCP

 

\Windows\System32\Drivers

 

\Windows\System32\Logfiles

 

\Windows\Application Compatibility Scripts

Interactive, Batch, Service-Read & Execute

Users Can Delete When You Specifically Denied Delete

Sometimes an administrator will allow a user to Read and Write a file, but also selects Deny Delete so the user cannot delete the file. Surprisingly, the user can often still delete the file. What is going on? The file's parent folder has the Allow Delete Subfolders and Files permission. This permission allows users in the folder to delete contents. The Deny Delete permission is being overruled by the higher Allow Delete Subfolders and Files. To prevent users from being able to delete files, remove the Delete Subfolders and Files permission on the folder holding the file(s).

Deny Doesn't Always Override Allow Permissions

Another very important point is that although Deny permissions usually override Allow permissions (we saw an exception in the Delete vs. Delete Subfolders and Files permissions conflict), a permission set explicitly on an object will override an inherited deny. For example, I can place a user in a group that has Full Control-Deny permissions to the root directory and tell those permissions to apply to every file and subfolder. But if I go to a lower subfolder and explicitly give the user an Allow permission, the Allow will override the Deny. This is an important fact that will become the basis of a very useful defense in Chapter 5.

Changing Permissions

There are times when a file or folder's permissions may change because of some action. For instance, if you copy or move a file, it may change the file's permissions. When you copy a file, Windows always creates a duplicate new copy of the file in the destination area. The new copy will inherit the permissions of the new parent area by default. You can change them of course. If you move a file from one disk volume to another volume, the file will inherit the permissions of the new area. But if you move a file from one volume to another location on the same volume, the file will retain its original permissions. In class the saying is, "Move the Same Retains, Everything Else Inherits."

Also, normal Windows operations may overwrite the file and its original permissions. For example, when a hotfix overwrites an older file with a new version, it may reset the file's permissions to those of the parent folder. You learn how to use group policy and security templates to overcome this problem in Chapter 14. Another problem area is Windows File Protection (WFP). By default, when a protected Windows system file gets modified unexpectedly (e.g., Notepad.exe is deleted), WFP will note the deletion and replace the file. Unfortunately, the original file's permissions are lost and the new replacement file will inherit the permissions of the parent folder. You may come across other similar issues with Windows permissions.

Note 

Restoring from the Recycle Bin or System Restore retains the original permissions.

Inheritance

By default, all files, folders, and registry keys inherit their permissions from their parent container unless inheritance is turned off. Inheritance can be turned on by file, folder, or registry key, and can apply granularly to one or more security principals. Most administrators don't know that they can selectively turn on and off inheritance on a file-by-file basis, and make it apply on a per-user basis. That's because although inheritance is turned off or on holistically per file or folder, not every permission from above will automatically flow below (i.e., be inherited) between folders. As Figure 3-12 shows, the Apply To field determines whether a particular permission stays in the current container or flows below to subfolders and files. An administrator can set a permission (on a per-user basis) that either does or doesn't flow downward. In this example, the Everyone group has Read & Execute permissions, but the permissions do not flow down.

image from book
Figure 3-12

Effective Permissions

To refresh what you have learned so far: When a user tries to access a protected object, all the SIDs belonging to the user and the groups to which the user belong are collected together and placed into their security access token (along with other information). The user (or the process impersonating the user) hands the token to the Windows security reference monitor process, which compares the user's submitted SIDs to the object's DACLs. The DACL lists all the users and groups, and their allowed or denied permissions. The user's SID list (and access mask) is compared against the object's DACLs to determine what permission apply.

A user's effective permissions (i.e., their real permissions in practice) are calculated from a variety of factors. First, when trying to figure out a user's effective permissions, you must collect together the user's individual account and all the groups they belong to. A quick way to list most of the groups a user belongs to at a point in time is to run the Whoami /user /groups command at the command prompt while the user is logged in. This will reveal most of the groups, but potentially not all of the groups that the user is placed in at the moment of trying to access a file. For example, if you run that command at the user's workstation, it probably won't reveal that the user is placed in the action-based Network group on the remote server they are accessing. Of course, this factoid won't mean anything unless the Network group is assigned permissions to the particular resource the user is trying to access. Just remember that when troubleshooting permission problems, try to gather all the groups the user belongs to, obvious and not so obvious groups.

All the permissions assigned to all the user's SIDs are collected together. If there is a Deny permission set at the same level as an Allow permission, the Deny usually wins. If a Full Control-Deny wins, the user cannot usually access the object. By default, when NTFS and Share permissions are involved (i.e., the user is connecting to resource over a network share), the SRM must collect together all the Share and NTFS permissions. Up to this point, all permissions are collected together cumulatively, although the Share and NTFS permissions are kept separate.

The user's effective permissions are either the set of Share permissions or the set of NTFS permissions, whichever is less permissive (or most restrictive). This is another very important point. At the point of trying to determine the effective permissions, the outcome is the entire set of either the Share or the NTFS permissions, whichever gives less permissions. A large portion of administrators believe that the effective outcome is the least permissive permission, which is wrong. It is the least permissive set of permissions — either NTFS or Share. Let's use Figure 3-13 for our example.

image from book
Figure 3-13

In Figure 3-13, a user ends up with Read and Change Share permissions and Read and Modify NTFS permissions. As Figure 3-13 shows, initially the user had multiple Read permission occurrences because permissions cumulate from the various groups the user belongs to plus any permissions given to the individual user (not a good practice). All the Share and NTFS permissions are accumulated, but stored separately. Then the effective permissions are the most restrictive (least permissive) set of permissions. In this case, it is nearly identical. The effective permissions are Read and Change/Modify.

From having taught NTFS permissions for 17 years, I know that a large majority of Windows administrators think that the correct answer is the Read permission only — and that is wrong. They've been taught to take the least permissive permission (i.e., Read) at the end of the comparison instead of the least permissive set of permissions. But now you know, if you didn't already. This apparent conclusion is not as readily apparent as it seems, as I frequently see overly permissive permissions set on mission-critical resources. Make sure all the administrators on your staff know the correct answer and how it was derived.

Also, true effective permissions are determined by more than just NTFS and Share permissions. As discussed much in this chapter, the less apparent, action-based groups may be in place and adding their own permissions to the effective permission puzzle. Other Windows mechanisms, such as EFS, may come into play. For instance, if one of your end users has enabled EFS encryption on a file and you are not the Data Recovery Agent (covered in Chapter 13), then even if you have Full Control to the file, you won't be able to read it. Conversely, in order for an EFS user to open an EFS-protected file for viewing, that user must have Read and Write permissions on the file (because EFS decrypts the file upon viewing and rewrites it on-the-fly). This point is important to understand because effective permissions can be harder to figure than meets the eye.

Effective Permissions Tab

In Windows XP and later, Microsoft has included a new Effective Permissions tab (see Figure 3-14). Supposedly, anyone can access the new feature (right-click the object, select the Properties option, select the Security tab, click the Advanced button, and then select the Effective Permissions tab) and easily determine a particular user or group's effective permissions. In the past, all the individual and user account interactions would have to be figured out by the administrator. Now, with a few clicks of the mouse, the administrator can determine the effective permissions of a user or group.

image from book
Figure 3-14

Unfortunately, the Effective Permissions tab only works on NTFS permissions. It does consider the effects of Share permissions, action-based groups the user is not currently in, or other factors such as EFS. In this list of missing effects, not considering the impact of Share permissions is most inexcusable. The Effective Permissions tab is a needed but not overly accurate tool. Use it to get a general sense of what the effective permissions might be, but don't rely on it alone when determining critical permission settings. For that, rely on yourself and expertise.

Simple File Sharing

Windows XP has a setting called Simple File Sharing that, if enabled, effectively removes most NTFS permissions and sets them to something close to Share permissions. Even then, all connecting users either come in with full administrator rights or as Guest. Simple File Sharing is beyond the scope of this book other than to say you should never have your PC using it. Simple File Sharing causes many other issues, disables a ton of useful features, and effectively guts the security of Windows. It is meant for home users who need simply file sharing, but nearly everyone who knows about it wants Microsoft to remove it.



Professional Windows Desktop and Server Hardening
Professional Windows Desktop and Server Hardening (Programmer to Programmer)
ISBN: 0764599909
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net