F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP APM
  4. Configuration Guide for BIG-IP Access Policy Manager
  5. Configuring Endpoint Security Server-Side
Manual Chapter : Configuring Endpoint Security Server-Side

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 11.4.1, 11.4.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>
8 
 
Configuring Endpoint Security (Server-Side)
Introducing endpoint security (server-side) checks
Configuring client OS check
Configuring cliweb site at ent type check
Checking for client-side check capability
Checking a landing URI with the landing URI check
Identifying Microsoft Exchange clients with the client for MS Exchange check
Using IP Geolocation in an access policy
Introducing endpoint security (server-side) checks
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.
Preparing for clients that cannot use client checks
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.
Checking the landing URI of a client
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.
Configuring client OS 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.
Linux
Mac OS
iOS
Android
Setting up the client OS check
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.
To add a client OS 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Example: Using client OS check
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.
To add the example client OS check 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Figure 8.1 Client OS access policy example
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.
Configuring cliweb site at ent type check
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.
Setting up the client type access policy item
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.
To add a client type 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Example: Using client type check
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.
To add the example client type check 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
9.
On all branches except for the fallback branches, configure Allow endings.
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.
Figure 8.2 Client Type access policy example
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.
Checking for client-side check capability
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.
Setting up the client-side check capability access policy item
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.
To add a client-side check capability 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Example: Using client-side check capability action
In this example, you add a client-side check capability action, then add an antivirus client-side check to the Full branch.
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.
To add the example client-side check capability 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Figure 8.3 Client-side check capability access policy example
Checking a landing URI with the landing URI check
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.
Setting up the landing URI access policy item
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®.
To add a landing URI 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Example: Using landing URI check
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.
To add the example Landing URI check 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
To assign the resource, see Assigning resources.
The completed policy appears as shown in Figure 8.4.
9.
Click Save.
10.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
Figure 8.4 Landing URI access policy example
Identifying Microsoft Exchange clients with the client for MS Exchange check
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.
The client for MS Exchange check requires that you also add an Exchange profile to the access profile.
Understanding Microsoft Exchange connections
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.
Authentication retries are not attempted.
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:
Active Directory Authentication
Active Directory Query
Client Certificate Inspection
HTTP Authentication
LDAP Authentication
LDAP Query
NTLM Authentication
RADIUS Authentication
RADIUS Accounting
RSA SecurID Authentication
Client-Side Capability
Client OS
Landing URI
IP Geolocation Match
The following actions are not supported on MS Exchange clients:
On-Demand Certificate Authentication
any client side check
Setting up the MS Exchange check policy item
We recommend that you use the MS Exchange check to determine when a user is connecting with an Exchange or ActiveSync client.
To add a client for MS Exchange check
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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
Example: Using client for MS Exchange check
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.
To add the Client for MS Exchange check
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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
6.
On the Client for MS Exchange branch, click the plus sign () to add an action.
7.
Select Advanced Resource Assign and click Add.
The Advanced Resource Assign action popup screen opens.
8.
Click Add new entry
9.
Under Expression: empty click Add/Delete.
10.
Select Portal Access Resources from the menu tabs and select an Outlook Web Access resource.
You must predefine an Outlook Web Access portal access resource to select. You can create one manually or use the Portal Access wizard.
11.
Select Webtop from the menu tabs and select a portal access or full webtop.
You must predefine a portal access resource access or full webtop to select.
12.
Click Save.
The completed policy appears as shown in Figure 8.5.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
Figure 8.5 Client for MS Exchange access policy example
Using IP Geolocation in an access policy
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.
Setting up the IP geolocation match access policy item
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.
To add an IP geolocation match check
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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
5.
To make changes to the IP Geolocation Match settings, click the Branch Rules tab.
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.
Example: Using IP geolocation
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.
Note: This example does not detail how to create and assign resources. For detailed instructions, see Assigning resources.
To add the example IP geolocation match 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.
3.
On a branch of the access policy, click the plus sign () to add an action.
The Add Item popup screen opens.
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.
15.
On the US-Texas branch, add a resource assign action and configure it for the policy assignment.
The completed policy appears as shown in Figure 8.6.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
Figure 8.6 IP geolocation match example action
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information