Introduction
AppLocker is a new feature available in Windows 7 and Windows Server 2008 R2 that helps to prevent the use of unknown or unwanted applications within a network. Its functionality boasts both security and compliance benefits for a wide array of organizational environments.
AppLocker is a feature in Windows Server 2012, Windows
Server 2008 R2, Windows 8, and Windows 7 that advances the functionality
of the Software Restriction Policies feature. AppLocker contains new
capabilities and extensions that reduce administrative overhead and help
administrators control how users can access and use files, such as
executable files, scripts, Windows Installer files, and DLLs. By using
AppLocker, you can:
-
Define rules based on file attributes that persist across
application updates, such as the publisher name (derived from the
digital signature), product name, file name, and file version. You can
also create rules based on the file path and hash.
-
Assign a rule to a security group or an individual user.
-
Create exceptions to rules. For example, you can create a rule
that allows all users to run all Windows binaries except the Registry
Editor (Regedit.exe).
-
Use audit-only mode to deploy the policy and understand its impact before enforcing it.
-
Create rules on a staging server, test them, export them to
your production environment, and then import them into a Group Policy
Object.
-
Simplify creating and managing AppLocker rules by using Windows PowerShell cmdlets for AppLocker.
Software Restriction Policies was originally designed for
Windows XP and Windows Server 2003 to help IT professionals limit the
number of applications that would require administrator access. With the
introduction of User Account Control (UAC) and the emphasis of standard
user accounts in Windows Vista®, fewer applications require
administrator privileges. As a result, AppLocker was introduced to
expand the original goals of Software Restriction Policies (SRP) by
allowing IT administrators to create a comprehensive list of
applications that should be allowed to run.
Typically, an app consists of multiple components: the
installer that is used to install the app and one or more .exe file,
.dll file, or script. With classic apps, not all these components always
share common attributes such as the publisher name, product name, and
product version. Therefore, AppLocker controls each of these components
separately through the following rule collections: Exe, Dll, Script, and
Windows Installers. In contrast, all the components of a packaged app
share the same Publisher name, Package name, and Package version
attributes. It is therefore possible to control an entire app with a
single rule.
Rule conditions are properties of files that AppLocker uses
to enforce rules. Each AppLocker rule can use one primary rule
condition. The following three rule conditions are available in
AppLocker:
-
Publisher rule conditions can only be
used for files that are digitally signed by a software publisher. This
condition type uses the digital certificate (publisher name and product
name) and properties of the file (file name and file version). This type
of rule can be created for an entire product suite, which allows the
rule in most cases to still be applicable when the application is
updated.
-
Path rule conditions are based on the file or folder installation path of specific applications.
-
File hash rule conditions are based on
the unique file hash that Windows cryptographically computes for each
file. This condition type is unique, so each time that a publisher
updates a file, you must create a new rule.
In Windows Server 2008 R2 and Windows 7
AppLocker rules can be enforced on computers running
Windows 7 Ultimate, Windows 7 Enterprise, or any edition of Windows
Server 2008 R2 except Windows Web Server 2008 R2 and Windows
Server 2008 R2 Foundation.
To create rules for a local computer, the computer must be
running Windows 7 Ultimate or Windows 7 Enterprise. If you want to
create rules for a Group Policy Object (GPO), you can use a computer
that is running any edition of Windows 7 if the Remote Server
Administration Tools are installed. AppLocker rules can be created on
any edition of Windows Server 2008 R2. Although you can create AppLocker
rules on computers running Windows 7 Professional, they will not be
enforced on those computers. However, you can create the rules on a
computer running Windows 7 Professional and then export the policy for
implementation on a computer running an edition of Windows that does
support AppLocker rule enforcement.
In Windows Server 2012 and Windows 8
AppLocker is supported on all Windows beta evaluation versions except the Server Core installation option.
The most common reasons why the AppLocker rules might not be enforced are:
-
The Application Identity service (AppIDsvc) is not running.
-
Rule enforcement is set to Audit only.
To view AppLocker events, you can use event forwarding technologies, Event Viewer (eventvwr.msc), or the Get-WinEvent Windows PowerShell cmdlet.
You can either use Remote Desktop to log on to a client
computer or physically log on to that computer to view or collect the
AppLocker events.
In Event Viewer, AppLocker events are stored in a log under: Applications and Services Logs\Microsoft\Windows\AppLocker. There are two child logs: one for executable files and DLLs and another for Windows Installer files and scripts.
When AppLocker is enabled, only applications that are
specified will be allowed to run. When you first create rules, AppLocker
will prompt you to create the default rules. These default rules ensure
that key Windows system files and all files in the Program Files
directory will be permitted to run. While the default rules are not
mandatory, we recommend that you start with the default rules as a
baseline and then edit them or create your own to ensure that Windows
will function properly.
If computers cannot start properly due to your AppLocker
policy, edit the AppLocker rules in the corresponding GPO to be less
restrictive. If the AppLocker rules are defined in a computer's local
policy, start the computer in Safe Mode, create the default AppLocker
rules, and then restart the computer.
AppLocker provides Windows PowerShell cmdlets designed
to streamline the administration of an AppLocker policy. They can be
used to help create, test, maintain, and troubleshoot an AppLocker
policy. The cmdlets are intended to be used in conjunction with the
AppLocker user interface that is accessed through the Microsoft
Management Console (MMC) snap-in extension to the Local Security Policy
snap-in and Group Policy Management Console.
No. A virtual machine is a separate image. Therefore, the
image cannot access the policy files of the computer that hosts the
AppLocker policies.
Some tasks can be done by using Remote Desktop. AppLocker
policies can be applied by using domain GPOs, local GPOs, or both. If a
user requests access to an application, you can use one of the Windows
PowerShell cmdlets, or you can use the Local Security Policy snap-in
(secpol.msc) to add a local rule to temporarily allow that application.
In both cases, you need to have administrator privileges. You can either
do this by using Remote Desktop or by using the Windows PowerShell
remote access capabilities.
There are three ways of doing this:
-
Back up the GPOs by using the GPMC (for domain policies only).
-
Export the AppLocker policy by using the AppLocker snap-in.
-
Create a script by using the Get-AppLockerPolicy Windows PowerShell cmdlet to export the policy.
AppLocker is a feature in Windows Server 2012, Windows Server 2008 R2, Windows 8, and Windows 7 that advances the functionality of the Software Restriction Policies feature. AppLocker contains new capabilities and extensions that reduce administrative overhead and help administrators control how users can access and use files, such as executable files, scripts, Windows Installer files, and DLLs. By using AppLocker, you can:
- Define rules based on file attributes that persist across application updates, such as the publisher name (derived from the digital signature), product name, file name, and file version. You can also create rules based on the file path and hash.
- Assign a rule to a security group or an individual user.
- Create exceptions to rules. For example, you can create a rule that allows all users to run all Windows binaries except the Registry Editor (Regedit.exe).
- Use audit-only mode to deploy the policy and understand its impact before enforcing it.
- Create rules on a staging server, test them, export them to your production environment, and then import them into a Group Policy Object.
- Simplify creating and managing AppLocker rules by using Windows PowerShell cmdlets for AppLocker.
Software Restriction Policies was originally designed for Windows XP and Windows Server 2003 to help IT professionals limit the number of applications that would require administrator access. With the introduction of User Account Control (UAC) and the emphasis of standard user accounts in Windows Vista®, fewer applications require administrator privileges. As a result, AppLocker was introduced to expand the original goals of Software Restriction Policies (SRP) by allowing IT administrators to create a comprehensive list of applications that should be allowed to run.
Typically, an app consists of multiple components: the installer that is used to install the app and one or more .exe file, .dll file, or script. With classic apps, not all these components always share common attributes such as the publisher name, product name, and product version. Therefore, AppLocker controls each of these components separately through the following rule collections: Exe, Dll, Script, and Windows Installers. In contrast, all the components of a packaged app share the same Publisher name, Package name, and Package version attributes. It is therefore possible to control an entire app with a single rule.
Rule conditions are properties of files that AppLocker uses to enforce rules. Each AppLocker rule can use one primary rule condition. The following three rule conditions are available in AppLocker:
- Publisher rule conditions can only be used for files that are digitally signed by a software publisher. This condition type uses the digital certificate (publisher name and product name) and properties of the file (file name and file version). This type of rule can be created for an entire product suite, which allows the rule in most cases to still be applicable when the application is updated.
- Path rule conditions are based on the file or folder installation path of specific applications.
- File hash rule conditions are based on the unique file hash that Windows cryptographically computes for each file. This condition type is unique, so each time that a publisher updates a file, you must create a new rule.
In Windows Server 2008 R2 and Windows 7
AppLocker rules can be enforced on computers running Windows 7 Ultimate, Windows 7 Enterprise, or any edition of Windows Server 2008 R2 except Windows Web Server 2008 R2 and Windows Server 2008 R2 Foundation.
To create rules for a local computer, the computer must be running Windows 7 Ultimate or Windows 7 Enterprise. If you want to create rules for a Group Policy Object (GPO), you can use a computer that is running any edition of Windows 7 if the Remote Server Administration Tools are installed. AppLocker rules can be created on any edition of Windows Server 2008 R2. Although you can create AppLocker rules on computers running Windows 7 Professional, they will not be enforced on those computers. However, you can create the rules on a computer running Windows 7 Professional and then export the policy for implementation on a computer running an edition of Windows that does support AppLocker rule enforcement.
In Windows Server 2012 and Windows 8
AppLocker is supported on all Windows beta evaluation versions except the Server Core installation option.
The most common reasons why the AppLocker rules might not be enforced are:
- The Application Identity service (AppIDsvc) is not running.
- Rule enforcement is set to Audit only.
To view AppLocker events, you can use event forwarding technologies, Event Viewer (eventvwr.msc), or the Get-WinEvent Windows PowerShell cmdlet.
You can either use Remote Desktop to log on to a client computer or physically log on to that computer to view or collect the AppLocker events.
In Event Viewer, AppLocker events are stored in a log under: Applications and Services Logs\Microsoft\Windows\AppLocker. There are two child logs: one for executable files and DLLs and another for Windows Installer files and scripts.
When AppLocker is enabled, only applications that are specified will be allowed to run. When you first create rules, AppLocker will prompt you to create the default rules. These default rules ensure that key Windows system files and all files in the Program Files directory will be permitted to run. While the default rules are not mandatory, we recommend that you start with the default rules as a baseline and then edit them or create your own to ensure that Windows will function properly.
If computers cannot start properly due to your AppLocker policy, edit the AppLocker rules in the corresponding GPO to be less restrictive. If the AppLocker rules are defined in a computer's local policy, start the computer in Safe Mode, create the default AppLocker rules, and then restart the computer.
AppLocker provides Windows PowerShell cmdlets designed to streamline the administration of an AppLocker policy. They can be used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets are intended to be used in conjunction with the AppLocker user interface that is accessed through the Microsoft Management Console (MMC) snap-in extension to the Local Security Policy snap-in and Group Policy Management Console.
No. A virtual machine is a separate image. Therefore, the image cannot access the policy files of the computer that hosts the AppLocker policies.
Some tasks can be done by using Remote Desktop. AppLocker policies can be applied by using domain GPOs, local GPOs, or both. If a user requests access to an application, you can use one of the Windows PowerShell cmdlets, or you can use the Local Security Policy snap-in (secpol.msc) to add a local rule to temporarily allow that application. In both cases, you need to have administrator privileges. You can either do this by using Remote Desktop or by using the Windows PowerShell remote access capabilities.
There are three ways of doing this:
- Back up the GPOs by using the GPMC (for domain policies only).
- Export the AppLocker policy by using the AppLocker snap-in.
- Create a script by using the Get-AppLockerPolicy Windows PowerShell cmdlet to export the policy.
No comments:
Post a Comment