Managing file shares after configuration
Managing claims-based access controls
Auditing file and folder access
Few aspects of the operating system are more important than file security, access controls, and auditing. These topics are so interconnected, in fact, that talking about one without talking about the others is difficult. File security and access controls protect important data on a server by restricting access. Auditing protects data by tracking who accessed files and folders and identifying the actions they performed.
You can think of access permissions as the base-level permissions—the permissions that are applied no matter what. For NTFS and Resilient File System (ReFS) volumes, you use access permissions and ownership to constrain actions further within the share and to share permissions. For file allocation table (FAT) volumes, share permissions provide the only access controls because FAT volumes have no file and folder permission capabilities.
Access permissions are much more complex than share permissions, and to understand fully how they can be used and applied, you must understand ownership and inheritance and the permissions that are available. Because Windows Server 2012 R2 adds new layers of security, access permissions now include basic permissions, claims-based permissions, and special permissions.
Before working with access permissions, you should understand the concept of ownership as it applies to files and folders. In Windows Server, the file or folder owner isn’t necessarily the file’s or folder’s creator. Instead, the file or folder owner is the person who has direct control over the file or folder. File or folder owners can grant access permissions and give other users permission to take ownership of a file or folder.
The way ownership is assigned initially depends on where the file or folder is being created. By default, the user who created the file or folder is listed as the current owner. Ownership can be taken or transferred in several ways. Any administrator can take ownership. Any user or group with the Take Ownership permission can take ownership. Any user who has the right to Restore Files And Directories, such as a member of the Backup Operators group, can take ownership, and any current owner can transfer ownership to another user.
You can take ownership by using File Explorer or Server Manager. In File Explorer, press and hold or right-click the file or folder and then select Properties. On the Security tab of the Properties dialog box, open the Advanced Security Settings dialog box by tapping or clicking Advanced.
If a folder has been shared, you can change its ownership by using Server Manager. In Server Manager, the Shares subnode of the File And Storage Services node shows existing shares for file servers that have been added for management. Press and hold or right-click the share you want to work with and then tap or click Properties. In the Properties dialog box, tap or click the Permissions in the left pane. Tap or click Customize Permissions to open the Advanced Security Settings dialog box.
As shown in Figure 19-1, the current owner is listed on the Permissions tab. Tap or click Change. Use the options in the Select User, Computer, Service Account, Or Group dialog box to select the new owner. If you’re taking ownership of a folder, you can take ownership of all subfolders and files within the folder by selecting Replace Owner On Subcontainers And Objects. Tap or click OK twice when you are finished.
By default, when you add a folder or file to an existing folder, the folder or file inherits the permissions of the existing folder. For example, if the Domain Users group has access to a folder and you add a file to this folder, members of the Domain Users group will be able to access the file. Inherited permissions are automatically assigned when files and folders are created.
When you assign new permissions to a folder, the permissions propagate down and are inherited by all subfolders and files in the folder and supplement or replace existing permissions. If you add permissions on a folder to allow a new group to access a folder, these permissions are applied to all subfolders and files in the folder, meaning the additional group is granted access. However, if you were to change the permissions on the folder so that, for instance, only members of the Engineering group could access the folder, these permissions would be applied to all subfolders and files in the folder—meaning only members of the Engineering group would have access to the folder, its subfolders, and its files.
Inheritance is automatic. If you do not want the permissions of subfolders and files within folders to supplement or replace existing permissions, you must override inheritance, starting with the top-level folder from which the permissions are inherited. A top-level folder is referred to as a parent folder. Files and folders below the parent folder are referred to as child files and folders. This is identical to the parent/child structure of objects in Active Directory.
If a permission you want to change is shaded, the file or folder is inheriting the permission from a parent folder. To change the permission, you must do one of the following:
Access the parent folder and make the desired changes. These changes will then be inherited by child folders and files.
Select the opposite permission to override the inherited permission if possible. In most cases, Deny overrides Allow, so if you explicitly deny permission to a user or group for a child folder or file, this permission should be denied to that user or group of users.
Stop inheriting permissions from the parent folder and then copy or remove existing permissions as appropriate.
To stop inheriting permissions from a parent folder, press and hold or right-click the file or folder in File Explorer and then select Properties. On the Security tab of the Properties dialog box, tap or click Advanced to open the Advanced Security Settings dialog box. On the Permissions tab, you see a Disable Inheritance button if inheritance currently is enabled. When you tap or click Disable Inheritance, you can either convert the inherited permissions to explicit permissions or remove all inherited permissions and apply only the permissions that you explicitly set on the folder or file. (See Figure 19-2.)
Important
If you remove the inherited permissions and no other permissions are assigned, everyone but the owner of the resource is denied access. This effectively locks out everyone except the owner of a folder or file. However, administrators still have the right to take ownership of the resource regardless of the permissions. Thus, if an administrator is locked out of a file or a folder and truly needs access, she can take ownership and then have unrestricted access.
If a folder has been shared, you can change its inheritance settings by using Server Manager. In Server Manager, the Shares subnode of the File And Storage Services node shows existing shares for file servers that have been added for management. Press and hold or right-click the share you want to work with and then tap or click Properties. In the Properties dialog box, tap or click the Permissions in the left pane. Tap or click Customize Permissions to open the Advanced Security Settings dialog box. After you tap or click Disable Inheritance, you can elect to convert the inherited permissions to explicit permissions or to remove all inherited permissions and apply only the permissions that you explicitly set on the folder or file. (See Figure 19-2.)
Another way to manage permissions is to reset the permissions of subfolders and files within a folder, replacing their permissions with the current permissions assigned to the folder you are working with. In this way, subfolders and files get all inheritable permissions from the parent folder and all other explicitly defined permissions on the individual subfolders and files are removed.
To reset permissions for subfolders and files of a folder, open the Advanced Settings dialog box as discussed previously. Next, select Enable Inheritance. Optionally, before you tap or click OK, you can remove all explicitly defined permissions and enable propagation of inheritable permissions to any file or subfolder of the folder. To do this, select the Replace All Child Object Permission Entries check box and then tap or click Yes when prompted to confirm. (See Figure 19-3.)
On NTFS and ReFS volumes, you can assign access permissions to files and folders. These permissions grant or deny access to users and groups. Keep in mind that if a permission has been explicitly denied, the deny setting will override any permission grant.
In File Explorer, you can view basic permissions by pressing and holding or right-clicking the file or folder you want to work with, selecting Properties on the shortcut menu, and then, in the Properties dialog box, selecting the Security tab, as shown in Figure 19-4. The Group Or User Names list shows groups and users with assigned permissions. If you select a group or user in this list, the applicable permissions are shown in the Permissions For list. If permissions are unavailable, it means the permissions are inherited from a parent folder as discussed previously.
The basic permissions you can assign to folders and files are shown in Table 19-1 and Table 19-1. These permissions are made up of multiple special permissions.
Table 19-1. Basic folder permissions
Permission | Description |
|---|---|
This permission permits reading, writing to, changing, and deleting files and subfolders. If a user has Full Control over a folder, she can delete files in the folder regardless of the permission on the files. | |
Modify | This permission permits reading and writing to files and subfolders, and it allows deletion of the folder. |
List Folder Contents | This permission permits viewing and listing files and subfolders and executing files; it is inherited by folders only. |
Read & Execute | This permission permits viewing and listing files and subfolders and executing files; it is inherited by files and folders. |
Write | This permission permits adding files and subfolders. |
Read | This permission permits viewing and listing files and subfolders. |
Table 19-2. Basic file permissions
Permission | Description |
|---|---|
Full Control | This permission permits reading, writing to, changing, and deleting the file. |
Modify | This permission permits reading and writing to the file, and it allows deletion of the file. |
Read & Execute | This permission permits viewing and accessing the file’s contents and executing the file. |
Write | This permission permits writing to a file. Giving a user permission to write to a file but not to delete it doesn’t prevent the user from deleting the file’s contents. |
Read | This permission permits viewing or accessing the file’s contents. Read is the only permission needed to run scripts. Read access is required to access a shortcut and its target. |
You can set basic permissions for files and folders by following these steps:
In File Explorer, press and hold or right-click the file or folder you want to work with and select Properties. In the Properties dialog box, select the Security tab, as shown in Figure 19-4.
Tap or click Edit to display an editable version of the Security tab. Users or groups that already have access to the file or folder are listed in the Groups Or User Names list box. You can change permissions for these users and groups by selecting the user or group you want to change and then using the Permissions For list box to grant or deny access permissions.
To set access permissions for additional users, computers, or groups, tap or click Add. This opens the Select Users, Computers, Service Accounts, Or Groups dialog box.
The Locations button enables you to access account names from other domains. Tap or click Locations to see a list of the current domain, trusted domains, and other resources that you can access. Because of transitive trusts, you can usually access all the domains in the domain tree or forest.
Type the name of a user or group account in the selected or default domain and then tap or click Check Names. The options available depend on the number of matches found, as follows:
When a single match is found, the dialog box is automatically updated as appropriate and the entry is underlined.
When no matches are found, you’ve either entered an incorrect name part or you’re working with an incorrect location. Modify the name and try again or tap or click Locations to select a new location.
If multiple matches are found, select the name or names you want to use and then tap or click OK.
To add additional users or groups, type a semicolon (;) and then repeat this process.
When you tap or click OK, the users and groups are added to the Group Or User Name list. Configure access permissions for each added user and group by selecting an account name and then allowing or denying access permissions. If a user or group should be granted access permissions, select the check box for the permission in the Allow column. If a user or group should be denied access permissions, select the check box for the permission in the Deny column.
When you’re finished, tap or click OK.
Shared folders also have NTFS permissions. Use Server Manager to set basic NTFS permissions for shared folders by following these steps:
Press and hold or right-click the folder you want to work with and then tap or click Properties. This opens a Properties dialog box.
When you tap or click Permissions in the left pane, the current share permissions and NTFS permissions appear in the main pane.
Tap or click Customize Permissions to open the Advanced Security Settings dialog box with the Permissions tab selected. The available options include the following:
Add. Adds a user or group. Tap or click Add to open the Permission Entry dialog box, shown in Figure 19-5. Tap or click Select A Principal to open the Select User, Computer, Service Account, Or Group dialog box. Type the name of a user or a group account and then tap or click Check Names. Be sure to reference the user account name rather than the user’s full name. Only one name can be entered at a time.
Edit. Edits an existing user or group entry. Select the user or group whose permissions you want to modify and then tap or click Edit. The Permissions Entry dialog box shown in Figure 19-5 opens.
Remove. Removes an existing user or group entry. Select the user or group whose permissions you want to remove and then tap or click Remove.
When you are editing permissions, you allow and deny special permissions separately. Therefore, if you want to both allow and deny special permissions, you need to configure the allowed permissions and then repeat this procedure, starting with step 1, to configure the denied permissions.
When finished, use the Applies To options shown in Table 19-3 to determine how and where these permissions are applied. If you want to prevent subfolders and files from inheriting these permissions, select Only Apply These Permissions To Objects And/Or Containers Within This Container. When you do this, all the related entries in Table 19-3 are No. This means the settings no longer apply to subsequent subfolders or to files in subsequent subfolders.
Table 19-3. Applies To permissions options
Applies to | Applies to Current Folder | Applies to Subfolders in the Current Folder | Applies to File in the Current Folder | Applies to Subsequent Subfolders | Applies to Files in Subsequent Subfolders |
|---|---|---|---|---|---|
This folder only | Yes | No | No | No | No |
This folder, subfolders, and files | Yes | Yes | Yes | Yes | Yes |
This folder and subfolders | Yes | Yes | No | Yes | No |
This folder and files | Yes | No | Yes | No | Yes |
Subfolders and files only | No | Yes | Yes | Yes | Yes |
Subfolders only | No | Yes | No | Yes | No |
Files only | No | No | Yes | No | Yes |
Note
When Only Apply These Permissions To Objects And/Or Containers Within This Container is selected, all the values under Applies To Subsequent Subfolders and Applies To Files In Subsequent Subfolders are No. The settings no longer apply to subsequent subfolders or to files in subsequent subfolders.
You can use either File Explorer or Server Manager to view special permissions. In Server Manager, press and hold or right-click the share you want to work with and then tap or click Properties. In the Properties dialog box, tap or click the Permissions in the left pane. Tap or click Customize Permissions to open the Advanced Security Settings dialog box.
In File Explorer, you can view special permissions by pressing and holding or right-clicking the file or folder you want to work with and selecting Properties on the shortcut menu. In the Properties dialog box, select the Security tab and then tap or click Advanced to open the Advanced Security Settings dialog box.
The available special permissions are as follows:
Traverse Folder/Execute File. Traverse Folder enables you to access a folder directly even if you don’t have explicit access to read the data it contains. Use Execute File to run an executable file.
List Folder/Read Data. List Folder enables you to view file and folder names. Use Read Data to view the contents of a file.
Read Attributes. Enables you to read the basic attributes of a file or folder. These attributes include Read-Only, Hidden, System, and Archive.
Read Extended Attributes. Enables you to view the extended attributes (named data streams) associated with a file. As discussed in Chapter 15 these include Summary fields—such as Title, Subject, and Author—and other types of data.
Create Files/Write Data. Create Files enables you to put new files in a folder. Write Data enables you to overwrite existing data in a file (but not to add new data to an existing file because this is covered by Append Data).
Create Folders/Append Data. Create Folders enables you to create subfolders within folders. Append Data enables you to add data to the end of an existing file (but not to overwrite existing data because this is covered by Write Data).
Write Attributes. Enables you to change the basic attributes of a file or folder. These attributes include Read-Only, Hidden, System, and Archive.
Write Extended Attributes. Enables you to change the extended attributes (named data streams) associated with a file. As discussed in Chapter 15, these include Summary fields—such as Title, Subject, and Author—and other types of data.
Delete Subfolders And Files. Enables you to delete the contents of a folder. If you have this permission, you can delete the subfolders and files in a folder even if you don’t specifically have Delete permission on the subfolder or file.
Delete. Enables you to delete a file or folder. If a folder isn’t empty and you don’t have Delete permission for one of its files or subfolders, you won’t be able to delete it. You can do this only if you have the Delete Subfolders And Files permission.
Read Permissions. Enables you to read all basic and special permissions assigned to a file or folder.
Change Permissions. Enables you to change basic and special permissions assigned to a file or folder.
Take Ownership. Enables you to take ownership of a file or folder. By default, administrators can always take ownership of a file or folder and can grant this permission to others.
Table 19-4 and Table 19-5 show how special permissions are combined to make the basic permissions for files and folders. Because special permissions are combined to make the basic permissions, they are also referred to as atomic permissions.
Table 19-4. Special permissions for folders
Special Permissions | Full Control | Modify | Read & Execute | List Folder Contents | 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 | |||
X | ||||||
Delete | X | X | ||||
Read Permissions | X | X | X | X | X | X |
Change Permissions | X | |||||
Take Ownership | X |
Table 19-5. Special permissions for files
Special Permissions | Full Control | Modify | Read & Execute | Read | Write |
|---|---|---|---|---|---|
Traverse Folder/Execute File | X | X | X | ||
List Folder/Read Data | X | X | X | X | |
Read Attributes | X | X | X | X | |
Read Extended Attributes | 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 |
Change Permissions | X | ||||
Take Ownership | X |
You set special permissions for files and folders by using the Advanced Security Settings dialog box with the Permissions tab selected.
The options available include the following:
Add. Adds a user or group. Tap or click Add to open the Permission Entry dialog box. Tap or click Select A Principal to open the Select User, Computer, Service Account, Or Group dialog box. Type the name of a user or a group account and then tap or click Check Names. Be sure to reference the user account name rather than the user’s full name. Only one name can be entered at a time.
Edit. Edits an existing user or group entry. Select the user or group whose permissions you want to modify and then tap or click Edit. This opens the Permissions Entry dialog box.
Remove. Removes an existing user or group entry. Select the user or group whose permissions you want to remove and then tap or click Remove.
When you are editing permissions, only basic permissions are listed by default. Tap or click Show Advanced Permissions to display the special permissions, as shown in Figure 19-6. Use the Type list to specify whether you are configuring allowed or denied permissions and then select the permissions you want to allow or deny. If any permissions are dimmed (unavailable), they are inherited from a parent folder.
When finished, use the Applies To options shown in Table 19-3 to determine how and where these permissions are applied. If you want to prevent subfolders and files from inheriting these permissions, select Only Apply These Permissions To Objects And/Or Containers Within This Container. When you do this, all the related entries in Table 19-3 are No. This means the settings no longer apply to subsequent subfolders or to files in subsequent subfolders.
Navigating the complex maze of permissions can be daunting even for the best administrators. Sometimes it won’t be clear how a particular permission set will be applied to a particular user or group. Sometimes even a minor change in permissions can have unintended consequences. Either way, you have a problem, and one of your first steps to resolving it should be to determine the effective permissions for the files or folders in question.
The effective permissions tell you exactly which permissions are in effect. For a user, the effective permissions are based on all the permissions the user has been granted or denied, no matter whether the permissions are applied explicitly or obtained from groups of which the user is a member. Similarly, for a group, the effective permissions are based on all the permissions the group has been granted or denied, no matter whether the permissions are applied explicitly or obtained from groups of which the group is a member.
Important
You must have appropriate permissions to view the effective permissions of any user or group. You also should remember that you cannot determine the effective permissions for implicit groups or special identities, such as Authenticated Users or Everyone. Furthermore, the effective permissions do not take into account permissions granted to a user because he is the Creator Owner.
Cumulative permissions can be difficult to navigate because deny entries have precedence over allow entries. For example, if DevonP is a member of the Users, Engineering, DevUsers, and Managers groups, the effective permissions with respect to a particular file or folder are the cumulative set of permissions that DevonP has been explicitly assigned and the permissions assigned to the Users, Engineering, DevUsers, and Managers groups. If DevonP is a member of a group that is specifically denied a permission, he will be denied that permission, even if another group of which he is a member is allowed that permission.
User and device claims also have precedence. If you’ve configured claims-based policies and added a user claim that specifies that a user must or must not be a member of a particular group, that user claim can prevent access. Similarly, if there’s a device claim that specifies that a user’s computer must or must not be a member of a particular group, that device claim can prevent access.
You can use the Effective Access tab in the Advanced Security Settings dialog box to determine the effective permissions with regard to the related file or folder. On the Effective Access tab, use the options provided to determine the effective permissions for users, groups, and devices. Before you tap or click View Effective Access, keep the following in mind:
If you only want to determine access for a particular user or user group, tap or click Select A User, type the name of the user or group, and then tap or click OK.
If you only want to determine access for a particular device or device group, tap or click Select A Device, type the name of the device or device group, and then tap or click OK.
If you want to determine access for a particular user or user group on a particular device or in a device group, specify both a user/user group and a device/device group.
As Figure 19-7 shows, the effective permissions for the specified user or group are displayed using the complete set of special permissions. If a user has Full Control over the selected resource, she has all the permissions. Otherwise, a subset of the permissions is selected, and you have to consider carefully whether the user or group has the appropriate permissions. Use Table 19-4, earlier in the chapter, to help you interpret the permissions. Any selected permissions have been granted to the user or group.
Configuring shares can be a time-consuming process, especially if you are trying to troubleshoot why a particular user doesn’t have access or set up a new server with the same file shares as a server you are decommissioning. Fortunately, there are some techniques to help you manage file shares, and the way they are implemented, better.
Net Share is a handy command-line tool for helping you track file-share and print-share permissions. You can use it to display a list of shares and who has access to them. If you redirect the output of Net Share, you can save the share-configuration and access information to a file, and this file can become a log that helps you track share changes over time.
To view a list of configured shares, type net share at the command prompt or get-smbshare at a Windows PowerShell prompt. The output of Net Share shows you the name of each share on the server, the location of the actual folder being shared, and any descriptions you’ve added. Here is an example of output from running the Net Share command:
Share name Resource Remark ---------------------------------------------------------- ADMIN$ C:Windows Remote Admin C$ C: Default share F$ F: Default share IPC$ Remote IPC CorpData C:CorpData CorpTech F:CorpTech DevData F:DevData EngData C:EngData HRData F:HRData Public C:UsersPublic UserData C:UserData The command completed successfully.
The list of shares shown includes the file shares CorpData, CorpTech, EngData, Public, and others. Administrative shares created and managed by Windows are shown as well, including ADMIN$, IPC$, and any drive shares.
If you want to redirect the output to a file, you can do this by typing net share > FileName.txt, where FileName.txt is the name of the file to create and to which you want to write, such as:
net share > C:logsfileshares.txt
You can redirect the output from get-smbshare to a file as well:
get-smbshare > C:logsfileshares.txt
If you follow the Net Share command with the name of a configured share, you see the complete configuration details for the share, as shown in the following example:
Share name EngData
Path C:EngData
Remark
Maximum users No limit
Users
Caching Manual caching of documents
Permission CPANDLDomain Admins, FULL
CPANDLDomain Users, READ
CPANDLEngineeringUsers, READ
The command completed successfully.You can append the share configuration details to the previously created log file by using the append symbol (>>) instead of the standard redirect symbol (>), as shown in the following example:
net share corpdata >> C:logsfileshares.txt
A sample share logging script shows the source of a command-line script that you could use to create a configuration log for the key shares on the computer. Although the path in the example is set to c:logsfileshares.txt, you can set any log path you want.
Windows Server 2012 R2 adds Kerberos armoring, compound identities, and claims-based access controls to the standard access controls. Kerberos armoring improves domain security by allowing domain-joined clients and domain controllers to communicate over secure, encrypted channels. Compound identities incorporate not only the groups of which a user is a member but also user claims, device claims, and resource properties.
At their most basic, claims-based access controls enable you to define conditions that limit access as part of a resource’s advanced security permissions. Typically, these conditions add device claims or user claims to the access controls. User claims identify users; device claims identify devices. For example, to access the CorpTech share, you might want to add a device claim to ensure that the computer being used to access a resource is a member of Tech Computers and add a user claim that ensures that the user is a member of the CorpUsers group.
Kerberos armoring, compound identities, and claims-based access controls can also work together as part of the extended authorization platform in Windows Server. This platform allows dynamic access to resources by using central access policies.
With central access policies, you define central access rules in Active Directory and those rules are applied dynamically throughout the enterprise. Central access rules use conditional expressions that require you to determine the resource properties required for the policy, the claim types and security groups required for the policy, and the servers to which the policy should be applied.
Configuring central access policies is a multistep process that usually begins with defining the resource properties and claim types you’ll use as part of your policies. Afterward, you create access rules based on the claim types and then you establish dynamic controls by adding the rules to the appropriate group policies. Thus, the process typically looks like this:
First, you create resource properties. Resource properties create property definitions for resources. For example, you might want to add Department and Country/Region properties to files so that you can control access dynamically by department and by country or region.
Next, you create claim types that use those properties. Claim types create claim definitions for resources. For example, you might want to create a user claim to add Department and Country/Region properties to User objects so that you can control access dynamically by department and by country or region.
After you create resource properties and claim types and determine where the policy should be applied, you create an access rule and then add it to a central access policy. Adding the rule to a policy makes it available for dynamic control.
Last, you apply the policy across file servers by using Group Policy.
Servers to which you want to apply dynamic controls must have the File And Storage Services role with the File Server, Storage Services, and File Server Resource Manager role services at a minimum. You need the File Server Resource Manager role service and the related tools to apply classification property definitions to folders.
Claims-based policy should be enabled for all domain controllers in a domain to ensure consistent application. A domain must have at least one Windows Server 2012 R2 domain controller, and file servers must run Windows Server 2012 R2. By default, domain controllers are placed in the Domain Controllers organizational unit (OU) and the Default Domain Controllers policy has the highest precedence among Group Policy Objects (GPOs) linked to the Domain Controllers OU.
If your organization uses this approach, claims-based policy must be enabled for the Default Domain Controllers policy. If your organization uses a different approach, you need to ensure that the GPO with the highest precedence for the appropriate OU has claims-based policy enabled and configured properly.
You enable claims-based policy by using the KDC Support For Claims, Compound Authentication Dynamic Access Control And Kerberos Armoring policy in the Administrative Templates policies for Computer Configuration under SystemKDC. The policy must be configured to use a specific mode. The available modes are as follows:
Supported. Domain controllers support claims, compound identities, and Kerberos armoring. Client computers that don’t support Kerberos armoring can be authenticated.
Always Provide Claims. Same as Supported, but domain controllers always return claims for accounts.
Fail Unarmored Authentication. Specifies that Kerberos armoring is mandatory. Client computers that don’t support Kerberos armoring cannot be authenticated.
You can then work with dynamic access controls in Active Directory Administrative Center. When you are working with the Dynamic Access Control node, I recommend using Tree View, as shown in Figure 19-8, rather than the List View. With Tree View, you see related subnodes in the left pane, and this will make it easier to configure central access policy.
Central access policies don’t replace traditional access controls. Instead, you use central access policies to enhance existing access controls by defining very precisely the specific attributes users and devices must have to access resources.
Before you can deploy central access policies, you need to perform the following tasks in Active Directory Administrative Center:
Use the Claim Types node to create and manage claim types. For example, right-click in the Claim Types pane, click New, and then select Claim Type to start creating a new claim type.
Use the Resource Properties node to create and manage resource properties. For example, right-click in the Resource Properties pane, click New, and then select Resource Property to start creating a new resource property. Resource properties are added as classification definition properties on file servers as well.
Use the Central Access Rules node to create and manage central access rules. For example, right-click in the Central Access Rules pane, click New, and then select Central Access Rule to start creating a new access rule.
Use the Central Access Policies node to create and manage central access policies. For example, right-click in the Central Access Policies pane, click New, and then select Central Access Policy to start creating a new access policy.
You can then complete the deployment by editing the highest-precedence GPO linked to the OU where you put file servers and enabling central access policies. To do this, follow these steps:
In Group Policy Management, open the GPO for editing. Navigate the Computer Configuration policies to Windows SettingsSecurity SettingsFile System. When you select the Central Access Policy node in the left pane, any currently deployed central access policies are listed in the right pane, as shown in Figure 19-9.
Press and hold or right-click Central Access Policy and then tap or click Manage Central Access Policies. This opens the Central Access Policies Configuration dialog box.
In the Central Access Policies Configuration dialog box, shown in Figure 19-10, available policies are listed in the left pane and currently applied policies are listed in the right pane.
To apply a policy, tap or click it in the left pane and then click Add. To remove a policy, tap or click it in the right pane and then click Remove.
Tap or click OK to apply any changes.
The dynamic controls are available as soon as the Group Policy changes take effect on your servers. You can speed the refresh along by entering gpupdate /force at an elevated command prompt.
After you enable central access policy and any time you update your classification property definitions, you need to wait for Global Resource Properties from Active Directory to refresh on your file servers as well. You can speed this along by opening an elevated Windows PowerShell prompt and entering update-fsrmclassificationpropertydefinition. Do this on each file server where you want to configure central access policies.
The deployment of central access policies isn’t completed yet. You still need to edit the properties of each folder where you want a central access policy to apply and do the following:
Add the appropriate classification definitions on the folder’s Classification tab. On the Classification tab, each resource property you created will be listed. Select each property in turn and then set its value as appropriate.
Enable the appropriate policy by using advanced security settings for the folder. On the Security tab, tap or click Advanced and then select the Central Policy tab. Any currently selected or applied policy is listed along with a description you can use to review the rules of that policy. When you tap or click Change, you can use the selection list provided to select a policy to apply or you can choose No Central Access Policy to stop using the policy. Tap or click OK.
You need to repeat this process for each top-level or other folder where you want to limit access. Files and folders within the selected folder inherit the access rule automatically unless you specify otherwise. For example, if you create an access rule called US Marketing Only and define Department and Country/Region resource definitions, you could edit a folder’s properties, select the Classification tab, and use the available options to set Department to Marketing and Country/Region to US. Then you could apply the US Marketing Only policy by using the advanced security settings for the folder.
Access permissions only help protect data; they don’t tell you who deleted important data or who was trying to access files and folders inappropriately. To track who accessed files and folders and what they did, you must configure auditing for file and folder access. Every comprehensive security strategy should include auditing. Auditing settings you configure are applied to specific computers through local computer policy and to multiple computers through Group Policy.
Because auditing policies are applied as part of computer configuration rather than of user configuration, they must be applied through GPOs that are applied to computer OUs. Therefore, if you want an auditing setting to be applied to specific file servers, you configure the auditing setting in a Group Policy Object linked to the appropriate resource OUs. If you want an auditing setting to be applied throughout a domain, you configure the auditing setting in a Group Policy Object linked to the domain, and the setting will apply to all computers in the domain.
Generally, when you want auditing settings to apply only to specified resources and groups of users, you modify the security settings of the relevant objects so that auditing is enabled for the security groups of which the users are members. For example, you could configure auditing on the CurrentProjects folder to track changes and deletions that members of the TempWorkers group make.
Windows Server supports basic auditing and advanced auditing. Basic auditing includes the settings under Windows SettingsSecurity SettingsLocal PoliciesAudit Policy. Advanced auditing includes the settings under Windows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationAudit Policies. When you configure auditing, you use either basic or advanced auditing, not both. Advanced auditing can be applied to computers running Windows 7 or later and Windows Server 2008 R2 or later (and Windows Server 2008 and Windows Vista when logon scripts are used to apply advanced audit policy).
To track file and folder access, you must do the following:
Enable either basic or advanced auditing.
Specify which files and folders to audit or enable global object access auditing.
Track audit events by monitoring the security logs or using a collection tool such as Audit Collection Services in System Center Operations Manager.
Keep in mind that global object access policy is designed to be used with advanced auditing. If you choose to use advanced auditing rather than basic auditing, you can prevent conflicts between basic and advanced settings by forcing Windows to ignore basic auditing settings. To do this, enable the Audit: Force Audit Policy security setting as appropriate in Group Policy. This security setting is under Windows SettingsSecurity SettingsLocal PoliciesSecurity Options.
You configure basic auditing policies by using Group Policy or local security policy. Use Group Policy when you want to set auditing policies for an entire site, domain, or organizational unit. Local security policy settings apply to an individual workstation or server and can be overridden by Group Policy.
To enable basic auditing of files and folders for multiple computers through Group Policy, select Group Policy Management on the Tools menu in Server Manager. Next, press and hold or right-click the GPO you want to work with and then select Edit. In Group Policy Management Editor, expand Policies, Windows Settings, Security Settings, and Local Policies and then select Audit Policy, as shown in Figure 19-11.
To enable basic auditing of files and folders for a specific computer, start the Local Security Policy tool by selecting the related option on the Tools menu in Server Manager. Expand Local Policies and then select Audit Policy.
Next, double-tap or double-click Audit Object Access. This opens the Audit Object Access Properties dialog box shown in Figure 19-12. In a domain, enable the policy for configuration by selecting Define These Policy Settings. Under Audit These Attempts, select the Success check box to log successful access attempts, the Failure check box to log failed access attempts, or both check boxes and then tap or click OK. This enables auditing, but it doesn’t specify which objects should be audited. You do that by editing the properties of each object that you want to track, which can include files and folders, registry settings, and more.
As with basic auditing, you configure advanced auditing policies by using Group Policy or local security policy. To enable advanced auditing of files and folders for multiple computers through Group Policy, select Group Policy Management on the Tools menu in Server Manager. Next, press and hold or right-click the GPO you want to work with and then select Edit. In Group Policy Management Editor, expand Policies, Windows Settings, Security Settings, Advanced Audit Policy Configuration, and Audit Policies and then select Object Access, as shown in Figure 19-13.
To enable auditing of files and folders for a specific computer, start the Local Security Policy tool by selecting the related option on the Tools menu in Server Manager. Expand Advanced Audit Policy Configuration and System Audit Policies - Local Group Policy Object and then select Object Access.
With advanced auditing, identify specific types of object access to track by using the available options, which include the following:
Audit File Share. Generates audit events whenever an attempt is made to access a shared folder. Because shared folders don’t have system access control lists (SACLs), access to all shares on the system is audited (which includes network access to the SYSVOL on domain controllers). Only one audit event is recorded for any connection established between a client and a file share. To record events every time a file or folder on a share is accessed, use the Audit Detailed File Share policy.
Audit File System. Generates audit events for objects when the type of access requested and the account making the request match the settings in SACLs set on the objects. For example, if a user tries to modify a file and is a member of a group for which you enabled auditing of success and failure Modify events, related audit events will be generated and recorded in the security log. An audit event is generated each time an account accesses a file system object with a matching SACL.
Audit Detailed File Share. Generates audit events whenever an attempt is made to access a file or folder on a share. Because shared folders don’t have SACLs, access to all shared files and folders on the system is audited. An audit event is recorded every time a file or folder on a share is accessed.
To configure these policies, double-tap or double-click a policy to open its Properties dialog box. As shown in Figure 19-14, select Configure The Following Audit Events and then select the Success check box to log successful access attempts, the Failure check box to log failed access attempts, or both check boxes and then tap or click OK. This enables auditing, but it doesn’t specify which files and folders should be audited.
Next, ensure that advanced audit policy overrides basic audit policy. To do this, whenever you edit the Group Policy Objects and enable advanced audit policy, you must also enable the Audit: Force Audit Policy Subcategory Settings security setting. This security setting is under Windows SettingsSecurity SettingsLocal PoliciesSecurity Options.
In the Group Policy editor, double-tap or double-click the Audit: Force Audit Policy security setting to open its Properties dialog box. Select Define This Policy Setting and then select Enabled. Finally, tap or click OK.
After you enable the auditing of object access, you can set the level of auditing by either specifying which files and folders to audit or enabling global object access auditing. Auditing of individual folders and files enables you to control whether and how folder and file usage is tracked. Keep in mind that auditing is available only on NTFS and ReFS volumes. In addition, everything discussed about inheritance applies to files and folders as well—and this is a good thing. This enables you, for example, to audit access to every file or folder on a volume just by specifying that you want to audit the root folder of the volume.
You can use either File Explorer or Server Manager to view and configure auditing. In Server Manager, press and hold or right-click the share you want to work with and then tap or click Properties. In the Properties dialog box, tap or click the Permissions in the left pane. Tap or click Customize Permissions to open the Advanced Security Settings dialog box.
In File Explorer, you can view special permissions by pressing and holding or right-clicking the file or folder you want to work with and selecting Properties on the shortcut menu. In the Properties dialog box, select the Security tab and then tap or click Advanced to open the Advanced Security Settings dialog box.
In the Advanced Security Settings dialog box, tap or click the Auditing tab. You can now view and manage auditing settings by using the options shown in Figure 19-15.
The Auditing Entries list shows the users, groups, or computers whose actions you want to audit. To remove an account, select the account in the Auditing Entries list and then tap or click Remove.
You can audit access related to basic permissions and special permissions as listed in Table 19-4 and Table 19-5, respectively. Keep in mind that basic permissions include multiple special permissions. Therefore, when you audit the Modify permission, this tracks access related to Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, Create Files/Write Data, Create Folders/Append Data, Write Attributes, Write Extended Attributes, Delete, and Read permissions.
You can configure auditing for additional users, computers, or groups by following these steps:
Tap or click Add and then click Select A Principal to open the Select Users, Computers, Service Accounts, Or Groups dialog box.
Type the name of a user, computer, or group in the current domain and then tap or click Check Names. Be sure to reference the user account name rather than the user’s full name. Only one name can be entered at a time. If you want to audit actions for all users, use the special Everyone group. Otherwise, select the specific user groups, users, or both that you want to audit.
Tap or click OK. The user and group are added, and the Principal and the Auditing Entry dialog box are updated to show this. Only basic permissions are listed by default. If you want to work with advanced permissions, tap or click Show Advanced Permissions to display the special permissions.
Optionally, use the Applies To list to specify at what level objects are audited. If you are working with a folder and want to replace the auditing entries on all child objects of this folder (and not on the folder itself), select Only Apply These Settings To Objects And/Or Containers Within This Container.
Note
The Applies To list enables you to specify where you want the auditing settings to apply. The Only Apply These Settings To Objects And/Or Containers Within This Container check box controls how auditing settings are applied. When this check box is selected, auditing settings on the parent object replace settings on child objects. When this check box is cleared, auditing settings on the parent object are merged with existing settings on child objects.
Use the Type list to specify whether you are configuring auditing for success, failure, or both and then specify which actions should be audited. Success logs successful events such as successful file reads. Failure logs failed events such as failed file deletions. The events you can audit are the same as the special permissions discussed previously, except that you can’t audit the synchronizing of offline files and folders.
If you’re using claims-based policies and want to limit the scope of the auditing entry, you can add claims-based conditions to the auditing entry. For example, if all corporate computers are members of the Approved Computers group, you might want to audit access closely by devices that aren’t members of this group.
Tap or click OK. Repeat this process to audit other users, groups, or computers.
Note
Often, you’ll want to track only failed actions. This way, you know if someone was trying to perform an action and failed. Keep in mind that a failed attempt doesn’t always mean someone is trying to break into a file or folder. A user simply might have double-tapped or double-clicked a folder or file to which he didn’t have access. In addition, some types of actions can cause multiple failed attempts to be logged even when the user performed the action only once. Regardless, as an administrator, you should check multiple failed attempts because of the possibility that someone is attempting to breach your system’s defenses.
Instead of tracking access to specific files and folders, your business or compliance policies might require you to track specific types of access on sensitive computers. For example, you might need to track all access activity on servers containing sensitive data. To do this without having to configure SACLs, you can use global object access policy.
Global object access policy is designed to be used with advanced auditing and two object access areas:
Audit File System, which must be enabled to track global access to files and folders
Audit Registry, which must be enabled to track global access to the registry
After you enable file system auditing, registry auditing, or both, you can enable global access policy. Global access policy generates audit events for objects when the type of access requested and the account making the request match the settings in SACLs configured in the global access policy.
You configure global access policy by using Group Policy or local security policy. Follow these steps:
Open the GPO you want to work with for editing. Next, in Group Policy Management Editor, expand Policies, Windows Settings, Security Settings, Advanced Audit Policy Configuration, and Audit Policies and then select Global Object Access Auditing.
Double-tap or double-click the File System setting to open its Properties dialog box. Select Define This Policy Setting and then tap or click Configure. This opens the Advanced Security Settings For Global File SACL dialog box, shown in Figure 19-16.
In the Advanced Security Settings For Global File SACL dialog box, tap or click Add. Next, in the Auditing Entry dialog box, tap or click Select A Principal to open the Select User, Computer, Service Account Or Group dialog box. Type the name of the user, group, or computer to audit and then tap or click Check Names. Only one name can be entered at a time. Be sure to reference the user account name rather than the user’s full name.
Use the Type list to specify whether you are tracking successful or failed access and then select the permissions you want to audit. If you want to track both successful and failed access, choose All as the type.
With Windows Server 2012 R2, you can extend claims-based access controls to auditing. Here, you create central audit policies that use claims and resource properties. The result is a more targeted and easier-to-manage auditing policy that can help you meet business and compliance requirements such as policies that do the following:
Precise targeting helps limit the volume of collected data while focusing on the most relevant data. Although the auditing events are generated on a per-server basis, event collection and analysis tools, such as Audit Collection Services in System Center Operations Manager, make it possible to collect the events centrally and search through them in new ways.
The easiest way to extend claims-based access controls to auditing is to follow these steps:
Enable and configure central access policies as discussed in “Managing claims-based access controls” earlier in the chapter.
Enable either object access or global object access auditing as discussed in “Enabling advanced auditing” earlier in the chapter.
Use the claim types and resource properties you defined to help you fine-tune audit policy.
An example of extending claims-based access controls to auditing is shown in Figure 19-17. Here, you limit the auditing to members of the Contractors group who are outside a specified country or region and who don’t have their Company property set as City Power.
Any time files and folders that you’ve configured for auditing are accessed, the action is written to the system’s Security log, where it’s stored for your review. The Security log is accessible from Event Viewer. Successful actions can cause successful events, such as successful file reads, to be recorded. Failed actions can cause failed events, such as failed file deletions, to be recorded.