Lab 2: Visual Policy Editor (VPE) Overview

Setup Lab Environment

To access your dedicated student lab environment, you will require a web browser and Remote Desktop Protocol (RDP) client software. The web browser will be used to access the Lab Training Portal. The RDP client will be used to connect to the Jump Host, where you will be able to access the BIG-IP management interfaces (HTTPS, SSH).

1. Click DEPLOYMENT located on the top left corner to display the environment

2. Click ACCESS next to jumpohost.f5lab.local

   

3. Select your RDP resolution.

4. The RDP client on your local host establishes a RDP connection to the Jump Host.

5. Login with the following credentials:

   • User: f5lab\user1
   • Password: user1

6. After successful logon the Chrome browser will auto launch opening the site https://portal.f5lab.local. This process usually takes 30 seconds after logon.

7. Click the Classes tab at the top of the page.

   

8. Scroll down the page until you see 101 Intro to Access Foundational Concepts on the left

   

9. Hover over tile Visual Policy Editor (VPE) Overview. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

   

10. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded. If you experience errors try running the automation a second time or open an issue on the Access Labs Repo.

    

Section 1 - The Access Profile

1. From a browser navigate to https://bigip1.f5lab.local

2. Login with username admin and password admin

   

3. Navigate to Access >> Profiles/Policies >> Access Profiles (Per-Session Policies).

   

4. The Status flag indicates if there are changed pending to the policy. When the flag is yellow there are changes pending to the policy. We will interact with Pending Changes later in the lab.

   

5. Click server1-psp

   

6. The Properties section provides baseline settings related to Scope, timers, and languages across the all sessions that will use the policy regardless of how Visual Policy Editor is configured.

   

   Setting	Value	Description and defaults
   Name	text	Specifies the name of the access profile.
   Inactivity Timeout	Number of seconds, or 0	Specifies the inactivity timeout for the connection. If there is no activity between the client and server within the specified threshold time, the system closes the current session. By default, the threshold is 0, which specifies that as long as a connection is established, the inactivity timeout is inactive. However, if an inactivity timeout value is set, when server traffic exceeds the specified threshold, the inactivity timeout is reset.
   Access Policy Timeout	Number of seconds, or 0	Designed to keep malicious users from creating a denial-of-service (DoS) attack on your server. The timeout requires that a user, who has followed through on a redirect, must reach the webtop before the timeout expires. The default value is 300 seconds.
   Maximum Session Timeout	Number of seconds, or 0	The maximum lifetime is from the time a session is created, to when the session terminates. By default, it is set to 0, which means no limit. When you configure a maximum session timeout setting other than 0, there is no way to extend the session lifetime, and the user must log out and then log back in to the server when the session expires.
   Max Concurrent Users	Number of users, or 0	The number of sessions allowed at one time for this access profile. The default value is 0 which specifies unlimited sessions.
   Max Sessions Per User	Number between 1 and 1000, or 0	Specifies the number of sessions for one user that can be active concurrently. The default value is 0, which specifies unlimited sessions. You can set a limit from 1-1000. Values higher than 1000 cause the access profile to fail.
   Max In Progress Sessions Per Client IP	Number 0 or greater	Specifies the maximum number of sessions that can be in progress for a client IP address. When setting this value, take into account whether users will come from a NAT-ed or proxied client address and, if so, consider increasing the value accordingly. The default value is 0 which represents unlimited sessions.
   Restrict to Single Client IP	Selected or cleared	When selected, limits a session to a single IP address.
   Logout URI Include	One or more URIs	Specifies a list of URIs to include in the access profile to initiate session logout.
   Logout URI Timeout	Logout delay URI in seconds	Specifies the time delay before the logout occurs, using the logout URIs defined in the logout URI include list.

