Lab 1: Building a Basic Access Policy

Objectives

In this lab we will work through the building blocks of Access Policy Manager. Much like the majority of the other modules around LTM they are policy based meaning you are binding a Profile to the virtual server in question that you want to provide enhanced functionality. In this case those come in the form of Per-Session and Per-Request Policies

Setup Lab Environment

To access your dedicated student lab environment, you will need a web browser and Remote Desktop Protocol (RDP) client software. The web browser will be used to access the Unified Demo Framework (UDF) Training Portal. The RDP client will be used to connect to the jumphost, 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 jumphost.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 102 Access Building Blocks on the left

   

9. Hover over tile Building a Basic Acces Policy. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

10. After the click it may take up to 30 seconds before you see processing

    

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

    

Intro to Access Profiles and Policies

Access Policy Manager (APM) provides two types of policies.

Per-session policy

The per-session policy runs when a client initiates a session. (A per-session policy is also known as an access policy.) Depending on the actions you include in the access policy, it can authenticate the user and perform other actions that populate session variables with data for use throughout the session.

Per-request policy

After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. Because of this behavior, a per-request policy is particularly useful in the context of a Zero Trust scenario, where the client requires re-verification on every request. A per-request policy can include a subroutine, which starts a subsession. Multiple subsessions can exist at one time. You cannot use subroutines in macros within per-request policies.

You can associate one access policy and one per-request policy with a virtual server.

Access Session

An access session is recorded when a client initiates a connection through a per-session policy. Once an access session is established it has a set of timeouts set within the Access profile. A session will terminate if it reaches a timeout or the client ends the session. An access session is now not limited by a license but by the platform running APM. For more information on APM licensing see K15624537: BIG-IP APM Licensing for BIG-IP Standard Platforms

Subsession

A subsession is part of the per-request policy framework. It starts when a subroutine (within a per-request policy) runs and continues until reaching the maximum lifetime specified in the subroutine properties, or until the session terminates. A subsession populates subsession variables that are available for the duration of the subsession. Subsession variables and events that occur during a subsession are logged.

Multiple subsessions can exist at the same time. The maximum number of subsessions allowed varies across platforms. The total number of subsessions is limited by the session limits in APM (128 * max sessions). Creating a subsession does not count against the license limit.

Objectives

The lab has a pre-configured test Virtual Server which will be used throughout the lab. You will use the Visual Policy Editor (VPE) to create and attach a simple Access Profile which performs user authentication.

Lab Requirements

• A pre existing virtual server at 10.1.10.101 or https://app.acme.com

Task 1: Define an Authentication Server

Before we can create an access profile, we must create the necessary AAA server profile for our Active Directory.

1. Click the bigip1 bookmark from within Chrome and login to the BIG-IP, admin/admin

2. From the main screen, browse to Access > Authentication > Active Directory

3. Click Create… in the upper right-hand corner

4. Configure the new server profile as follows:

   Name:	lab_sso_ad_server
   Domain Name:	f5lab.local
   Server Connection:	Direct
   Domain Controller:	10.1.20.7
   User Name:	admin
   Password:	admin

5. Click Finished

   Note

   If you wish you can simply use the app-ad-servers.

Task 2: Create a Simple Access Profile

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

   

2. From the Access Profiles screen, click Create… in the upper right-hand corner

3. In the Name field, enter mycccesspolicy and for the Profile Type, select the dropdown and choose All

   

4. Under “Language Settings”, choose English and click the

   << button to slide over to the Accepted Languages column.

   

5. Click Finished, which will bring you back to the Access Profiles screen.

6. On the Access Profiles screen, click the Edit link under the Per-Session Policy column.

   

   The Visual Policy Editor (VPE) will open in a new tab.

7. On the VPE page, click the + icon on the fallback path, to the right of the Start object.

   

8. On the popup menu, choose the Logon Page radio button under the Logon tab and click Add Item

   

   

9. Accept the defaults and click Save

   Now let’s authenticate the client using the credentials to be provided via the Logon Page object.

10. Between the Logon Page and Deny objects, click the + icon, select AD Auth found under the Authentication tab, and click the Add Item button

    

    

11. Accept the default for the Name and in the Server drop-down menu select the AD server created above: /Common/lab_sso_ad_server, then click Save

    

12. On the Successful branch between the AD Auth and Deny objects, click on the word Deny to change the ending

    

13. Change the Successful branch ending to Allow, then click Save

    

    

14. In the upper left-hand corner of the screen, click on the Apply Access Policy link, then close the window using the Close button in the upper right-hand. Click Yes when asked Do you want to close this tab?

    

    

Task 3: Associate Access Policy to Virtual Servers

Now that we have created an access policy, we must apply it to the appropriate virtual server to be able to use it.

1. Navigate to Local Traffic –> Virtual Servers –> Virtual Server List and click the name of the virtual server created previously: app-https

2. Scroll down to the Access Policy section, for the Access Profile dropdown, select myaccesspolicy

   

3. Click Update at the bottom of the screen

Task 4: Testing

Now you are ready to test.

1. Open a new browser window and open the URL for the virtual server that has the access policy applied:

   https://app.acme.com

   You will be presented with a login window

   

2. Enter the following credentials and click Logon:

   Username:	user1
   Password:	user1

You will see a screen similar to the following:

Task 5: Troubleshooting tips

You can view active sessions by navigating Access/Overview/Active Sessions

You will see a screen similar to the following:

Click on the session id for the active session. If the session is active it will show up as a green in the status.

Click on the “session ID” next to the active session. Note every session has a unique session id. Associated with it. This can be used for troubleshooting specific authentication problem.

Once you click on the session id you will be presented with a screen that is similar to the following.

Note that the screen will show all of the log messages associated with the session. This becomes useful if there is a problem authenticating users.

The default log level shows limited “informational” messages but you can enable debug logging in the event that you need to increase the verbosity of the logging on the APM policy. Note you should always turn off debug logging when you are finished with trouble shooting as debug level logging can generate a lot of messages that will fill up log files and could lead to disk issues in the event that logging is set to log to the local Big-IP.

Please review the following support article that details how to enable debug logging.

https://support.f5.com/csp/article/K45423041

Lab 1 is now complete.