Considerations when using F5 of other Load Balancer for MFA and ReST API agents. How to configure F5 or other Load Balancing.
6 months ago
Article Number
000073573
Applies To

on-Prem AM 8.7 and later. Possibly AM 8.6 too.

Issue

ReST based authentication API agents may or may not include a load balance feature. The RSA MFA agent for Windows has options for Weighted Round-Robin load balancing that can be controlled via Windows GPO, the RSA IIS MFA agent can be configured for manual load-balancing priorities, also through GPO, while the RSA MFA agent for PAM only has an option for Round-Robin with no weighting, no priorities and no GPO templates.

A custom ReST API agent might only offer failover URLs with no load balancing.

Therefore, sites with a mix of ReST based API agents might use F5 or other Load Balancers to provide consistent load balancing services for 100% uptime to Authentication Manager servers for all ReST API and MFA agents. 

See also KB article # 000064993
Configuration options for RADIUS Client Load balancing with Authentication Manager version 8.6

Tasks

1. Configure any RSA MFA agents to have no MFA agent load balancing, with a single VIP authentication URL with no failover URLs. 

2. Configure the Load Balancer with a pool list the AM servers that will offer authentication services

3. Configure the Load Balancer pool with a load balance strategy, e.g. Round-Robin.

4. Configure the Load Balancer with a health monitor or keep-alives, to maintain an accurate list of available online backend AM servers that are in the load balance pool. 

Resolution

To configure MFA and ReST API agents to use F5 or other Load Balancers, you will want to do the following:

1. Configure any RSA MFA agents to have no MFA agent load balancing, with a single VIP authentication URL with no failover URLs. RSA MFA agents configured this way will be completely dependent on the F5 or other load balancer, and will not compete or conflict with the F5 strategy and configuration.

NOTE: With the MFA Agent for Windows Load Balancing GPO, 'Not Configured' means Round-Robin for LB and Failover. Configure this GPO for 'Disabled' to have no load balancing. 

2. Configure the Load Balancer with a pool list the AM servers that will offer authentication services. Give this pool a Virtual Server name and IP address, aka a VIP URL that resolves in DNS and can be configured as the single VIP authentication URL on all MFA and ReST API agents.

3. Configure the Load Balancer pool with a load balance strategy, e.g. Round-Robin.

4. Configure the Load Balancer with a health monitor or keep-alive, to maintain an accurate list of available online backend AM servers that are in the load balance pool. *

* If Load Balancer must listen on TCP port 443 instead of port 5555, refer to 

How to configure a load balancer with REST API
https://community.rsa.com/s/article/How-to-configure-a-load-balancer-with-REST-API

to configure the following:
While sending the request, hard-code a header. where the header Key is "Host", and the Value of the header should be "<loadbalancerIP>:5555"

===optional keepalive details===

Load Balancer Keep-alives can be configured in two main ways.

  1. Simply, using the TCP port 5555 on the AM servers in the load balance pool. TCP 3-way handshakes with SYN, SYN-ACK, ACK ensure that a TCP port is up and listening. This is a Layer 4 check on the OSI 7-layer model.   

    Sample iRule with 60-second keepalive would look something like this ([server_port] would = 5555)

    when SERVER_CONNECTED {
        log local0. "Client: [client_addr]:[client_port] - Server: [server_addr]:[server_port]."
        # Set server-side keep-alive interval to 60 seconds.
        TCP::keepalive 60
    }

     
  2. Minimal complexity, using an https URL to check if an application is connected to its TCP service port. This is more than a Layer 4 check on the OSI 7-layer model and is considered an application level check without actually performing an authentication.

Regarding application layer keep-alives, the following MFA URLs might provide the needed application layer check required by some customers.

1. https://<AM_server>:5555/mfa/v1_1/cancel
Sending a "cancel" REST request via URL - but with an invalid payload and no API key they should expect an error response. A request with no payload would get back a "401" response and the text:
"Unauthorized: Authentication token was either missing or invalid."

2. https://<AM_server>:5555/mfa/v1_1/authn/initialize
This URL is used by agent to check the server status
Again, with an invalid payload and no API key they should expect an error response.

3. https://<AM_server>:5555/mfa/v1_1/healthcheck
If AM ReST port is up and listening, this URL would expect to get back a "401" response and the text:
"Unauthorized: Authentication token was either missing or invalid."
which indicates that the REST port is available and responding.
This is because there is no healthcheck endpoint in the ReST API.