7. Click SSO/Auth Domains

   

   Setting	Value	Description and defaults
   Domain Mode	Single Domain or Multiple Domains	Select Single Domain to apply your SSO configuration to a single domain. Select Multiple Domain to apply your SSO configuration across multiple domains. This is useful in cases where you want to allow your users a single Access Policy Manager® (APM®) login session and apply it across multiple Local Traffic Manager™ or APM virtual servers, front-ending different domains.
   Domain Cookie	A Domain Cookie	If you specify a domain cookie, then the line domain=specified_domain is added to the MRHsession cookie.
   Cookie Options: Secure	Enable or disable check box	Enabled, this setting specifies to add the secure keyword to the session cookie. If you are configuring an application access control scenario where you are using an HTTPS virtual server to authenticate the user, and then sending the user to an existing HTTP virtual server to use applications, clear this check box.
   Cookie Options: Persistent	Enable or disable check box	Enabled, this setting specifies to set cookies if the session does not have a webtop. When the session is first established, session cookies are not marked as persistent, but when the first response is sent to the client after the access policy completes successfully, the cookies are marked persistent.
   Cookie Options: HTTP only	Enable or disable check box	HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Use the HttpOnly flag when generating a cookie to help mitigate the risk of a client-side script accessing the protected cookie, if the browser supports HttpOnly.
   SSO Configuration	Predefined SSO Configuration	SSO configurations contain settings to configure single sign-on with an access profile. Select the SSO configuration from the list that you want applied to your domain.

8. Click Multiple Domains. Notice additional fields now appear on the screen.

   

   Setting	Value	Description and defaults
   Primary Authentication URI	URI	The URI of your primary authentication server, for example https://logon.siterequest.com. This is required if you use SSO across multiple domains. You provide this URI so your users can access multiple back-end applications from multiple domains and hosts without requiring them to re-enter their credentials, because the user session is stored on the primary domain.
   Cookie	Domain or Host	If you specify multiple domains, populate this area with hosts or domains. Each host or domain can have a separate SSO config, and you can set persistent or secure cookies. Click Add to add each host you configure.

9. Click Access Policy

   Note

   Object builds outside visual policy editor, but used within the policy are displayed here.

10. Click Edit Access Policy for Profile “server1-psp” to open Visual Policy Editor(VPE) in a new tab.

    

Section 2 - Visual Policy Editor(VPE)

Visual Policy Editor is used for configuration of Access Policies in APM. 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.

The policy below presents a user with a logon page to collect credentials. Once the credentials are collected they are validated against Active Directory. If the credentials are valid the connection to the server is allowed, if they are invalid access is denied.

Let’s explore the components that make up Visual Policy Editor workflows.

Task 2.1 - Branches

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.

Some actions such as Logon Pages only have a single default branch, while other actions such as authentication will have a minimum of two branches.

When a creating a policy from scratch there will only be a single branch connecting the Start item to the Deny Terminal as depicted below.

1. Click on the AD Auth action to explore its configuration.

   

2. Actions will have at least two tabs. One contains the settings for that action, while the second one contains the Branch Rules. Click Branch Rules.

   

3. The AD Auth action has two branch rules. In order to proceed down the Successful branch Active Directory Auth has Passed must be true. If not the user will proceed down the fallback branch. Click change to take a deeper look at the Expression.

   

4. Expressions can be modified under the Simple or Advanced Tabs. The Simple tab allows you create expression using boolean logic. If something is added to the AND expression both conditions must be true. While if something is add the OR condition either condition must be true. Click Advanced.

   

5. The Advanced tab allows direct modification of the expression using TCL. You can now see that AD Auth action evaluates the session variable session.ad.last.authresult to determine if the value is a 1(true).

6. Click Cancel because we do not want to modify anything in the AD Auth action.

   

Task 2.2 - Building Blocks

APM 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.

1. Click the + (Plus Symbol) on the Successful of the AD Auth Action.

   

   The Actions selection screen has a default set of six tabs. Each tab contains a collection of predefined actions related to that tab.

2. The Logon tab contains various ways of collections user credentials.

   

3. Click the Authentication Tab. It contains actions that either validate credentials or interact with directory servers in some way.

   

   

4. Click the Assignment tab. It determines the association between resources and users. Secondly this is where mechanisms such as ACLs or bandwidth controls are chosen.

   

5. Click the Endpoint Security (Server-side) tab. These endpoint checks do not require anything to be installed on the client.

   

6. Click the Endpoint Security (Client-side) tab. These endpoints checks require software to be installed on the client. Either the Edge Client is using VPN or F5 Helper Agent if performing posture via a web browser. It’s important to know the initial installation requires administrative privileges on the client machine. In this environment the software is already installed on the jumphost.

   

7. Click the General Purpose tab. We are now going to add a new action to the policy.

8. Click Message Box

9. Click Add Item

   

10. Enter the text Learning APM in the Title Section.

11. Click Save

    

12. We have successfully added our first new action to this policy. Now After the user credentials are successfully validated against Active Directory the user will see a message box with the text “Learning APM”.

