Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Server Side Checks
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

10 
Introducing server-side checks
In addition to client-side checks, the BIG-IP® Secure Access 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 UI mode check presents a query to find out what type of client is connecting, and routes the client to the different policy branches (for full browser clients, standalone clients, or neither) based on the results of the query.
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 an 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 check the 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:
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.
5.
Select Client OS and click Add Item to add the action to the access policy.
The Client OS action popup screen opens.
6.
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 add the client OS check to an access policy, and only the Windows 7, Windows Vista, and Windows XP 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 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 Client OS and click Add Item to add the action to the access policy.
The Client OS action popup screen opens.
6.
Click Save.
7.
On the Windows 7, Windows XP and Windows Vista 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 10.1.
8.
To activate the access policy, click the Apply Access Policy link at the top of the visual policy editor screen.
You can use the UI mode 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 UI mode check includes three branches:
A Full Browser branch, which indicates that the user is connecting with a Windows web browser or with the standalone client in web browser mode.
A Standalone Client branch, which indicates that the user is connecting with the standalone client, and not in full browser mode.
A Fallback branch, which indicates that the user is connecting with another method.
We recommend that you use the UI mode check as one of the first checks in your access policy. You can then configure the Full Browser branch with all of the checks that you require for your fully 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.
5.
Select UI Mode and click Add Item to add the action to the access policy.
The UI Mode action popup screen opens.
6.
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 add a UI mode check, then add a cache and session control endpoint security check to the Full Browser 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 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 UI Mode and click Add Item to add the action to the access policy.
The UI Mode action popup screen opens.
6.
Click Save.
7.
On the Full Browser branch following the UI Mode action, click the plus sign ().
The Add Item popup screen opens.
9.
Select Cache and Session Control and click Add Item.
The cache and session control action popup screen opens.
10.
Click Save.
11.
On the Standalone Client branch following the UI mode action, and the Successful branch following the cache and session control action, configure Allow endings.
12.
Configure logon denied endings for all other branches.
To configure endings, see Configuring access policy endings.
The completed policy appears as shown in Figure 10.2.
13.
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-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.
5.
Select Client-Side Check Capability and click Add Item to add the action to the access policy.
The Client-Side Check Capability action popup screen opens.
6.
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.
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 Client-Side Check Capability and click Add Item to add the action to the access policy.
The Client-Side Check Capability action popup screen opens.
6.
Click Save.
7.
On the Full branch following the Client-Side Check Capability action, click the plus sign ().
The Add Item popup screen opens.
9.
Select Antivirus check and click Add Item.
The antivirus check action popup screen opens.
10.
Click Save.
11.
On the Successful branch following the Antivirus action, configure an Allow ending.
12.
Configure logon denied endings for all other branches.
To configure endings, see Configuring access policy endings.
The completed policy appears as shown in Figure 10.3.
13.
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.
5.
Select landing URI and click Add Item to add the action to the access policy.
The Landing URI action popup screen opens.
6.
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, your 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 web applications resource for Outlook Web Access with this 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.
5.
Select Landing URI and click Add Item to add the action to the access policy.
The Landing URI action popup screen opens.
6.
In the Name box, type OWA.
7.
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.
8.
Next to Expression: Landing URI is /uri1, click the change link.
The expression builder popup screen opens.
9.
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.
10.
Click Save.
11.
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)