4. https://<authmanagerFQDN>.com:7004/IMS-AA-IDP/InitialLogonDispatch.do
If a 200 response is needed, you can get from AM console but not ReST, using GET.

In AM 8.7 SP2, there is a URL which they can access via GET without sending payload nor header (so no key or credentials is sent for access). The GET to this URL will respond with 200 OK if AM is running:

Notes

Logging Notes

On an Authentication Manager Server you should be able to see some mfa keepalives in the /opt/rsa/am/server/logs biztier_access.log and/or imsTrace.log

===biztier_access.log===
POST    /mfa/v1_1//authn/initialize

===imsTrace.log===
ServletRequestHandledEvent: url=[/mfa/v1_1/authn/initialize]; client=[172.30.0.3]; method=[POST];
ServletRequestHandledEvent: url=[/mfa/v1_1/authn/verify]; client=[172.30.0.3]; method=[POST];

 

3rd Party product logging

MyF5 Home External Monitoring of BIG-IP Systems: Implementations About Logging
https://techdocs.f5.com/en-us/bigip-14-0-0/external-monitoring-of-big-ip-systems-implementations-14-0-0/about-logging.html

Manual Chapter: About Logging
Configuring Request Logging
Configuring Remote High-Speed Logging
Configuring Remote High-Speed DNS Logging
Configuring Remote High-Speed Logging of Protocol Security Events
Configuring Remote High-Speed Logging of Network Firewall Events
Configuring Remote High-Speed Logging of DoS Protection Events
Configuring Remote High-Speed Logging of CGNAT Processes
Setting Up Secure Remote Logging
Configuring CGNAT IPFIX Logging
Logging Network Firewall Events to IPFIX Collectors
Customizing IPFIX Logging with iRules
Monitoring BIG-IP System Traffic with SNMP
Monitoring BIG-IP System Traffic with sFlow
Event Messages and Attack Types
IPFIX Templates for CGNAT Events
IPFIX Templates for AFM Events
IPFIX Templates for AFM DNS Events
IPFIX templates for AFM SIP events

Knowledge article
K16197: Reviewing BIG-IP log files
https://my.f5.com/manage/s/article/K16197


CLI - SSH
tail /var/log/ltm
tmsh" to switch to your virtual terminal
show /sys log all
tmsh show /sys log ltm range 2025-09-21--2025-09-22     [Sep 21-22, 2025]
tmsh show /sys log ltm range now-2d            [show last 2 days]

GUI
SYSTEM --> Logs
web console: Security > Event Logs

-------------------------

Home / VMware® Security and Load Balancing / VMware® Avi Load Balancer /
VMware Avi Load Balancer 31.1
https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/31-1.html

Configuration Guide
Masking and Removing Personally Identifiable Information (PII) in Applications Logs on Avi Load Balancer
https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/31-1/vmware-avi-load-balancer-configuration-guide/masking-and-removing-personally-identifiable-information-pii-in-applications-logs-on-avi-vantage.html

Hiding PII in Information Logs using CLI
Based on the requirement, any of the HTTP request headers and response headers can be masked or removed in the virtual service logs on Avi Load Balancer.
In the configuration snippet mentioned below, HTTP headers are selected by using the match_str: "HTTP-Header-name" command and their corresponding actions (to mask the original value) are set by using the LOG_FIELD_MASKOFF command in the analytics profile configuration of a virtual service:
Refer to the following configuration snippet for reference:

analyticsprofile_object {
   uuid: "l7-analytics-profile-3"
   name: "l7-analytics-profile-3"
   tenant_uuid: "admin"
   sensitive_log_profile {
      header_field_rules {
         index: 1
         name: "hdr_rule_1"
         enabled: true
         match {
            match_criteria: EQUALS
            string_group_uuids: "stringgroup-2"
         }
         action: LOG_FIELD_MASKOFF
     }
     header_field_rules {
         index: 2
         name: "hdr_rule_2"
         enabled: true
         match {
            match_criteria: CONTAINS
            match_str: "X-Forwarded-For"
         }
         action: LOG_FIELD_MASKOFF
     }
   }
}

stringgroup_object {
   uuid: "stringgroup-2"
   name: "stringgroup-2"
   kv {
      key: "Authorization"
   }
   kv {
      key: "Cookie"
   }
   kv {
      key: "Set-Cookie"
   }
   tenant_uuid: "admin"
}