13. Also notice a new set of text has appeared in the top left corner of the policy. When you see Apply Access Policy in the left corner it means a policy has changes that have been saved but yet to be committed. It is important to understand that changes made to a per-session policy do not impact existing sessions. we will leave it that way for now as we have more changes to make.

    

Task 2.3 - Macros

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.

In this task we are going to create a Macro that detects the client operating system. If the system is Windows it proceed to a Firewall check. If the system is anything but Windows the client will proceed down the Fail branch.

1. Click Add New Macro.

   

2. Enter the name for the macro Posture Assessments

3. Click Save

   

4. The empty Macro name now Appears under the policy and can be edited just like the main Per-session Policy.

5. Expand the Macro by clicking the plus symbol

   

6. By default a Macro only has a single terminal. We know upfront that we intent to have a pass/fail condition so it is best create our additional terminal upfront.

7. Click Edit Terminals

   

8. Click Add Terminal

   

9. Change the default terminal text to Pass. This is the terminal using the color green

10. Change the new terminal text to Fail.

11. Toggle the Terminal Endpoints order so the Fail Terminal is on the bottom.

    

12. Click Set Default

13. Change the default to Fail

14. Click Save

    

15. Click the +(Plus Symbol) inside of the Macro’s fallback branch.

    

16. Click the Endpoint Security (Server-Side) tab

17. Select Client OS

18. Click Add Item

    

19. Click Save

    

20. We able to only allow Windows hosts to connect. Click Pass on the Windows RT branch.

    

21. Select Fail

22. Click Save

    

23. Click the Fail Terminal on the Windows branch.

    

24. Select Pass

25. Click Save

    

26. Click the +(Plus Symbol) inside of the Windows branch.

    

27. Click the Endpoint Security (Client-side) tab.

28. Select Firewall

29. Click Add Item

    

30. Leave the defaults. Click Save

    

31. Now add your completed Macro to the Policy by clicking the +(Plus Symbol) between the Start Item and Logon Page action.

    

32. A new tab has appeared now that a Macro has been configured. Click the Macros tab

33. Select Posture Assessments

34. Click Add Item

    

Task 2.5: Endings

Endings allow an administrator to customize APM’s response by introducing redirects rather than generic Allow or Deny action. We will explore added a redirect to our policy to see it’s behavior during testing.

1. Click Edit Endings

   

2. Click Add Ending

   

3. Select the Redirect radio button

4. Enter the URL https://www.f5.com

5. Update the color #16 Violet

6. Enter the Name Redirect for the Redirect Terminal

7. Click Save

   

8. Select the Deny Terminal off the AD Auth Action fallback branch

   

9. Select the Redirect Terminal

10. Click Save

    

11. We now a have completed Policy. Click Apply Access Policy in the top left.

    

Task 2.6 Testing

1. Open a new browser tab and then navigate to https://server1.acme.com. You will be redirected to /my.policy and the first thing that happens in our policy is the Windows and Firewall Check. You can see these are being performed as the agent software is being triggered when the screen states Awaiting Connection… and then transitions to Checking for security software.

   

   

2. After posture assessment has been successful performed the logon screen will appear.

   

3. we are going to first test if the redirect works by failing Active Directory Authentication. Enter the username: test and password:test and attempt to logon. Repeat this step two more times because the AD auth agent by default requires three failed logon attempts before sending the user down the fallback branch.

   

4. One authentication has been failed 3 times you are directed to https://www.f5.com as expected.

   

5. The session has been closed by the redirect Action. Navigate back to https://server1.acme.com

6. At the logon page enter the Username:user1 and Password:user1

7. Click Logon

   

8. After successful authentication you are presented the Message box with the text learning APM. Click Continue.

   

9. User1 has successfully authenticated through the policy and now granted access to their resource.

   

Lab Cleanup

1. From a browser on the jumphost navigate to https://portal.f5lab.local

2. Click the Classes tab at the top of the page.

   

3. Scroll down the page until you see 101 Intro to Access Foundational Concepts on the left

   

4. Hover over tile Visual Policy Editor (VPE) Overview. A start and stop icon should appear within the tile. Click the Stop Button to trigger the automation to remove any prebuilt objects from the environment

   

5. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded. If you experience errors try running the automation a second time or open an issue on the Access Labs Repo.

   

6. This concludes the lab.