Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Client-Side Checks and Client Side Actions
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

In BIG-IP® Access Policy Manager® access policies, you use client-side checks to collect and verify system information. In the visual policy editor, you can use the information collected by client-side checks in an access policy, to enforce a specific security level before granting access to network resources. You can also use this information to perform remediation and protect your network resources. The Access Policy Manager provides these checks as a set of access policy actions that you can use to construct an access policy to evaluate client systems.
Access Policy Manager uses ActiveX controls or browser plug-ins to collect information about client systems. For those clients that do not support browser add-ons or that do not allow browser software installation, the client-side security process can inspect HTTP headers to gather information on the client operating system, including the client operating system and browser type. You can check that a client supports client-side checks with the client-side check capability action. If a client does not support client-side checks, that client can follow a different access policy branch.
While Access Policy Manager provides checks for many client devices, some client-side checks may not be supported on all supported operating systems.
Antivirus check
Checks information about installed Windows, Macintosh, or Linux antivirus software, including vendor, version, state (enabled or disabled), and virus database age. For details, refer to Setting up antivirus check.
Firewall check
Checks information about installed Windows, Macintosh, or Linux firewalls, including vendor, state (enabled or disabled), and version. For details, refer to Setting up firewall check.
File check
Checks for the presence or absence of Windows, Macintosh, or Linux files based on specific file. For details, refer to Setting up file check.
Machine cert auth
Checks the client system for an installed machine certificate. For details, refer to Setting up file check.
Windows info
Checks the version information for the Windows operating system, such as version and hotfix information from the remote system. For details, refer to Verifying Windows information.
Process check
Checks for running Windows, Macintosh, or Linux processes. For details, refer to Setting up process check.
Registry check
Checks the Windows registry for keys and values that you specify. For details, refer to Setting up registry check.
You use the antivirus check action to check for antivirus software on the client computer. You can configure the antivirus check action to search for antivirus software from a set of available antivirus vendors, or for specific antivirus applications. In addition, the antivirus check can determine the specific version of the software, the specific virus database version, the age of the virus database, and whether the antivirus software is enabled.
When you configure the antivirus action with multiple antivirus types, the antivirus types work as logical OR operators. If one antivirus type you specify matches the software on the client computer, the action passes, regardless of other antivirus conditions that are specified in the action.
Use the antivirus check action to assure that clients who connect to secure resources are using an approved and up-to-date antivirus solution.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Antivirus Check and click Add Item to add the action to the access policy.
The Antivirus Check action popup screen opens.
a)
From the Antivirus ID list, select the antivirus vendor. Select Any to allow the access policy to pass with any antivirus. In this list, Windows-specific firewalls are marked with the prefix [Win], Macintosh-specific firewalls are marked with the prefix [Mac], and Linux-specific firewalls are marked with the prefix [Lin].
b)
From the State list, select a state for the antivirus. Select Enabled to specify that the selected antivirus (or any antivirus) is running on the computer. Select Unspecified to verify the presence of the antivirus software, but not the state.
c)
If you require a specific virus software engine version (for example, 5200.2000), in the Version box, type the version number. Note that this check does not allow for later versions, so if you check for a specific version, a later version will fail.
d)
If you require a specific virus database version (for example, 4.931.00), in the Database Version box, type a database version. Note that this check does not allow for later versions, so if you specify a check for a specific version, a later version will fail.
e)
If you require that the virus database not be older than a certain age, in the DB Age Not Older Than (days) box, type the database age in days. Be sure to use settings that are compatible with your software. Some antivirus services provide updates frequently, every few days; some antivirus services update only every week or less.
7.
8.
Click Save to complete the configuration.
In this example, the administrator adds support for two popular corporate antivirus solutions: McAfee on Windows, and Symantec on Mac and Linux platforms. The administrator specifies that any of these antivirus solutions must be running, with virus databases no older than 7 days, for the client computers to pass the condition successfully.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Antivirus Check and click Add Item to add the action to the access policy.
The Antivirus Check action popup screen opens.
a)
From the Antivirus ID list, select [win/mac/linux] McAfee, Inc.
b)
From the State list, select Enabled.
c)
In the DB Age Not Older Than (days) box, Type 7.
7.
Click Add new entry to add an antivirus entry to the action.
Note that new entries are added above previously configured entries, by default.
a)
From the Antivirus ID list, select [mac] Symantec Corp.
b)
From the State list, select Enabled.
c)
In the DB Age Not Older Than (days) box, type 7.
9.
Click Add new entry to add an antivirus entry to the action.
Note that new entries are added above previously configured entries, by default.
a)
From the Antivirus ID list, select [win/linux] Symantec Corp.
b)
From the State list, select Enabled.
c)
In the DB Age Not Older Than (days) box, Type 7.
11.
Click Save to save the access policy.
You use the file check action for Windows, Macintosh, or Linux to verify the presence of one or more files on a client system. On all supported platforms, the file check action can verify one or more file properties, including the file name, size, date, and MD5 checksum. In addition, the Windows version of the file check action can verify version and signer information.
If a file with the described properties exists, the client is passed to the successful branch. If the file does not exist, or a file exists but one or more properties are not correct, the client is passed to the fallback branch.
Add a file check action to an access policy in a situation where verifying the presence of a certain file can increase confidence in the security of the client system.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
For Windows, select Windows File Check and click Add Item to add the action to the access policy.
For Macintosh, select Mac File Check and click Add Item to add the action to the access policy.
For Linux, select Linux File Check and click Add Item to add the action to the access policy.
6.
Click Add new entry to add a file entry to the action.
a)
In the FileName box, type the name for the file you want to check.
Note that this is the only setting that is required.
b)
If you want to verify that the MD5 checksum matches, in the MD5 box, type or paste the MD5 checksum.
c)
If you require an exact size for the file, in the Size box, type the size in bytes.
Note that if you type a 0 in this box, no file size check occurs. To check for a 0-byte file, you must instead type the MD5 checksum in the MD5 box. The MD5 checksum for a 0-byte file is always d41d8cd98f00b204e9800998ecf8427e.
d)
If you want to specify the file creation date, in the Date box, type the file creation date. The default date of 1970-01-01 00:00:00 is the same as specifying no date.
You can determine the file creation date by right-clicking the file in Windows, and selecting Properties. The file creation date must be translated to a 24-hour clock, if your system is not on 24-hour time. For example, you would type the file creation date
Wednesday, February 27, 2008, 1:23:37 PM
in this box as 2008-02-27 13:23:37. The file creation date is set in UTC, or Greenwich Mean Time (GMT), so the server and client timezones are not the same as the file time, and you must adjust the file time you specify accordingly.
e)
For Windows file check only, if you require that the file be signed, in the Signer box, type the signer.
f)
For Windows file check only, in the Version box, type the version of the file, if you want to specify a version, or greater than or less than a version of the file.
g)
For Windows file check only, from the Version Comparison list, select the version comparison operator. Select = if you want the file to be the exact version you specify, select < if you want the checked file version to be greater than the version number you specify, and select > if you want the checked file version to be less than the version number you specify.
9.
Click Save to complete the configuration.
In this example, the administrator adds a Windows file check action, with the requirement that a system file, wininet.dll, be present on the client system. The file must be version 6.0.2900.2904, be 658,432 bytes in size, and have an MD5 checksum of 38ab7a56f566d9aaad31812494944824.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Windows File Check and click Add Item to add the action to the access policy.
The File Check action popup screen opens.
6.
Click Add new entry to add a file entry to the action.
In the File Name box, type wininet.dll.
In the MD5 box, type the MD5 checksum 38ab7a56f566d9aaad31812494944824.
Many MD5 checksum utilities include a copy function to simplify this step.
In the Size box, type 658432.
In the Version box, type 6.0.2900.2904.
From the Version Comparison list, select =.
8.
Click Save to complete the configuration.
You use the machine certificate authentication check action to check for the presence of a machine certificate on the client computer. You can configure the action to check for a certificate in a specific location, and to require matches with particular certificate fields to pass.
Certificate Store Name
Specifies the certificate store name that the action attempts to match. The certificate store can be a system store with a predefined name like MY, or a user-defined name. The store name can contain alphanumeric characters. The default store name is MY.
Certificate Store Location
Specifies the type and location of the store that contains the certificate, either the local machine or the current user. The store locations are in the following registry locations:
LocalMachine - searches in HKEY_LOCAL_MACHINE for the machine certificate.
CurrentUser - searches in HKEY_CURRENT_USER for the machine certificate.
CA Profile
Specifies the certificate authority profile for the machine certificate. To configure a certificate authority, on the navigation pane, expand Local Traffic, click Profiles, from the SSL menu select Certificate Authority, and click Create.
OCSP Responder
Specifies the Online Certificate Status Protocol responder configured to provide certificate status. The OCSP responder is used to check the status of the machine certificate configured in the machine cert auth check action.
Certificate Match Rule
Specifies how the machine cert auth check action identifies the certificate. The following match rules are supported:
SubjectCN Match FQDN - Specifies that the common name in the machine certificate matches the computers fully qualified domain name (FQDN).
SubjectAltName Match FQDN - Specifies that the content extracted from the Subject Alternative Name field, using a specified regular expression, must match the computers FQDN.
When this option is selected, the SubjectAltName box appears. This box is required for the SubjectAltName match value only. The regular expression is used to extract content from the first subgroup matched in the Subject Alternative Name, and then to compare the extracted content with the machines FQDN.

