Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Endpoint Security Server-Side
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

In addition to client-side checks, the BIG-IP® Access Policy Manager® provides server-side checks. When the access policy is processed, server-side checks allow the server to check clients and make policy decisions based on information that a client presents to the server. For example, the client type check presents a query to find out what type of client is connecting, and routes the client to the different policy branches based on the results of the query.
For a complete list and brief descriptions of endpoint security (server-side) checks, see Understanding available actions. The basic process for adding an action to an access policy is the same for each action. Properties and branch rules differ from action to action.
The administrator can configure an access policy to provide access for non-Windows clients, or clients that do not have the ability to install browser add-ons. To do this, the administrator adds a client-side check capability action at the start of the access policy, and then adds the client-side checks only on the Full access policy branch.
The landing URI action checks the landing URI the client entered to reach the access policy. The landing URI is the actual landing address after the domain name; for example, for a Microsoft Outlook Web Access connection at http://www.siterequest.com/owa, the landing URI is /owa. The landing URI action provides a separate rule branch for each configured URI, and a fallback branch is provided for URIs that do not conform. For details, refer to Checking a landing URI with the landing URI check.
The client OS check allows you to verify which operating system the client is using. The default client OS check includes eight rule branches. Seven of these rule branches correspond to the operating systems specified in the name of the rule. If, while running the access policy, Access Policy Manager® detects the operating system on the client as one of the specified operating systems, the access policy uses that rule branch. The access policy uses the fallback rule branch when it detects any other operating system. These are the operating system rule branches:
Windows® (includes Windows version 7 and 8, Windows Server® 2008, Windows Vista®, Windows Server 2003, Windows XP, Windows 2000, and Windows NT)
Windows RT
Note: The Windows RT branch is available only when you have the appropriate Access Policy Manager 11.4.x hotfix installed. To determine hotfix requirements, refer to the BIG-IP APM Client Compatibility Matrix for APM 11.4.0 or APM 11.4.1 on the AskF5 web site at http://support.f5.com.
We recommend that you use the client OS check at the beginning of an access policy, so you can build access policies using the separate operating system branches for functionality specific to those operating systems.
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.
4.
On the Endpoint Security (Server-Side) tab, select Client OS and click Add Item to add the action to the access policy.
The Client OS action popup screen opens.
5.
Click Save to complete the configuration.
6.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
In this example, you add the client OS check to an access policy, and only the Windows, MacOS, iOS, and Android branches are assigned allowed endings.
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, portal access, app tunnel, or remote desktop resource using one of the resource assign actions, along with an associated network access, portal access, or full webtop. For a web 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.
4.
On the Endpoint Security (Server-Side) tab, select Client OS and click Add Item to add the action to the access policy.
The Client OS action popup screen opens.
5.
Click Save.
6.
On the Windows, MacOS, iOS, and Android branches following the client OS action, configure allowed endings. Configure logon denied endings for all other branches.
To configure endings, see Configuring access policy endings.

