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.
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 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:
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.
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.
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, downlevel 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.
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.
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.
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.
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:
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:firstname.lastname@example.org,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 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.
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.
The final and arguably most powerful native tool is PowerShell, Microsoft's new commandline 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")
Set‐ACL –Path 'c:\Users\Administrator\Tools' –ACLObject $AclToModify
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.
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 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.
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"
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:
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.
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 wellformed 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.
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.
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.
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.
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).
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.
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")
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.
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.
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.
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:
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.
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.
IT environments with large numbers of file shares, large amounts of file storage, or highsecurity 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.