A fellow Devcentral member named Shannon Poole graciously shared this guide on how to protect BigIP Report behind the APM. This would actually be the first “guest post” on the blog too. If you want to get into contact with Shannon you can connect with him via LinkedIn or send a message via Devcentral.
Thank you very much for sharing this Shannon!
Table of Contents
Here is a simple configuration that I came up with to regulate access to my BIGIP Report and utilize the APM module. I am, by no means, an expert with APM but this policy may be simple enough to deploy to anything you want.
The author would like to thank David Allshouse, Senior Systems Engineer for constructive criticism of the manuscript.
Configure an Active Directory AAA server
Navigate to Access Policy -> AAA Servers -> Active Directory and use the configuration below. It is necessary to give a name, domain name, and IP address of the domain controller. Also, choose Direct rather than Use Pool.
Note: A better configuration may be to use the Pool should a DC become unresponsive but that is something which can be configured later.
Creating a New Access Profile
Navigate to Access Policy -> Access Profiles List and hit the create button. Provide a name, such as MyAccessProfile, and set the profile type to “ALL.” This could probably be set to “LTM-APM” if you want to be precise but that is not necessary. Next, remove the check for “Secure” in “Cookie Options” as it is not required due to no SSO. Finally, add “English (en)” as a language is required and click Finish.
Note: Since I am not using multiple domains or SSO configurations for this setup, creating an access profile was fairly simple.
Configure Your Access Policy
Once you have configured your Access Profile, you should now see your policy in the Access Profile List and should be able to click on the policy name, which brings you to the screen below:
Click on the Access Policy tab and now when you click on Edit Access Policy for Profile “My Access Policy”, you should see the following screen:
This brings you to the basic configuration of your policy and configured with a “deny-by-default” method similar to most things with F5.
Configure a Macro
With this policy, it was important to configure it in a way as to limit access via Active Directory security groups. In order to do this, you need to add a macro to handle the logon page, authentication, and AD query processes. This can be done by clicking on “Add New Macro” and then selecting “AD auth query and resources” for the “Select macro template” drop-down. Provide a name, such as “MyADAuth” and it should look like the template below:
Once you click “Save”, the Macro has been created and added to the policy:
The next step was to remove the “Resource Assign” and “AD Logging” items by clicking on the “X” and selecting delete. These are not required for this policy. The end result should be this:
Now you am ready to configure the policy. Start with the Logon Page and write some simple text in the “From Header Text” box and change the “Logon Button” to “Submit”. Everything else was left as the defaults.
For the “AD Auth” configuration, only select the AAA server that you created earlier in the “Server” drop-down:
The AD Query is where you will configure your AD groups. Like the previous screen shot, you need to select your AAA server from the “Server” drop-down:
Now it’s time to move onto the “Branch Rules” tab. The first thing was to remove the “Primary Group ID is 100” branch rule so you can create your own. Once that is removed, you are now free to select “Add Branch Rule.” It should look like this:
Next, rename the Branch Rule to “MyBranchRule” and select “change” which gives the ability to add an expression:
Next, click “Add Expression” and select the items that you see below while also adding your AD memberof attribute string for the group you want to use:
Once you click “Add Expression”, you should see your policy look like this:
Now you are ready to indicate which action determines a failure or a success within your macro. You can do this by simply clicking on “Failure”, selecting the radio button for Successful, and click save:
The final step for the Access Policy configuration is to add your macro, MyADAuth, to the policy by selecting the plus sign between “Start” and “Deny” and navigating to the “Macrocalls” tab:
Now when you select the macro and click “Add Item”, it adds the macro to the policy:
Since both rules are set to deny, you need to change the Successful branch to an allow by clicking on “Deny” and selecting allow.
Save your changes and add the Access Policy to your Virtual Server. To save your changes, you can simply click on the “Apply Access Policy” in the header above. Then add the policy to your virtual server by navigating to your virtual server and adding it in the Access Policy section: