The Essentials Series

Fundamentals of
Effective File Server
Security
sponsored by

by Greg Shields
 

Article 1: Enforcing File and Folder Security ............................................................................................... 1 

Permissions in Two Flavors: Share and NTFS ........................................................................................ 2 

Share Permissions .......................................................................................................................................... 2 

NTFS Permissions ........................................................................................................................................... 2 

How to Set Permissions .................................................................................................................................... 3 

Automating Permissioning .............................................................................................................................. 5 

Net Share ............................................................................................................................................................ 5 

Icacls.exe ............................................................................................................................................................. 5 

PowerShell ......................................................................................................................................................... 6 

Going Beyond Native Toolsets ....................................................................................................................... 6 

Article 2: Enumerating File and Folder Security ........................................................................................ 7 

Viewing Permissions .......................................................................................................................................... 7 

Native File and Folder Enumeration Remains Painful ..................................................................... 10 

Article 3: Auditing File and Folder Access .................................................................................................. 11 

Auditing Considerations ................................................................................................................................ 11 

Configuring Auditing ....................................................................................................................................... 12 

Command‐Line Auditing ........................................................................................................................... 13 

Mining the Security Event Log .................................................................................................................... 14 

Centralized Auditing and Reporting via Third‐Party Tools ........................................................... 15 

  i
 

Copyright Statement
© 2009 Realtime Publishers. All rights reserved. This site contains materials that have
been created, developed, or commissioned by, and published with the permission of,
Realtime Publishers (the “Materials”) and this site and any such Materials are protected
by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtime Publishers or its web site
sponsors. In no event shall Realtime Publishers or its web site sponsors be held liable for
technical or editorial errors or omissions contained in the Materials, including without
limitation, for any direct, indirect, incidental, special, exemplary or consequential
damages whatsoever resulting from the use of any information contained in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, non-
commercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtime Publishers and the Realtime Publishers logo are registered in the US Patent &
Trademark Office. All other product or service names are the property of their respective
owners.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtime Publishers, please contact us via e-mail at
info@realtimepublishers.com.

  ii
 

[Editor's Note: This eBook was downloaded from Realtime Nexus—The Digital Library for 
IT Professionals. All leading technology eBooks and guides from Realtime Publishers can be 
found at http://nexus.realtimepublishers.com.] 

Article 1: Enforcing File and Folder Security 
Files and folders…folders and files…data everywhere! It seems like even the smallest of 
business networks somehow aggregate mounds of those individual buggers each and every 
day. Collecting up on our file servers, it is the protection of that data that is arguably our 
primary job as IT administrators. 

Yet as a fundamental part of our daily activities, managing file server security is one task 
we must accomplish using some of the least‐capable tools in our administrative quiver. 
With little more than an Explorer shell and a few native command‐line tools, we’re charged 
with maintaining the security and availability of our business’ most critical assets: Its data. 

Effectively managing file server security is a three‐fold responsibility: We must first ensure 
that rights and permissions are set correctly to give the correct people access and keep the 
wrong people out. Lacking specialized tools to assist, completing this task requires large 
amounts of mouse‐work as we click through to set each file and folder’s properties. 

But setting security isn’t efficient without a good visualization of the structures we have to 
work within. The second responsibility in effective file server security is in enumerating 
files, folders, and their assigned permissions. Lacking tools here, we’re further forced into 
highly‐manual activities that don’t scale with the growth of our data. 

The third facet of this responsibility arrives as an unfortunate side effect of how dynamic 
an IT environment really is. Once set, we must constantly and comprehensively audit that 
security to make sure it hasn’t been changed. Ultimately, keeping the wrong people out is as 
much work as locking them out in the first place. 

It is the goal of this Essentials Series to assist you with these three responsibilities. You 
know as well as the next IT professional that enforcing, enumerating, and auditing file 
server security can be a painful process without the right tools. This series will show you 
tools that are available right within the Windows operating system (OS). Along the way, 
you may discover that alternative solutions might come in handy for easing the strain of 
this daily activity. 

   

  1
 

Permissions in Two Flavors: Share and NTFS

Effectively enforcing file server security means monitoring permissions at both the level of 
NTFS as well as with each individual shared folder. For data that is accessed via a shared 
path, both sets of permissions determine a user’s rights to work with files and folders in the 
share. 

There is often some confusion as to what privileges are conveyed through each of these two 
permission structures. Part of this confusion is because both NTFS and shared folders 
leverage similar permission sets such as Full Control and Read. By design, NTFS 
permissions control the access to a particular file or folder. That access holds true no 
matter how the user navigates to the file or folder’s location. Share permissions, however, 
apply only to objects that are accessed through a defined shared folder path. 

Share Permissions 
Share permissions are often considered the gatekeepers of a shared resource. Correctly 
implemented, they limit the boundary of access that a user can have on any item within the 
share. This extra security boundary enables a blanketed control over all file and folder 
access within the share, which is then tailored down further using the NTFS permissions 
applied to each individual file and folder. There are three levels of control exposed at the 
share level: 

• The most basic access is Read. Read allows a user to be controlled by the Read & 
Execute, List Folder Contents, and Read NTFS permission groups. 
• The next level of control at the share level is Change, which exposes all the 
additional NTFS permission groups except Full Control. 
• The final level, Full Control, allows access to the remaining NTFS permission group 
of the same name. 
It is important to remember share permissions do not grant any direct access to files or 
folders. They only enable a configured user or group to traverse through the share. The 
other half of permissioning is handled using NTFS permissions. 

NTFS Permissions 
Once through a shared folder, NTFS permissions further define which users can access 
which resources. These permissions control access to the file or folder itself as well as to its 
specific attributes. At their most basic level, NTFS permissions define whether a user or 
group can read, write, and ultimately delete a particular file or folder. 

But these three rights are only the most basic of those that can be assigned. An additional 
set of “special permissions”—over a dozen in all and different based on each object’s 
type—can be assigned as necessary. This granularity enables you to create complex 
permissioning structures where users can traverse folder structures but not read their 
contents or create files but not delete them. Exceptional care is necessary when working 
with these special permissions, as their incorrect assignment can create havoc for user 
access. 

  2
 

Complicating this situation even further, the permission structure for NTFS is cumulative. If 
a user is a member of several groups that have all been granted different permissions to a 
file or folder, the user will be granted the least‐restrictive effective permission. As such, 
keeping a user out of a folder means not assigning its privileges to the user’s user account 
as well as any of the groups to which the user is a member. 

This cumulative behavior is also experienced with folder inheritance. With inheritance, a 
file or folder can receive its permissions from the folder above it in the tree. Thus, down‐
level files and folders can have their permissions automatically assigned from another 
folder that is one or many folders above in the file structure. Finding where those 
permissions are assigned can be a challenging activity using native tools alone. In complex 
environments with large folder structures, third‐party solutions are often necessary to 
visualize and untangle what eventually becomes a spaghetti of inherited permissions. 

Finally, the NTFS permission structure includes a powerful (and often painful) Deny 
permission. Whereas access that is enabled through the standard Allow permissions 
follows the rules previously mentioned, any Deny permission automatically and 
immediately overrides everything. This is useful for creating a blanket restriction for 
highly‐secure folders but must be used carefully. If you’ve ever accidentally set the Deny 
permission for the Everyone group on a file or folder, you know how challenging this 
permission can be to wield effectively. 

How to Set Permissions 
NTFS permissions are defined within Windows Explorer by navigating to the target file or 
folder and viewing the Security tab of the object’s properties (see Figure 1). The Security 
tab shows a list of accounts and groups that have access to the file. When a user or group is 
selected, the permission groups enabled for them are highlighted. 

  3
 

 
Figure 1: Viewing NTFS permissions. 

Clicking Edit will allow you to modify the permission groups assigned or associate new 
groups. Clicking Advanced followed by the resulting Edit button enables access to edit 
Advanced Security Settings (see Figure 2). 

 
Figure 2: Editing advanced security settings. 

  4
 

This wizard allows you to associate users or groups with permissions on the targeted 
object. It also allows you to control how inherited permissions affect the object and any 
sub‐objects. Editing permissions from there allows access to the special permissions. 

Yet these are all tools you already use today. You already use Windows Explorer to 
accomplish at least the basics of permissioning through the GUI. What you need are 
automation solutions that make this process easier. Let’s start by looking at some common 
command‐line solutions that are available right out of the box. 

Automating Permissioning 
Windows Server 2008 ships with several command‐line tools to help manage NTFS and 
share permissions. These tools help alleviate some of the scalability and consistency 
limitations experienced with Windows Explorer. Three in particular are useful right out of 
the box: 

• Share permissions can be managed through the net share command. 
• NTFS permissions can be managed with icacls.exe, also known as Improved Change 
ACLs. 
• Microsoft’s investment in Windows PowerShell further extends scripting support 
through cmdlets such as Set‐ACL for working with NTFS permissions. 

Net Share 
Creating shares from the command line via “net share” is a fairly straightforward process. 
To create the share, you must pass the share name and the path to the share: 

Net share MyFolderShare=c:\Users\Administrator\Tools 

Net share can also be used to grant permissions to users and groups when establishing the 
share using the /grant switch: 

Net share MyFolderShare=c:\Users\Administrator\Tools 
/Grant:MyDomainSysAdmins@mydomain.local,CHANGE /Grant:steve@mydomain.local,FULL  

As the previous example shows, the /Grant switch can be used more than once to add 
multiple users or groups. Be aware that “net share” will not allow you to modify 
permissions on an existing share. 

Icacls.exe 
Icacls.exe is a command‐line tool for managing both permissions and file integrity levels. It 
is natively available in Windows Server 2008, Windows Vista, and Windows 7, and arrives 
as an evolution of the cacls.exe command first available in Windows NT 4.0. Icacls.exe 
offers rich permissioning support for files and folders, enabling an administrator to 
automate the application of both simple as well as special permissions. 

  5
 

Its challenge is in its syntax. Although it is powerful in what it can do, applying permissions 
using icacls.exe involves a complex aggregation of switches and inheritance operators. For 
example, let’s assume you need to remove the existing inherited permissions from the 
C:\Shared folder. At the same time, you want to directly apply the Read permission to the 
Domain Users group and the Full Control permission for File Administrators. To 
accomplish this, you would use the following icacls.exe syntax: 

Icacls C:\Shared /inheritance:r /grant:r “Domain Users”:(OI)(CI)R /grant:r “File 
Administrators”:(OI)(CI)F 

Once through its learning curve, icacls.exe’s true power arrives by stringing together long 
series’ of these commands to automate permissioning at multiple levels. Once scripted, you 
can re‐run the script over and over again to reapply permissions to your file structure. 

Note 
A thorough explanation of scripting with icacls.exe can be found at 
http://technet.microsoft.com/en‐
us/magazine/2009.07.geekofalltrades.aspx. 

PowerShell 
The final and arguably most powerful native tool is PowerShell, Microsoft’s new command‐
line automation framework. PowerShell provides a cmdlet called Set‐ACL that can be used 
alone or incorporated within a larger script for managing NTFS permissions. Set‐ACL is 
best used when modifying an existing permission set, whether that permission set is from 
the object you want to modify or another object. The Set‐ACL solution is also the most 
verbose of the command‐line options: 

$AclToModify = Get‐ACL –Path ‘c:\Users\Administrator\Tools’ 
$NewPermission = New‐Object 
System.Security.AccessControl.FileSystemAccessRule(“MyLocalDomain\Steve”,”Modify”,
”Allow”) 
$ AclToModify.AddAccessRule($NewPermission) 
Set‐ACL –Path ‘c:\Users\Administrator\Tools’ –ACLObject $AclToModify 

Going Beyond Native Toolsets 
As you can see, the native toolsets available in Microsoft Windows create a framework for 
the enforcement of permissions. Yet each of these tools arrives with their own challenges, 
requiring either heavy mouse‐work or a deep knowledge of scripting to be truly useful. 

As the primary job of every IT administrator, managing data on file servers requires a lot of 
time and effort. As such, other non‐native solutions may be necessary as the size of your 
data scales. These tools enable the graphical visualization of permissions structures 
through built‐in discovery, reporting, and analysis engines. With the right views in place, 
administrators can leverage built‐in automation that defines and maintains widespread 
permissions based on best practices. If the management of your file servers is a strain, 
consider looking to external solutions for enforcing your file and folder security. 

  6
 

Article 2: Enumerating File and Folder 
Security 
Assigning permissions to files and folders is an important task. But you won’t get far 
without first having a useful enumeration of your folder structures themselves. Windows 
Server 2008 provides numerous tools to visualize the access permissions set on your files 
and folders. Primary tools for this are the Windows Explorer GUI as well as command‐line 
tools such as showacls.exe, icacls.exe, or PowerShell’s Get‐ACL. Unfortunately, these tools 
are limited in flexibility for environment sizes that go much beyond the very small. 
Effectively using them requires you to aggregate results from other solutions or turn to 
third‐party solutions for a comprehensive analysis of file and folder security. With this in 
mind, let’s take a look through the tools that are natively available, with an eye towards the 
features and capabilities that one might want in an external solution. 

Viewing Permissions 
Viewing NTFS and Share permissions from Windows Explorer requires the individual 
examination of each file or folder. Share permissions can be determined only by opening 
the properties dialog box from of the root of the share (see Figure 1). 

 
Figure 1: Viewing NTFS and Share permissions from Windows Explorer. 

A similar process can be used to examine the NTFS permissions for a specific object via 
Windows Explorer from the properties dialog box. Administrators can dig deeper into the 
application of these permissions by going to the Advanced view, as shown in Figure 2. 

  7
 

 
Figure 2: Digging deeper into permissions application. 

These wizard screens are excellent for the single‐instance application of permissions. Their 
use works well when you need to apply only a few permissions to a few folders. Yet they 
don’t scale. The process to set each new permission can require a minimum of seven mouse 
clicks, with special permissions requiring an even greater number. More permissions 
equals more mouse clicks, which reduces your effectiveness and increases the effort 
required to do your job. 

To combat this, Microsoft provides command‐line tools for working with NTFS and Share 
permissions that include options for reporting. These command‐line reporting options 
enable the creation of text output that can be redirected to a file for later viewing. 

Using the net share command with no options will provide a listing of all shared folders on 
a system, including the share name, path, and any assigned remarks. Specifying a share 
name with net share will display share details, which adds information about the maximum 
limit of users, caching settings, and assigned permissions. As an example, to report this 
information about the MyFolderShare to a file called filepermissions.txt, use the following 
syntax:  

subinacl.exe /share MyFolderShare /display 
/outputlog=”c:\securitylog\filepermissions.txt” 

As subinacl.exe also can manage file system permission, shown below is a similar syntax 
which reports on NTFS permissions for files: 

subinacl.exe /subdirectories c:\Users\Administrator\Tools /display 
/outputlog=”c:\securitylog\filepermissions.txt” 

   

  8
 

This command structure enables icacls.exe to report on a file’s NTFS permissions. However, 
more useful is the ability to save that structure to a file for later reapplication. Consider the 
situation where you’ve created a rich set of permissions for a large file structure. Using the 
/save switch, as shown below, icacls.exe will create a text file that contains the folder and 
permissions structure in Microsoft’s Security Descriptor Definition Language (SDDL) 
format: 

icacls c:\Users\Administrator\Tools\* /save ACLFile /T 

Replacing the /save switch with /restore in the previous code snippet will restore the text 
file’s saved permissions to your file structure. The net result is the ability to quickly restore 
an entire structure’s permissions as necessary to fix a mistaken permission or simply 
ensure that your permissions are set to your established standards. 

Showacls.exe is another command‐line tool, found in the Windows 2003 Resource Kit, 
which can be used for retrieving and viewing NTFS permissions. The differentiator with 
showacls.exe is in its ability to report on the specific permissions assigned to a user or 
group, similar to the Effective Permissions option found within Windows Explorer: 

showacls /s c:\Users\Administrator\Tools\* > ACLFile.txt 
 
showacls /s /u:MyDomain\administrator c:\Users\Administrator\Tools\* > ACLFile.txt 

When possible, showacls.exe will use the simple permissions Read, Change, or Full Control. 
If the permission structure is more complex, it provides an “access mask,” which attempts 
to sum up the access rights. More information about configuring access masks can be found 
in the tool’s help file. 

Windows PowerShell’s Get‐ACL cmdlet accomplishes many of the same textual 
visualizations seen in the previously mentioned tools but with the added power of 
PowerShell’s rich scripting architecture. Get‐ACL returns a 
System.Security.AccessControl.DirectorySecurity object for each file and directory it is run 
against, which can be later repurposed for other uses within a larger PowerShell script 
infrastructure. The Access property of this object contains the file or folder permissions: 

Get‐ACL c:\Users\Administrator\Tools\* 

As a full scripting language, PowerShell provides several display options over and above 
the alternatives, including exporting to XML, comma separated value (CSV) files, or HTML. 

   

  9
 

Native File and Folder Enumeration Remains Painful 
Each of these examples provides you with yet another view of your files and folders. But as 
you can obviously see, their results are almost entirely text‐based. Although native tools 
indeed enable you to enumerate and visualize your permissions structures, you can argue 
that their text‐based nature isn’t much better than Windows Explorer alone. 

Environments that need greater visibility into file server security must look to external 
solutions. These solutions enable the discovery of file and folder structures as well as their 
assigned permissions. Their aggregation of permissions information across multiple file 
servers into a central and consistent format enables the reporting on permissions across an 
entire infrastructure at once. Storing permissions centrally also enables administrators to 
see how and where permissions structures have evolved over time, whether by server, 
user, group, or combination therein. Leveraging this file server metadata with a well‐
formed API for accomplishing needed tasks ensures that the job is done right. Lacking a 
substantial scripting investment, this capability is simply not possible using native toolsets 
and homegrown solutions. 

The needs of security are but one facet of file server management. A third‐party solution 
becomes more valuable when the reporting is needed to meet regulatory compliance. 
Regulations such as the Sarbanes‐Oxley Act (SOX), Health Insurance Portability and 
Accountability Act (HIPAA), Gramm‐Leach‐Bliley Act (GLBA), Federal Desktop Core 
Configuration (FDCC), and Payment Card Industry (PCI) require IT departments to 
positively show that proper access controls are in place on critical data. As you’ll find out in 
the third article of this series, third‐party solutions provide needed templates or reports 
that are designed to meet the auditing requirements imposed by those regulations. 

   

  10
 

Article 3: Auditing File and Folder Access 
The third rail of effective file server security is all about assurance. Assuring that the right 
users have access to data preserves availability. Assuring that everyone else stays out 
preserves security. Assuring that permissions on files and folders are always correctly set 
preserves compliance. 

Auditing access to Windows Server 2008 file servers is the primary mechanism through 
which this assurance is achieved. Auditing enables administrators to verify that security 
controls put in place are working properly, all the while logging access and modifications to 
controlled files. Auditing can be enabled via the Windows Explorer GUI, command prompt 
tools, and Group Policy. Like reporting on access controls, the auditing process is per server 
and the logging of controlled events is done to the local event log. 

A correctly‐developed auditing system provides a number of benefits to the organization. It 
assists in securing the enterprise by determining inappropriate access to files or folders. It 
provides for the maintenance of a modification history across data, applications, and 
operating system (OS) configurations. And it creates the necessary documentation for 
meeting regulatory standards. 

Auditing Considerations 
The first step in deciding to audit file server access is determining what type of events to 
audit. For many IT organizations, the selection of auditing categories is often defined by 
internal security organizations in cooperation with applicable rules of regulatory 
compliance. Although each compliance regulation is uniquely different in its guidance, all 
generally require that user and administrator actions are tracked into an auditable 
database. For some, that database can be your Windows servers’ Event Logs. 

The first step in this process is to designate a purpose to each audit rule. Auditing rules 
have several typical purposes. They can assist in securing the enterprise by determining 
inappropriate access to files or folders. Auditing also allows the maintenance of a 
modification history outside of any application‐specific modification tracking. 

This linkage between auditing rules and business goals is critically important, as there can 
be unintended effects when purposes are not designated to an audit rule. The first of these 
relates to collected events that do not further the organization’s goals. Collecting these 
events consumes resources, leads to log maintenance issues, and makes event filtering 
dramatically more difficult. Therefore, discretion is required when developing an audit 
policy so that only the appropriate types of access tracking are monitored. 

The second unintended effect stems from possible legal exposure. Your organization’s legal 
counsel should review your auditing strategy. Their legally‐focused review helps to ensure 
that the auditing purpose covers potential exposure and that the policy is defensible. 

  11
 

Note 
In short, your audit policy should collect the minimum amount of auditing 
information that is necessary to accomplish your business’ goals. 

Windows Server 2008 provides for auditing on folders as well as individual files. File and 
folder auditing can monitor access to both simple as well as special permissions as 
discussed in the first article of this series. For each object, assigned auditing rules can 
monitor for success and/or failure in exercising the users’ permissions. 

As with permissions, it is important to remember that auditing configurations are also 
inheritable. Thus, if extensive auditing is set up and allowed to pass down the settings to a 
large number of files, a great number of audit entries could be generated. 

Configuring Auditing 
Auditing must first be globally enabled before setting auditing rules on individual files and 
folders. Doing this across multiple machines in an environment is most commonly 
accomplished via Group Policy. Navigate to Computer Configuration | Policies | Windows 
Settings | Security Settings | Local Policies | Audit Policy, as shown in Figure 1. Here, edit 
the Audit Object Access policy to allow the tracking of Success and/or Failure events. 

 
Figure 1: Enabling auditing via Group Policy. 

Once the global audit policy is enabled, configuring auditing on individual files and folders 
can be performed using Group Policy, Windows Explorer, or command‐line tools. As with 
the global policy, leveraging Group Policy for individual file and folder configuration 
ensures a comprehensive approach. Right‐click Computer Configuration | Policies | 
Windows Settings | Security Settings | File System, and select Add File to add a file or folder 
to the policy (see Figure 2). 

  12
 

 
Figure 2: Configuring auditing of NTFS access. 

After entering the file path, click Edit Security to bring forward the same Security wizard 
you’re used to seeing when managing permissions directly in the file system. Click 
Advanced, and select the Auditing tab of the Advanced Security Settings window to 
configure audit settings using the GUI. 

Command‐Line Auditing 
Audit configuration from the command line is possible using the same Windows 
PowerShell Get‐ACL cmdlet discussed earlier in this series. Get‐ACL is used to retrieve the 
existing audit policy using PowerShell by supplying the ‐audit command‐line switch: 

Get‐ACL c:\Users\Administrator\Tools\ ‐audit | Select‐Object –ExpandProperty Audit 

To use PowerShell to create an audit rule, the Set‐ACL cmdlet is required: 

$AclToModify = Get‐ACL –Path ‘c:\Users\Administrator\Tools’ –Audit 
 
$NewAudit = New‐Object 
System.Security.AccessControl.FileSystemAuditRule(“MyLocalDomain\gshields”,”ReadDa
ta”,”Success”) 
 
$ AclToModify.AddAuditRule($NewAudit) 
 
Set‐ACL –Path ‘c:\Users\Administrator\Tools’ –ACLObject $AclToModify 

PowerShell provides a rich mechanism for scripting the creation of audit rules; however, 
effectively using it requires familiarity with the .NET Framework classes that manage 
access to the file system rules. 

  13
 

Mining the Security Event Log 
After auditing has been configured, success or failure events will be stored in the Security 
event log. Event log entries are stored per server, so be conscious of each server’s 
maximum log size and how the event log is configured to react when the log size is reached. 
Depending on the size of the log file and the number of events, there is a danger of losing 
audit entries due to log size maximums being reached. 

Note 
Windows Server 2008 includes a feature called Event Log Forwarding, which 
allows file servers to centralize event log data onto a single server. This 
server can be configured to pull the event logs from the other servers or 
those servers can pass selected events to the central server. More 
information on Event Log Forwarding can be found at 
http://technet.microsoft.com/en‐us/library/cc748890.aspx. 

Gathering log information is only the first step. Effectively mining event log data for 
meaningful events requires extra effort. With the release of Windows Server 2008, Event 
Viewer provides several filtering options that limit the data being presented In Figure 3, 
you can see how a few specific settings can greatly enhance the quality of information 
viewed from the Security log: 

• Logged. For a general‐purpose file system auditing log, this can be set at Any time. 
• Event Level. All security audit entries will be Informational, so this filter is of 
relatively little use. 
• Event Logs. All the entries dealing with auditing are contained in the Security event 
log. 
• Event Sources. Microsoft Windows security auditing should be selected here. 
• Task Category. Here, select the File System option. 
• Keywords. The Keywords option is of little use, as all security audit entries contain 
the keywords Audit Success or Audit Failure. 

  14
 

 
Figure 3: Event Viewer’s filtering options. 

Once filtered, reporting from the Event Viewer is quite limited. A selection of events can be 
saved to XML, text, or comma‐separated value files, but there is no facility for rich 
reporting. Additionally, reporting efforts can be hampered by the limitations of event log 
storage. In the most gracious scenario where all old event logs cannot be maintained in the 
current view, the events are archived and those archives would need to be searched 
individually in order to obtain information from them. 

Centralized Auditing and Reporting via Third‐Party Tools 
Auditing is all about assurance, but assuring effective auditing with native tools alone is a 
challenge. As you can see, configuring auditing via Windows Explorer or Windows 
PowerShell requires a number of steps and careful coordination to be effective. Each and 
every file share must be managed as an individual item, which increases the chance for 
errors or omissions in auditing. Although Group Policy assists this process, the natural 
dynamics of an IT environment mean that Group Policies must be regularly verified to 
ensure their policies remain correct over time. 

   

  15
 

IT environments with large numbers of file shares, large amounts of file storage, or high‐
security requirements may find that native solutions are insufficient for their needs. To 
meet regulatory compliance and provide timely security information, you may find the 
need to turn to third‐party toolsets. Their extended capabilities enable the central 
configuration of an audit plan, central storage of audit data, customizable reporting, 
alerting in the case of unauthorized access, and enhanced search features that are often 
necessary as environments scale. 

Download Additional eBooks from Realtime Nexus! 
Realtime Nexus—The Digital Library provides world‐class expert resources that IT 
professionals depend on to learn about the newest technologies. If you found this eBook to 
be informative, we encourage you to download more of our industry‐leading technology 
eBooks and video guides at Realtime Nexus. Please visit 
http://nexus.realtimepublishers.com. 

  16