Publisher condition
By selecting the Publisher
condition, you will be required to browse to an application file so that
the information about the Publisher as well as about the application
itself can be retrieved. Publisher is the best selection choice whenever
possible to assure consistency. When an application that has been
identified via Publisher is managed by AppLocker, it will always be
correctly identified across workstations regardless of the installation
directory.
You can also use the Publisher
condition to create rules that are more generic and impact multiple
applications instead of a single named application. For instance, let us
assume that I would like all applications from a particular vendor to
be allowed to run on the kiosk machines in my environment. The
applications from the vendor are various, and the version information
changes frequently. Creating individual rules for each of the
applications and then keeping them up to date as changes occur would be a
heavy administrative task.
To begin your configuration,
you create a GPO and apply it to the kiosk machines OU. Next, you need
to create your AppLocker rule. In this case, instead of specifying each
individual application with a different rule, you should utilize the
Publisher condition to create a single rule that is scoped to the vendor
level. To do this, you will still need to have the information of an
application to be used as a sampling that has been digitally signed from
the vendor you are trying to configure.
Begin the Create New Rule...
wizard and once you arrive on the conditions screen, select Publisher
and browse to the sample application. Once all of the application
information has populated on the screen, you can then use the slider
shown in Figure 5
to adjust the rule to a broader scope. By moving the slider up, it
removes the application-specific information from the rule, such as File
Version and File Name. You can even go so far up as to remove Product
Name, which would leave only the Publisher name of the vendor in the
screen, as displayed in Figure 5.
This would effectively create an AppLocker rule that targets a specific
vendor instead of an application created by the vendor.
Path condition
There are times when selecting
the Publisher condition is just not possible. If vendors do not
digitally sign their applications, then the Publisher condition cannot
be utilized. Another viable choice when this is the case is the Path
condition.
The Path condition requires
you to browse to the location of the executable and select it. The
policy will recall the executable file information as well as the path
to the executable. Both local paths and network paths may be specified.
AppLocker marches to the beat of its own tune, in that path, variables
may be specifics; however, the path variables are unique to AppLocker.
The path variables used by AppLocker do not follow the standardized
Windows environmental variables, and even though some of the values are
indeed the same, others are quite different. Table 2 displays a comparison between some of the AppLocker path variables and the Windows environmental variables.
Table 2. AppLocker and Windows Environmental Variables
Windows Path | AppLocker Variable | Windows Environmental Variable |
---|
Windows | %WINDIR% | %SystemRoot% |
System32 | %SYSTEM32% | %SystemDirectory% |
Windows installation directory | %OSDRIVE% | %SystemDrive% |
Program Files | %PROGRAMFILES% | %ProgramFiles% and %ProgramFiles(x86)% |
When the path option is
utilized with an Allow policy, the executable in the selected path will
be allowed to run, but executable files in other directory paths, even
with the same executable name, will be denied. An example of how Allow
behaves is as follows: You configure an Allow rule for an
application named BearToast. The application’s executable file,
BTst.exe, is located in the C:\Program Files\BToast directory.
Configuring this rule only allows applications with that designation
executable name within that specific directory to run. Any applications
of the same flavor in other directories will be denied.
File hash condition
For applications that are not
digitally signed and have varying paths, File hash is an option that may
be used. When you are selecting File hash with an application
executable, a computation is performed to generate a unique File hash
that will be used to identify the applications.
One thing to be aware of is
that the File hash will only pertain to that exact version of the
application. If different versions of the application exist in the
environment, you must create a rule for each that you wish to effect.
Automatically Generate Rules
The final rule creation method available to administrators to create rules within AppLocker is called Automatically Generate Rules. Instead of individually creating rules for applications, the Automatically Generate Rules allow the administrator to select at the folder level.
All of the applications
which reside in the selected folder will automatically be configured
within the rule set. You can indicate which conditions should be used to
identify the different applications. Publisher conditions are preferred
and in the case that a file is not digitally signed, you may indicate
an alternative method on the Rule Preferences screen, displayed in Figure 6.
This is a fast and easy way to create multiple rules in one fell swoop.
Also be aware that this method can only be used to create Allow rules.