Note that the order of RDNs is the same as is displayed; the required separator is a comma ( , ). Subcases for regex extraction follow:

Partial extraction. For example,
".*DNS Name=([^,]+).*"
or
".*Other Name:Principal Name=([^,]+).*".
For a regular expression
'.*DNS Name=([^,]+).*', the value of the DNS Name field is extracted for matching.

Whole extraction. Leave this field empty or use "(.*)", in order to allow the entire SubjectAltName content to be extracted for matching.
Any - Specifies that the first certificate in the specified certificate store is sent to the server for further validation. Any other certificates are ignored.
Issuer - Specifies that the content from the Issuer field matches the pattern specified by the regular expression.
When this option is selected, the Issuer box appears. This box is required for the Issuer match, as well as Issuer and Serial Number match. The regular expression is used to match the Issuers content against the specified pattern.

Note that the order of RDNs is the same as is displayed; the required separator is a comma ( , ).

Subcases for the regex match are as follows:

Partial match. For example,
"CN=.*, OU=FP, O=F5, L=San Jose, S=CA, C=US"

Exact Match. For example,
"CN=Root, OU=FP, O=F5, L=San Jose, S=CA, C=US"
Issuer and Serial Number - Specifies that the content from the Issuer field matches the pattern specified by the regular expression, and that the serial number precisely matches your input.
When this option is selected, the Issuer box appears. This box is required for the Issuer match, as well as Issuer and Serial Number match. The regular expression is used to match the Issuers content against the specified pattern.
When this option is selected, the Serial Number box appears. The serial number must be an exact match (for example, the hex string must be typed in the same order as it is displayed by OpenSSL and Windows cert tools). For example,
0102030405060708090a.
Save Certificate in a session variable
Select Enabled to save the complete encrypted text of the machine certificate in a session variable, session.windows_check_machinecert.<name>.cert.
Use the machine cert auth check action to check for the existence of fields in a machine cert, to ensure that client systems comply with your security policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Machine Cert Auth and click Add Item to add the action to the access policy.
The Machine Cert Auth action popup screen opens.
6.
In the Certificate Store Name box, type the certificate store name, or use the provided value, MY.
7.
From the Certificate Store Location list, select the certificate store registry location.
8.
From the CA Profile list, select the certificate authority.
9.
From the OCSP Responder list, select an OCSP responder, if required, or None.
10.
From the Certificate Match Rule list, select the desired certificate match rule, and enter values in any related boxes that appear.
See Understanding machine cert auth check options, for more information.
11.
From the Save Certificate in a session variable list, select Enabled to save the certificate in a session variable, or Disabled to not save the certificate as a session variable.
12.
Click Save to complete the configuration.
In this example, the machine certificate checks the fully qualified domain name for www.siterequest.com against the Subject Alternative Name field.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Machine Cert Auth and click Add Item to add the action to the access policy.
The Machine Cert Auth action popup screen opens.
6.
From the Certificate Match Rule list, select SubjectAltName match FQDN.
7.
In the Subject Alternative Name box, type *.siterequest.com.
9.
Click Save to complete the configuration.
The firewall check action is used to check for firewall software on the client computer. The action can be configured to check for available firewall, or specific firewall vendors. In addition, the firewall check can determine whether the firewall software is enabled, and verify the version of the software.
When you configure the firewall action with multiple firewall types, the firewall types work as logical OR operators. If one firewall you specify matches the software on the client computer, the action passes, regardless of other firewall conditions that are specified in the action.
Use the firewall check action to check for the existence of files that can ensure that client systems comply with your security policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Firewall Check and click Add Item to add the action to the access policy.
The Firewall Check action popup screen opens.
6.
Click Add new entry to add a firewall entry to the action.
From the Firewall ID list, select a firewall, or select Any to allow the access policy to pass with any supported firewall.
In this list, Windows-specific firewalls are marked with the prefix [Windows], Macintosh-specific firewalls are marked with the prefix [Mac], and Linux-specific firewalls are marked with the prefix [Linux].
From the State list, select the state to allow for the firewall. Select Enabled to specify that the selected firewall (or any firewall) is running on the computer. Select Unspecified to verify the presence of the firewall software, but not the state.
9.
Click Save to complete the configuration.
In this example, the administrator adds support for two popular firewall solution vendors: Microsofts built-in Windows Firewall, Apple Computers built-in Mac OS X Firewall, and the Linux IPTables firewall. The administrator specifies that one of these firewall solutions must be running.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Firewall Check and click Add Item to add the action to the access policy.
The Firewall Check action popup screen opens.
6.
Click Add new entry to add a firewall entry to the action.
7.
Configure Microsoft:
From the Firewall ID list, select [win] Microsoft Corp. (MSWindowsFW).
From the State list, select Enabled.
8.
Click Add new entry to add a firewall entry to the action.
9.
Configure Apple Computer:
From the Firewall ID list, select [mac] Apple Computer, Inc.
From the State list, select Enabled.
10.
Click Add new entry to add a firewall entry to the action.
11.
Configure iptables:
From the Firewall ID list, select [linux] IPTables.
From the State list, select Enabled.
12.
Click Save to complete the configuration.
You use the process check action with a Boolean expression to check for processes that are running on the client system.
The Boolean expressions you specify can use the wildcards * and ?, parentheses ( ) to combine values, and the logical operators AND, OR, and NOT.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select the Process Check for the operating system you are checking, and click Add Item to add the action to the access policy.
The Process Check action popup screen opens.
6.
In the Expression box, type the expression.
7.
Click Save to complete the configuration.
In this example, you use the process check action to determine the presence of the running Windows processes winlogon.exe and GoogleDesktop.exe. You also determine that no process with gator in the name is running.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Windows Process Check and click Add Item to add the action to the access policy.
The Process Check action popup screen opens.
6.
In the Expression box, type the process check expression as follows:
7.
Click Save to complete the configuration.
You can set up the registry check action or verify the existence or absence of certain keys and values in the Windows system registry database. Both key values or Boolean expressions evaluate the existence or absence of registry entries.
key
Represents a path in the Windows registry.
value
Represents the name of the value.
comparison_operator
Represents one of the comparison operators (< <= > >= != =) or ISPR. ISPR is used to verify that a key or value is present.
For equality use =. The operator == is not valid here.
data
Represents the content to compare against.
Note: Quotation marks (") are required around key and value arguments. Quotation marks are used in data if the content contains spaces, commas, slashes, tabs, or other delimiters. If quotation marks exist as part of the registry path or value name, they should be doubled (use two sets of quotation marks). data is treated as a version number if it is entered in the format d.d[.d][.d] or d,d[,d][,d] (where d is a number), and as a date if it is entered in the format mm/dd/yyyy.
"HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\XP"
Checks for the presence of the specified path in the registry.
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Internet Explorer.Version">= "6.0.2900.2180"
Checks that the Internet Explorer version is greater than or equal to the value specified.
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InternetExplorer.Version" >= "5.0.2800.0" AND "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
InternetExplorer.Version" <= "6.0.2900.0"
Checks for the presence of Internet Explorer. With this registry check, the Internet Explorer version must be greater than or equal to 5.0.2800.0, and less than or equal to 6.0.2900.0.
The registry check action verifies that one or more particular registry checks exist, or do not exist, and confirms that the registry values are supported.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Registry Check and click Add Item to add the action to the access policy.
The Registry Check action popup screen opens.
6.
In the Expression box, type the registry check expression.
7.
Click Save to complete the configuration.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Registry Check and click Add Item to add the action to the access policy.
The Registry Check action popup screen opens.
6.
In the Expression box, type:
"HKEY_LOCAL_MACHINE\Software\Google\Google Desktop.ResourceDLL"
7.
Click Save to complete the configuration.
You use the Windows info check action to verify the presence of Windows operating system versions, Windows patches, or Windows updates.
Use the Windows info action to determine if the user is using the correct version of Windows, has applied specific patches or updates to Windows, or meets other Windows requirements.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Windows Info and click Add Item to add the action to the access policy.
The Windows Info action popup screen opens.
7.
Click the Add Rule button.
8.
In the Name box, type a name for the rule.
9.
Next to Expression: Empty, click change.
The Add Expression popup screen opens.
10.
Click the Add Expression button.
11.
From the Agent Sel. list, select Windows Info.
12.
From the Condition list, select Windows platform or Windows update.
If you selected Windows platform, from the Windows Platform is list, select the Windows version.
If you selected Windows update, in the Windows patch box, type the update name. The format for this can be a KB patch or a Windows service pack, for example KB869074 or SP2.
13.
Click Save to complete the configuration.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Windows Info and click Add Item to add the action to the access policy.
The Windows Info action popup screen opens.
7.
Click Add Rule.
8.
Type the name XP SP2 for the rule.
9.
Next to Expression: Empty, click change.
The Expression popup screen opens.
10.
Click the Add Expression button.
The popup screen displays new information.
11.
From the Agent Sel. list, select Windows Info.
12.
From the Condition list, select Windows platform.
13.
From the Windows Platform is list, select Windows XP.
14.
Click the Add Expression button.
15.
To add the next expression, next to AND, click Add Expression.
The popup screen displays new information.
16.
From the Agent Sel. list, select Windows Info.
17.
From the Condition list, select Windows update.
18.
From the Windows Platform is list, select Windows XP.
19.
In the Windows Patch box, type SP2.
20.
Click the Add Expression button.
The Expression popup screen shows the expression configured as shown in Figure 9.6.
To view the rule you have created, click the Advanced tab. You see the expression
expr { [mcget {session.windows_info_os.last.platform}] == WinXP && [mcget {session.windows_info_os.last.updates}] contains SP2 }
21.
Click Finished.
22.
Click Save to complete the configuration.
You use client-side actions to start a particular software state on the client. The Access Policy Manager uses information configured in the client-side actions to install software that configures the system. The systems return to their previous states after the secure access session ends.
Cache and session control check
Loads a cache and session control access policy item that removes all session-specific information from the clients browser after logout or session termination. Cache and session control also allows you to configure session inactivity timeouts, clean up saved form information and passwords, and remove some other information from a Windows system. For details, refer to Setting up cache and session control.
Protected workspace
Protected Workspace configures a temporary Windows user workspace for the secure access session that prevents external access, and deletes any files created before leaving the protected area. For details, refer to Setting up protected workspace.
Windows Group Policy
The Windows group policy action assigns a Windows group policy template to an access policy in a network access session. Once assigned to a successful session, the Windows group policy reconfigures the client systems configuration to conform to the selected policy template. Using Windows group policy templates, you can make configuration changes to client systems that exist for the duration of the network access session. After the network access session is terminated, all Windows group policy changes are rolled back, and the client system reverts to its previous state. For details, refer to Assigning a Windows group policy template.
Use the cache and session control action to provide a higher level of security to systems that are logged on to your network. The cache and session control agent deletes browser cache and other session-related information, and can be configured to clean various settings from the users system after a session is closed.
In an access policy, the cache and session control action is considered successful when the browser add-on starts successfully on the client computer. A failure indicates that the cache and session control action was unable to start.
Note: You can use the cache and session control action to clean cache and related session information from the Internet Explorer browser only. The action does not clear browser cache and session-related items from Firefox, Safari, or any other browser. However, other items you configure in the action are cleaned on all Windows systems.
Note: Cache and Session Control is not compatible with Protected Workspace. You should not use a Protected Workspace action in a session that includes the Cache and Session Control action.
Add a cache and session control action anywhere in the access policy, as long as it is used on a branch for Windows clients.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Cache and Session Control and click Add Item to add the action to the access policy.
The Cache and Session Control action popup screen opens.
For the option Clean forms and passwords autocomplete data option, select Enabled or Disabled.
Enabled removes autocomplete data from web forms, and deletes saved passwords from the system after the user logs out.
For the option Empty Recycle Bin, select Enabled or Disabled. Enabled ensures that the Recycle Bin is emptied on the system after the user logs out.
For the option Force session termination if the browser or Webtop is closed, select Enabled or Disabled.
Enabled forces the session to close when the user closes the web browser or the network access webtop.
For the option Remove dial-up entries used by Network Access client, select Enabled or Disabled.
Enabled removes the VPN connection from the users Network Connections Dial-up Networking folder.
From the Terminate session on user inactivity list, select a setting in minutes or hours to force the session to close if the user is inactive for the specified time.
Select Custom to specify a custom setting, in seconds.
Select Disabled to not terminate the session on user inactivity.
User inactivity is the period of time during which the user has not input any data using the keyboard or mouse on the client system. This is not traffic inactivity over the VPN.
From the Lock workstation on user inactivity list, select a setting in minutes or hours to force the users workstation to lock if the user is inactive for the specified time.
Select Custom to specify a custom setting, in seconds. Select Disabled to not lock the users workstation because of user inactivity.
User inactivity is the period of time during which the user has not input any data using the keyboard or mouse on the client system. This is not traffic inactivity over the VPN.
7.
Click Save to complete the configuration.
In this example, the administrator adds a cache and session control that removes stored passwords and autocomplete data, forces the user to log out if the Webtop or browser is closed, locks the workstation after 5 minutes of inactivity, and closes any session that is inactive after 30 minutes. All other settings are left disabled.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Cache and Session Control, and click Add Item to add the action to the access policy.
The Cache and Session Control action popup screen opens.
For the option Clean forms and passwords autocomplete data, select Enabled.
For the option Force session termination if the browser or Webtop is closed, select Enabled.
From the Terminate session on user inactivity list, select 30 minutes to force the session to close after 30 minutes of inactivity.
From the Lock workstation on user inactivity list, select 5 minutes to lock the users workstation after 5 minutes of inactivity.
7.
Click Save to complete the configuration.
Protected workspace configures a temporary Windows user workspace for the secure access session that prevents external access, and deletes any files created before leaving the protected area. The protected workspace allows you to restrict end users from printing and saving files on a client accessing the Access Policy Manager. Protected workspace reduces the risk of unintentional or accidental information leaks, but does not eliminate it. For example, EXE, DLL, and IME files are not encrypted. It restricts users to a temporary workspace on the remote system, which is newly created at the beginning of each new session. This workspace contains temporary Desktop and My Documents folders. In protected mode, the user cannot unintentionally or accidentally write files to locations outside the temporary folders. The protected workspace control deletes the temporary workspace and all of the folder contents at the end of the session.
Note: Cache and Session Control is not compatible with Protected Workspace. You should not use a Protected Workspace action in a session that includes the Cache and Session Control action.
Note: You cannot assign a Windows group policy template after a session is in the protected workspace. To use Windows group policies with protected workspace, you must place the Windows group policy action before the protected workspace action in the access policy.
Use the protected workspace action to assure that clients who connect to network access are placed in a protected workspace for the duration of the session.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Protected Workspace and click Add Item to add the action to the access policy.
The Protected Workspace action popup screen opens.
Enable or disable the option to Close Google Desktop Search when the user starts the protected workspace session.
Note that selecting Enabled in this option is more secure.
Enable or disable the option to Allow user to temporarily switch from Protected Workspace when the user is in the protected workspace session.
Enable or disable the option to Allow user to use printers.
Select the option for the setting Allow write access to USB flash drives. In addition to the Disabled option and the option to allow write access to All USB flash drives, this setting provides a third option, Only IronKey Secure Flash Drives, which allows a user to write only to specialized, highly secured flash drives created by IronKey, Inc.
Enable or disable the option to Allow user to burn CDs.
7.
If you want to allow protected workspace users to have write access to a specific server, click the Add new entry button and type the name of the server.
To add more servers, repeat this step. To remove a server, click the X button next to the name of the server.
8.
Click Save to complete the configuration.
In this example, the administrator adds protected workspace to an access policy branch. The security policy is very strict, so the only option allowed is for a user to write to an IronKey USB flash drive, and a server called Quarantine.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Protected Workspace and click Add Item to add the action to the access policy.
The Protected Workspace action popup screen opens.
From the Close Google Desktop Search list, select Enabled.
From the Allow user to temporarily switch from Protected Workspace list, select Disabled.
From the Allow user to use printers list, select Disabled.
From the Allow write access to USB flash drives list, select Only IronKey Secure Flash Drives.
From the Allow user to burn CDs list, select Disabled.
7.
Click Add new entry to add a server to which a user can write.
In the box that appears, type Quarantine.
Note that new entries are added above previously configured entries, by default.
8.
Click Save to save the access policy.
The Windows group policy action allows you to assign a Windows group policy, which changes security settings for the Windows client environment for the duration of the network access session.
Note: You cannot assign a Windows group policy template after a session is in the protected workspace. To use Windows group policies with protected workspace, you must place the Windows group policy action before the protected workspace action in the access policy.
Windows group policy templates allow you to configure and assign group policies for Windows machines dynamically per user session in the access policy. Using Windows group policy templates, you can make configuration changes to client systems that exist for the duration of a network access or web applications session. The system applies Windows group policy changes after the Windows group policy check is successful, and before resources are assigned. After the user terminates the session, all Windows group policy changes are rolled back, and the client system reverts to its previous state.
You can use predefined Windows group policy templates with Access Policy Manager. To define your own Windows group policy templates, you must purchase a license for the GPAnywhere product from Full Armor.
Table 9.1 lists the predefined Windows group policy templates included with Access Policy Manager, and their functional descriptions.
Access Policy Manager settings for enabling the users firewall. This policy is used to ensure that the users Microsoft firewall is configured and running.
Based on the Gramm-Leach-Bliley GLBA standard. This policy is used for desktop and laptops to help prevent access to unauthorized information.
Based on the HIPAA (Health Insurance Portability and Accounting Act) standard. This policy is used for desktop and laptops to help prevent access to unauthorized information.
Microsoft Common Usage (high) for desktops and laptops. This policy is used in managed environments and provides high restrictions on user access to devices, configuration, and applications.
Microsoft Common Usage (light) for desktops and laptops. This policy is used in managed environments, and provides light restrictions on user access to devices, configuration, and applications.
Based on the PCI (Payment Card Industry) standard. This policy is used for desktop and laptops to help prevent access to unauthorized information.
Microsoft Specialized Security (Limited Functionality) for desktops and laptops. This is a more focused security policy, with greater restrictions on configuration access.
Terminal Services for client terminal services. This policy is used in environments where the primary use is terminal services.
The Enterprise Client (EC) and Specialized SecurityLimited Functionality (SSLF) templates are based on Microsoft security profiles for Enterprise Client and Specialized SecurityLimited Functionality environments.
Microsoft uses the EC and SSLF environment classifications as the basis for making recommendations on how to configure a variety of server, workstation, and laptop settings. The EC Domain Template is applicable to most enterprise environments. It balances security with usability concerns. The Group Policy settings suggested for users in EC Domain-classified environments focus on addressing the basics at a moderate level, so it is not intrusive to the user.
The SSLF Domain Template is applicable to environments where concerns about security are paramount. In such an environment, some usability is sacrificed in order to further secure the systems. The Group Policy settings suggested for users in SSLF Domain-classified environments expand upon the settings recommended for the EC Domain.
Microsoft common scenarios classify client machines into categories such as mobile, multi-user, app-station, task-station, or kiosk. These scenarios are intended to provide common starting scenarios for group policy management.
The highly- and lightly-managed templates are based on Microsoft Common Scenarios. To standardize the implementation of the scenarios, Microsoft defined the highly-managed and lightly-managed Group Policy settings as the base set of settings on top of which the scenarios would be implemented.
Both the lightly-managed and highly-managed policies are intended for use with devices that work in a centrally managed environment. As such, both templates restrict the options to which a user has access. The distinction between the two is a matter of degree.
In the case of the lightly-managed template, the users retain some ability to customize their desktop environment. Examples of settings that are applied as part of the lightly-managed template are:
In the case of the highly-managed template, the user is given very little leeway to customize the desktop environment. Examples of settings that are applied as part of the highly-managed template are:
The terminal services task station template is specific to terminal server users. It prevents users from reverting back to the default security policy but more importantly, it controls which file types (.exe, .bat, and .msi) can be used. While there are no restrictions on shortcuts (.lnk), restrictions are placed on the actual path of executables.
The firewall settings template enables a users firewall. This policy is used to ensure that the users Microsoft firewall is configured and running. If the Microsoft Windows Firewall is not enabled, group policy starts it.
The final three pre-configured templates help address certain regulatory requirements. They are all based on a basic security policy with their own nuances.
Gramm-Leach-Bliley Act (GLBA), also known as the Financial Services Modernization Act, enabled investment banks to merge with commercial banks and permitted insurance services to merge with securities companies. As part of this act, privacy policies are required to protect sensitive information from security threats. With GLBA, financial institutions must inform consumers, through a privacy notice, how the company collects, stores, shares, and safeguards the data. Compliance with the GLBA is mandatory for any financial services company.
The Health Insurance Portability and Accountability Act (HIPAA) protects people with continued health insurance coverage if they lose or change jobs, and also establishes guidelines for the exchange of patient data, including electronic transmission. There are privacy rules for the use and disclosure of this patient information.
The Payment Card Industry Data Security Standard (PCI DSS) was designed by the major credit card companies as a guideline for any organizations that process credit card transactions. Like GLBA and HIPAA, it establishes procedures for processing, storing, and transmitting sensitive data, and offers some protection against security vulnerabilities that may expose that information. Companies using PCI must also go through an outside audit to validate their compliance. There are 12 requirements within 6 major areas of concern: network security monitoring, network security testing, protecting cardholder data, vulnerability management, access control, and policy maintenance. You can find the specifics of PCI DSS at:
In addition to the preinstalled group policy templates explained above, you can add custom group policy templates, you can download templates installed on the Access Policy Manager, and you can view the configuration of installed templates.
2.
Hover your mouse pointer over Access Profiles, and click the Windows Group Policy link that appears.
The Windows Group Policy List screen opens.
3.
Click Create.
The New Windows Group Policy screen opens.
4.
In the Name box, type a name for the group policy.
5.
In the Description box, type an optional description of the group policy.
This description appears on the Windows Group Policy List screen, in the Description column.
6.
In the Configuration File box, click Browse to locate the file.
Configuration files are created by the FullArmor GPAnywhere product, and are Windows executable files with an EXE extension.
7.
Click Finished when the configuration is complete.
2.
Hover your mouse pointer over Access Profiles, and click the Windows Group Policy link that appears.
The Windows Group Policy List screen opens.
3.
4.
Next to Configuration File, click the Download link.
The web browser pops up a save file dialog.
5.
Click the Save button to save the file.
2.
Hover your mouse pointer over Access Profiles, and click the Windows Group Policy link that appears.
The Windows Group Policy List screen opens.
3.
4.
Next to Configuration Details, click the View link.
The web browser pops up a save file dialog.
Use the Windows group policy action to assure that clients who connect to network access have their computers configured to conform to the security policy required for the duration of the session.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Windows group policy and click Add Item to add the action to the access policy.
The Windows group policy action popup screen opens.
6.
From the Windows group policy list, select the group policy to apply to client computers.
You can add your own group policy templates that you create with the FullArmor GPAnywhere add-on. For more information on group policy templates, see Understanding Windows group policy templates.
7.
Click Save to complete the configuration.
In this example, the administrator adds the predefined Gramm-Leach-Bliley Act (GLBA) Windows group policy template to clients that connect through this branch on the access policy. The Gramm-Leach-Bliley Act requires financial institutions to inform consumers, through a privacy notice, how the company collects, stores, shares, and safeguards the data. GLBA is mandatory for any financial services company.
Note: This is not a complete example. For the example to work, you must assign an Allow ending to successful branches. You can assign a network access or web applications resource using the resource assign action, along with associated webtops. For a web application access management connection, you need not assign resources. This example is configured starting with an empty access policy.
1.
On the Main tab of the navigation pane, expand Access Policy, then click Access Profiles.
The Access Profiles List screen opens.
2.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Select Windows Group Policy and click Add Item to add the action to the access policy.
The Windows group policy action popup screen opens.
7.
Click Save to save the access policy.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)