The completed policy appears as shown in Figure 8.1.
7.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
Note: The Windows RT branch shown in Figure 8.1 is available only when you have the appropriate Access Policy Manager® 11.4.x hotfix installed. To determine hotfix requirements, refer to the BIG-IP APM Client Compatibility Matrix for APM 11.4.0 or APM 11.4.1 on the AskF5 web site at http://support.f5.com.
You can use the client type check to determine whether the client is using a full browser, the standalone client, or another client to access the Access Policy Manager®. The default Client Type check includes six branches:
An Edge Portal® branch, which indicates that the user is connecting with the Edge Portal mobile app.
An Edge Client® branch, which indicates that the user is connecting with the BIG-IP® Edge Client or BIG-IP Edge Client app, supported on multiple devices and operating systems.
A Citrix Receiver branch, which indicates that the user is connecting using a later Citrix receiver.
A Citrix Receiver (legacy) branch, which indicates that the user is connecting using an earlier Citrix receiver.
A VMware View branch, which indicates that the user is connecting using a VMware View client.
A Full or Mobile Browser branch, which indicates that the user is connecting with a Windows web browser or a mobile browser.
A Windows® Built-in Client branch, which indicates that the user is connecting from a Windows client using the Inbox F5® VPN Client.
Note: This branch is available only when the appropriate Access Policy Manager version 11.4.x hotfix is installed. To determine hotfix requirements, refer to the BIG-IP APM® Client Compatibility Matrix for APM 11.4.0 or APM 11.4.1 on the AskF5 web site at http://support.f5.com.
A fallback branch, which indicates that the user is connecting with another method.
We recommend that you use the client type check as one of the first checks in your access policy. You can then configure the Edge Client® branch with all of the checks that you require for fully capable clients, while also providing access policy branches for other clients. You can also provide different resources or simpler checks for mobile clients using the Edge Portal® app, and make other choices based on the client type response.
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.
4.
On the Endpoint Security (Server-Side) tab, select Client Type and click Add Item to add the action to the access policy.
The Client Type action popup screen opens.
5.
Click Save to complete the configuration.
6.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
In this example, you add a client type check, add a Windows cache and session control endpoint security check to the full browser branch, and change endings to allow for all non-fallback branches.
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, portal access, app tunnel, or remote desktop resource using one of the resource assign actions, along with an associated network access, portal access, or full webtop. For a web 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.
4.
On the Endpoint Security (Server-Side) tab, select Client Type and click Add Item to add the action to the access policy.
The Client Type action popup screen opens.
5.
Click Save.
6.
On the Full Browser branch following the Client Type action, click the plus sign ().
The Add Item popup screen opens.
7.
On the Endpoint Security (Server-Side) tab, select Windows Cache and Session Control and click Add Item.
The cache and session control action popup screen opens.
8.
Click Save.
10.
Configure logon denied endings for all other branches.
To configure endings, see Configuring access policy endings.
The completed policy appears as shown in Figure 8.2.
11.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
Note: The Windows Built-in Client branch shown in Figure 8.2 is available only when you have the appropriate Access Policy Manager® version 11.4.x hotfix installed. To determine hotfix requirements, refer to the BIG-IP APM Client Compatibility Matrix for APM 11.4.0 or APM 11.4.1 on the AskF5 web site at http://support.f5.com.
You can use the client-side check capability action to determine whether the client has the ability to run client-side checks. The default endpoint check capability action includes two branches:
A Full branch, which indicates that the user is connecting with a client that has full client-side check support.
A Fallback branch, which indicates that the user is connecting with a client that does not fully support client-side checks.
We recommend that you use the client-side check capability action as one of the first checks in your access policy. You can then configure the Full branch with all of the endpoint security checks that you require for your endpoint-security capable clients, while also providing access policy branches for other 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.
4.
On the Endpoint Security (Server-Side) tab, select Client-Side Capability and click Add Item to add the action to the access policy.
The Client-Side Capability action popup screen opens.
5.
Click Save to complete the configuration.
6.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
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, portal access, app tunnel, or remote desktop resource using one of the resource assign actions, along with an associated network access, portal access, or full webtop. For web 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.
4.
On the Endpoint Security (Server-Side) tab, select Client-Side Capability and click Add Item to add the action to the access policy.
The Client-Side Capability action popup screen opens.
5.
Click Save.
6.
On the Full branch following the Client-Side Capability action, click the plus sign ().
The Add Item popup screen opens.
7.
On the Endpoint Security (Client-Side) tab, select Antivirus and click Add Item.
The antivirus action popup screen opens.
8.
Click Save.
9.
On the Successful branch following the antivirus action, configure an Allow ending.
10.
Configure logon denied endings for all other branches.
To configure endings, see Configuring access policy endings.
The completed policy appears as shown in Figure 8.3.
11.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
You can use the Landing URI check to check the landing URI with which the user has accessed the access policy. The default Landing URI check includes two branches:
A Landing URI branch, which indicates the landing URI for which the policy should check, and evaluates as true if the specified landing URI is reached.
A Fallback branch, which indicates that the user is connecting with a different landing URI.
We recommend that you use the landing URI check to determine the landing URI that the user typed to connect to the Access Policy Manager®.
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.
4.
On the Endpoint Security (Server-Side) tab, select Landing URI and click Add Item to add the action to the access policy.
The Landing URI action popup screen opens.
5.
Click Save to complete the configuration.
6.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
In this example, your Microsoft Outlook Web Access address is http://www.siterequest.com/owa. You add a landing URI check that checks for the landing URI /owa, the typical landing URI for an Outlook Web Access connection. If the access policy finds this URI, you can then add a resource assign action on the successful policy branch. In this example, you add a resource assign action after the landing URI check for the URI /owa. For a complete working scenario, assign a portal access resource for Outlook Web Access with this resource assign action.
Note: This example does not detail how to create and assign portal access resources. For detailed instructions, see the BIG-IP® Access Policy Manager® Portal Access Guide, and Assigning resources.
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.
4.
On the Endpoint Security (Server-Side) tab, select Landing URI and click Add Item to add the action to the access policy.
The Landing URI action popup screen opens.
5.
In the Name box, type OWA.
6.
Click the Rules tab.
The Rules for the action popup screen are displayed. The predefined rule for this action is Expression: Landing URI is /uri1.
7.
Next to Expression: Landing URI is /uri1, click the change link.
The expression builder popup screen opens.
8.
In the Landing URI is box, type /owa.
On the OWA branch, add a resource assign action and configure it for Outlook Web Access, if you have an Outlook Web Access server and resources.
To configure the web application, see the BIG-IP® Access Policy Manager® Portal Access Guide.
9.
Click Save.
10.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
You can use the client for MS Exchange check to determine if a client is using Microsoft Exchange or ActiveSync protocols. The default client for MS Exchange check includes two branches:
A Client for MS Exchange branch.
A Fallback branch, which indicates that the user is not using MS Exchange or ActiveSync.
A client for MS Exchange is not a typical web browser, and Access Policy Manager® has the following restrictions on MS Exchange access policy branches.
The MS Exchange client branch cannot provide responses that require additional user input, except for the logon page.
You must assign a logon page action to the access policy. The logon page action will automatically works in clientless mode.
MS Exchange devices support only the following actions, and you should not use other actions on a client for MS Exchange branch:
We recommend that you use the MS Exchange check to determine when a user is connecting with an Exchange or ActiveSync client.
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.
4.
On the Endpoint Security (Server-Side) tab, select Client for MS Exchange and click Add Item to add the action to the access policy.
The Client for MS Exchange action popup screen opens.
5.
Click Save to complete the configuration.
6.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
In this example, for a complete working scenario, assign a portal access resource for Outlook Web Access with this resource assign action. Note that you must also add an Exchange profile to the access profile.
Note: This example does not detail how to create and assign portal access resources. For detailed instructions, see the BIG-IP® Access Policy Manager® Portal Access Guide, and Assigning resources.
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.
4.
Select Client for MS Exchange and click Add Item to add the action to the access policy.
The Client for MS Exchange action popup screen opens.
5.
Click Save.
7.
Select Advanced Resource Assign and click Add.
8.
Click Add new entry
9.
Under Expression: empty click Add/Delete.
You must predefine an Outlook Web Access portal access resource to select. You can create one manually or use the Portal Access wizard.
12.
Click Save.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
You can use the IP Geolocation match access policy item to make policy decisions based on geolocation by client IP address.
The IP geolocation match access policy item checks the client IP address against the geolocation database to determine the clients physical location. The available conditions are:
IP Geolocation Continent code is: Specifies that the users IP address must match the specified continent code.
IP Geolocation Country code is: Specifies that the users IP address must match the specified country code.
IP Geolocation Country name is: Specifies that the users IP address must match the specified country name.
IP Geolocation State/Region is: Specifies that the users IP address must match the specified region or state.
If the geolocation information determined from the IP address does not match the specified conditions, the access policy sends the user to the fallback branch.
We recommend that you use the IP geolocation match check to determine a users physical location and make appropriate policy decisions based on that information.
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.
4.
On the Endpoint Security (Server-Side) tab, select IP Geolocation Match and click Add Item to add the action to the access policy.
The IP Geolocation Match action popup screen opens.
The default setting for the IP geolocation match access policy item is to check that the country code for the IP address is US.
6.
After you make changes, click Save to complete the configuration.
7.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
In this example, you check that the IP address geolocation is for the United States and for the state of Texas, and assign resources to the successful branch. The fallback branch gets assigned a deny ending. For a complete working scenario, assign resources with the resource assign action.
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.
4.
On the Endpoint Security (Server-Side) tab, select IP Geolocation Match and click Add Item to add the action to the access policy.
The IP Geolocation Match action popup screen opens.
5.
Click the Branch Rules tab.
The Branch Rules screen opens.
6.
In the Name field type US-Texas.
7.
Next to Expression: Country code: US, click the change link.
8.
Next to AND, click the Add Expression button.
The Add Expression screen opens.
9.
From the Agent Sel list, select IP Geolocation Match.
10.
From the Condition list, select IP Geolocation State/Region is.
11.
In the State/Region field, type Texas.
12.
Click Add Expression.
13.
Click Finished.
14.
Click Save.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
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)