Applies To:

Show Versions Show Versions

Manual Chapter: Understanding Access Policies
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

In an access policy, you define the criteria for granting access to various servers, applications, and other resources on your network.
Using an access policy, you can define a sequence of checks to enforce the required level of security on a users system, before the user is granted access to servers, applications, and other resources on your network.
An access policy can also include authentication checks, to authenticate a user before the user is granted access to the network resources.
Collect information about the client system
You can use the access policy to collect and evaluate information about client computers. For example, you can check that the user is operating from a company-issued computer, what antivirus software is present on the machine, what operating system the computer is running, and other aspects of the client configuration. This is accomplished using both client-side checks and server-side checks in the access policy.
Use the authentication action to verify client security against external authentication servers
The access policy allows you to check and evaluate authentication against an external authentication database or a certificate, to make sure the client system recognizes the user.
Retrieve users rights and attributes
You can use the access policy to retrieve extended information from authentication servers including LDAP or Microsoft Active Directory® attributes, and use the information retrieved to assign different resources.
Grant access to resources
With the access policy, you assign a network access resource after the client is authenticated.
Every access policy begins at a start point. In the visual policy editor, this is a green rectangle with an angled right side, labeled Start, that has one fallback branch connected to it. You build the access policy starting on this fallback branch.
An action performs a specific function in an access policy. These functions include client checks, authentication checks, and other access policy functions.
In the visual policy editor, the action appears as a rectangle surrounded by a single line in the access policy, with one branch entering it on the left, and one or more branches exiting on the right. If the action requires configuration, a red asterisk appears to the left of the action, and the name of the action appears in italics. In Figure 6.2, the RADIUS action is properly configured, and the resource assign action requires configuration.
The Access Policy Manager includes a number of pre-defined actions. You can see the available actions in the visual policy editor when you click the Add Item button , which is activated by positioning the cursor along the actions rule branch. The Add Item popup screen opens as a floating popup screen on top of the visual policy editor.
Table 6.1 lists all the actions available in Access Policy Manager, in the order in which they appear in the Add Item popup screen, and describes what they can do.
Adds a logon page to the access policy. You can customize the messages and link text on the logon page, and create custom messages for different languages.
Adds an external logon page to the access policy. Used with an external logon server like CSEs SECUREMATRIX®.
Assigns ACLs, a network access or web applications resource, and a webtop to the access policy.
If the Client SSL profile is configured to request the client certificate during the SSL handshake, checks the client certificate received during the SSL handshake.
Authentication (continued)
Checks for antivirus software on the client computer. Can check for antivirus software on Windows, Mac OS, and Linux clients.
Checks for firewall software on the client computer. Can check for firewall software on Windows, Mac OS, and Linux clients.
Checks for a specific file on the client computer. File check is available as three different actions for Windows, Mac OS, and Linux computers.
Checks for running processes on the client computer. Process check is available as three different actions for Windows, Mac OS, and Linux computers.
Cleans and removes browser cache, and optionally cleans form entries, passwords, dial-up entries, and sets timeouts for the access policy.
Provides a secure computing environment with a temporary desktop and profile that is removed after logout.. For use with public computers or in other situations where higher security is required.
Temporarily configures the Windows environment with a group policy. Windows Group Policy is an optional add-on that is enabled by FullArmors GPAnywhere product.
Detects the browser of client type the client is using. This provides three rule branches in your access policy:
Full Browser
The rule branch the access policy takes if the client is using a web browser, or the BIG-IP® Edge Client®.
Standalone Client
The rule branch the access policy takes if the client is using a standalone legacy SSL VPN client. This rule branch is used only if the standalone client is running in Legacy Mode. If the BIG-IP Edge Client is used, the Full Browser rule branch is matched.
Fallback
The rule branch the access policy takes if the client is not using one of the listed clients.
Checks whether the client supports JavaScript and supports either ActiveX controls or Netscape plug-ins. If a client can support JavaScript and one of these control types, it can run client-side checks. See Preparing for clients that cannot use client checks.
Detects the operating system of the remote client. Access Policy Manager detects this using information from the HTTP header.
A branch rule evaluates the result of an access policy action, findings about a client system, or other access policy item. The outcome of the evaluation of a branch rule grants or denies access, or continues on to the next action. The order of branch rules in an access policy determines the flow of action.
In an access policy, you use actions for which a set of branch rules are already defined. You can add branch rules to an action, or create new branch rules to test for a specific condition. You can use empty actions to create custom actions, and add your own branch rules to them. The ending is the last branch rule applied. Figure 6.3, shows the flow of a branch rule-checking operation.
By default, if the users system does not meet the access policy requirements, the Access Policy Manager® denies the user access. You can change this outcome by changing the access policy ending, and by modifying branch rules to check for different criteria.
When you create a new action, the visual policy editor automatically creates a set of branch rules. The last rule in this set is the fallback branch rule. It cannot be moved. It governs all cases that do not satisfy a preceding branch rule.
Figure 6.3 shows the internal process of an action.
To view a predefined branch rule, you must first add an action to the access policy. The following example describes how to add a predefined action (client cert result) to an access policy, then how to view the underlying rule.
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.
If the Authentication category is not expanded, click the plus sign [] to expand it.
5.
Select Client Cert Inspection and click Add Item to add the action to the access policy.
The Client Cert Result action popup screen opens.
6.
Click the Branch Rules tab.
Under the Name Successful, you see the text
Expression: Client Certificate is valid, and then a link to change the expression.
7.
Click change.
The Expression popup screen opens.
8.
Click the Advanced tab.
When you configure an action, it creates a predefined rule. To further refine or customize a rule, you can use the expression builder to build a rule from a list of agents and conditions.
You can edit a rule on the Rules tab by clicking change. You can edit rules in a rule builder on the Simple tab. You use this rule builder to choose from a simplified set of rules and automatically compile the Tcl syntax. You can also use the Advanced tab to edit the rule directly, using Tcl. Visual examples of the two editing methods are shown in Figure 6.5.
In the visual policy editor, you connect access policy items to other items with branches. A branch represents one of following three things:
The result of the evaluation of an access policy rule
Most actions have branches that represent the evaluation of rules. These branches might be called Successful, or they might have a more descriptive name. In many cases, a rule branch is a positive result to the evaluation of an action (for example, Active Directory authentication has passed). A rule branch can also be an informational response to the evaluation of an action (for example, client operating system is Windows Vista®).
An outgoing terminal from an access policy macro
When you configure an access policy macro, the rule branches inside the access policy macro have endings called terminals. These terminals do not function like access policy endings, but instead, become branches in the access policy to which the macrocall is added, which represent the outcomes of actions inside the macrocall.
A fallback rule
A fallback rule is typically a negative response, if the action has successful branches. Some fallback rules are the result of the action returning no match or a failure for the access policy check. Fallback rules are also the result of actions that have no positive or negative result. For example, the logon page action has no positive or negative result, because it sends only a logon page to the client, so the result branch of a logon page is always a fallback rule branch.
A macro is a collection of actions that you can configure to provide common access policy functions. You can create a macro for any action or series of actions in an access policy. You can also create macros that contain macrocalls to other macros (nested macros).
After you create a macro, you place it in the access policy by adding an item called a macrocall to your policy. A macrocall is an action that performs the functions defined in a macro. In the visual policy editor, a macrocall appears in an access policy, or in a macro definition, as a single rectangular item, surrounded by a double line, with one or more outgoing macro terminal branches, called terminals, as shown in Figure 6.7
Macro definitions, macro terminals, and macrocalls are defined for each access policy. Macros you create in one policy do not appear, and cannot be used, in another access policy.
Unlike other access policy actions, when you click a macrocall in the access policy, the macro definition is displayed below the access policy in the macros section, and not in a popup screen, as shown in Figure 6.8.
The BIG-IP® Access Policy Manager® includes several predefined macro templates. For example, BIG-IP Access Policy Manager includes macro templates for six authentication methods, and for a Windows antivirus and firewall check. For the definitions and configuration information for these included macro templates, see Configuring macros.
A macro does not have endings, as does an access policy. Instead, a macro contains one or more end points called terminals. Terminals are the macro branches that are the result of the actions you add to the macro. The access policy uses the macro terminals after you insert a macrocall into an access policy. A macro can have many terminals. You can use terminals as you use access policy endings within the macro configuration.
Macro terminals are common shared endpoints for the access policy macro item. After you add a macro to the access policy using a macrocall, each macro terminal defined in the macro appears as a separate shared output. For example, if you configure four macro terminals, and use those terminals ten times in the macro definition, when you add the macrocall access policy item to the access policy, only four outputs appear from the access policy item. For an example of a macro with multiple terminals used many times in the configuration, see Using the client classification and prelogon checks macro template.
To make macros easier to use, you can assign the macro terminals descriptive names and specific colors with the visual policy editor. When you add a macro to your access policy, the terminals from the macro become branches, and the branches take the names of their terminals.
After you add the macrocall to your access policy, the macrocall appears as a single access policy item, with four terminals that appear as four branches, named for the terminals. See Figure 6.9.
Note: You can make changes to the actions in a macro after you have added the macrocall to an access policy. However, you cannot delete terminals after a macrocall has been added to an access policy or another macro. For this reason, we recommend that you configure macro terminals before you add a macrocall to the access policy.
Access policy endings indicate the final outcome of a branch of the access policy. The Access Policy Manager provides the following endings: Allowed, Deny, and Redirect. In the visual policy editor, endings appear as a rectangle with a cut-out left edge.
In an access policy, the allow ending is a successful ending that allows the connection defined by the access policy branch. Configure your access policies so that only users who meet your security criteria reach an allow ending. The allow ending performs final validation of assigned resources, the webtop, and any resources added to the access policy branch, and allows the session to start.
Note: You must assign a valid network access or web application resource and a webtop for your users, unless you are using the access policy to control access to a local traffic virtual server, in a web application access management scenario.
In an access policy, the deny ending denies the user access to the resource, and ends the users session. After the user reaches a deny ending, all the session information collected during access policy operation is deleted from the client. You can use this ending at the ends of failed rule branches. When a user reaches a deny ending, the user sees an access denied error message web page.
In an access policy, the redirect ending sends the user to a URL that you specify. Use this ending when the result of a certain access policy outcome does not result in a webtop ending, but you want to send the user to another internal or external URL. For example, you might send a user to the web site for an antivirus vendor, if an antivirus action determines that the users virus definitions are older than the access policy allows.
The rules in access policies use the values that the actions return in session variables. During access policy operation, the Access Policy Manager collects various information about the system that is attempting access. This information is organized in a hierarchical arrangement and is stored as the users session data.
Session variables are variables that allow the access policy to access users session data. The name of a session variable consists of multiple hierarchical nodes separated by periods (.).
session.ad.<username>.queryresult = query result (0 = failed, 1=passed)
session.ad.<username>.authresult = authentication result (0 = failed, 1=passed)
session.ad.<username>.attr.<attr_name> = the name of an attribute retrieved during the Active Directory query. Each retrieved attribute is converted to a separate session variable. Note that attributes assigned to a user on the AAA server are specific to that server, and not to Access Policy Manager.
Figure 6.11 shows how Access Policy Manager names session variables.
You can use session variables to customize access rules or to define your own access policy rules. You can assign users specific resources based on session variables, using the resource assign action.
You can use session variables to configure rules in access policies. You can use the values of session variables to provide different outcomes for policies. For more information on how to use session variables, see Assigning variables, and Using advanced access policy rules. For a complete listing of available session variables, see Appendix C, Session Variables. You can view all session variables for a session at Reports > Current Sessions. Click a session name to view the session variables for the session.
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)