BIG-IP Next Access: Troubleshooting FAQ

This page of frequently asked questions is specific to BIG-IP Next Access. Use this section for general support and troubleshooting information.

Access Components

What are Access Components?

BIG-IP Next is composed of several components which are deployed as pods. In BIG-IP Next Access, the following components perform traffic processing:

  • f5-access-apmd: Runs the Access policy. An example of this Pod name is f5-access-apmd-5f4888bcfc-xjpr4.

  • f5-access-renderer: Renders the access related (login/logout) webpages. An example of this Pod name is f5-access-renderer-5f4666bcfc-xjpr6.

  • f5-access-session-manager: Handles all session management functions. An example of this Pod name is f5-access-session-manager-66cc784f88-8w26b.

  • f5-fsm-tmm: An example of f5-fsm-tmm pod name is f5-fsm-tmm-864f497c66-qhh5n. The f5-fsm-tmm pod has the following containers:

    f5-fsm-tmm: Processes incoming traffic.

    f5-access-websso: Processes the single-sign-on functionality.

How do I view information on the pods and containers?

Use one of the following kubectl command as per your requirement to enter a pod:

kubectl get pods | grep apmd
kubectl exec -it <podname> -- bash
kubectl exec -it <podname> -- sh
kubectl exec -it <podname> -c <container-name> -- sh
kubectl exec <podname> -- bash -c "ls /"
kubectl exec <podname> -c <container name> -- bash -c "ls /"

How do I list running pods and containers?

Use the following kubectl commands to list running pods on the BIG-IP Next:

kubectl get pods | grep f5-access
kubectl get pods | grep f5-access-apmd
kubectl get pods | grep f5-access-renderer
kubectl get pods | grep f5-access-session-manager

To view all pods:

kubectl get pods

To view all containers:

kubectl describe pod <podname>

To view all access pods:

kubectl get pods | grep "\(access\|fsm\)"

To view all access pods (except websso container):

kubectl get pods | grep access


How many Concurrent Access sessions are supported?

The BIG-IP Next Access supports a maximum of 20000 Concurrent Access sessions.


What configuration should my VE instance be for deployment?

All BIG-IP Next Access instances should use 8 core and 16 GB configuration for deployment.

Refer the following links for details on initial setup:

General Health

How do I check the general health of the modules?

To display a live stream of pod(s) resource usage statistics (such as CPU, memory, network, disk), use the following commands:

  • kubectl get pods | grep f5-access-apmd

    This command returns the pod name for f5-access-apmd pod.

  • kubectl describe pod <podname>

    This command describes pod status and health.

  • kubectl top pods

    This command gives the CPU memory usage of a pod.

Refer to kubectl commands for more details.

How do I generate and download a QKView file?

Refer to the How to: Generate & download a QKView file and upload to F5 iHealth or Support link for more information.

Collecting and Viewing Logs

How do I collect and view logs?

Run the following commands on a shell to collect and view logs:

  • Use the GET /systems/{system-id}/logs API to get the list of available logs:

    curl --location --insecure --request GET 'https://'${MBIP_MGMT_IP}':5443/api/v1/systems/{system-id}/logs' --header 'Authorization: Bearer '${TOKEN}


  • Use the Use the GET /systems/{system-id}/logs/<log-file-name> API to get a specific log file such as f5-access-apmd-stdout.log:

    curl --location --insecure --request GET 'https://'${MBIP_MGMT_IP}':5443/api/v1/systems/{system-id}/logs/f5-access-apmd-stdout.log' --header 'Authorization: Bearer '${TOKEN}


    "{\"type\":\"apmd\",\"timestamp\":\"Timestamp here\",\"log\":\"Log statement here\",\"tier2tag\":\"stdout\"}"
  • Use the kubectl command to get real-time logs for apmd pod:

    kubectl get pods | grep fluentdserver
    kubectl exec -it <podname> – sh tail -f /TODA/log/f5-access-apmd-stdout.log


    kubectl get pods | grep apmd
    kubectl logs -f <podname> –-timestamps=true


    kubectl logs -f f5-access-apmd-5f4888bcfc-xjpr4 –-timestamps=true
  • Use the kubectl command to get real-time logs for TMM container:

    kubectl get pods | grep fluentdserver
    kubectl exec -it <podname> – sh tail -f /TODA/log/f5-fsm-tmm-stdout.log


    kubectl exec -it fluentdserver-7b65c47fd9-7d8gj – sh tail -f /TODA/log/f5-fsm-tmm-stdout.log

    Another method:

    kubectl get pods | grep tmm
    kubectl logs -f <podname> -c f5-fsm-tmm


    kubectl logs -f f5-fsm-tmm-864f497c66-qhh5n -c f5-fsm-tmm

How do I change log levels?

Setting log levels in Access

Using the service object, you can configure the system logs, analytics, cluster configuration, and WAF settings. The service object represents the name of the service or process that generated the log. To change Access log settings independently from other service properties, use the /services/{serviceId}/access endpoint. The serviceId is the service identifier. To retrieve a service ID, make a GET request to the endpoint /services. This returns a list of all the services.

The logging object defines an array of log settings and log levels of various Access components. Set log levels for the components using the following properties in the logging object.

  • component: Specifies the BIG-IP Next Access component.

  • policy: Specifies the name of the Access policy. This property is optional; if not specified, the log levels are used by Access for policies that do not have their defined log level.

  • level: Specifies the minimum log level for the component log messages. The possible values for the log level are DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, and EMERGENCY. These values are not case-sensitive. The default log level for all the Access logs is Notice.

To get all services:

GET https://{{bigip_next_mgmt_floating_ip}}:5443/api/v1/services

To set the log level for the websso, tmm, and apmd components:

PUT /services/{serviceId}/access
  "logging": [
      "component": "websso",
      "level": "WARNING"
      "component": "tmm",
      "level": "NOTICE"
      "component": "apmd",
      "policy": "access-policy",
      "level": "DEBUG"


"id": "b56797e0-78fc-470f-aaa0-5e7ca3e10a32",
"verb": "PUT",
"uri": "/services/2addf4c6-1bda-44ec-a511-377af75c3a49/access",
"request": "{\"logging\":[{\"component\":\"websso\",\"level\":\"WARNING\"},{\"component\":\"tmm\",\"level\":\"NOTICE\"},{\"component\":\"apmd\",\"level\":\"DEBUG\",\"policy\":\"access-policy\"}]}",
"role": "AGENTCONFIG",
"status": "PENDING",
"message": {
"code": "",
"title": "",
"detail": "",
"links": {
"about": "",
"resourceLink": ""
"creationTime": "2022-08-10T22:44:43.347487Z",
"updateTime": "2022-08-10T22:44:43.347487Z",
"owner": "admin",
"authn": "local",
"authz": "global"


What are the common configuration errors?

jobId is used to track the progress of the job and get useful information about it. Every PUT call returns a 202 with a Job ID that can be used to track the progress of the task and find out if it is successful, timed out, or failed.

Refer to the Support and Troubleshooting link for general support.

SessionDump Command

How do I use the sessiondump utility for BIG-IP Next?

SessionDump is a command-line utility that allows you to perform several operations within BIG-IP Next, such as listing, copying, or deleting Access session information. You can access this utility and run commands only from the f5-access-session-manager pod. To get into the f5-access-session-manager pod, you require access to the pod’s Kubernetes environment. Once you SSH into the f5-access-session-manager pod, you can retrieve and delete session information using the sessiondump command.

Use the kubectl exec command to get pod access:

kubectl get pods | grep f5-access-session-manager
kubectl exec -it <podname> -- bash
kubectl exec <session manager podname> – sessiondump --list

The sessiondump command syntax on CLI includes one operation and one or more arguments and flags. The general usage for sessiondump utility is as follows:

sessiondump <operation> <arguments> <flags>


Name Description Example
help Show this help message sessiondump --help
list Show list of all sessions sessiondump --list
allkeys Show all session variables for all sessions sessiondump --allkeys
locks Show list of session locks sessiondump --locks
ip Show list of IP to session maps sessiondump --ip
ntlm Show list of NTLM credentials to session maps sessiondump --ntlm


Name Description Example
sid Show all session variables for a session sessiondump --sid 75d4d5c7
where 75d4d5c7 is the session key for a session
delete Delete all or a specific session sessiondump --delete all
sessiondump --delete 75d4d5c7
where 75d4d5c7 is the session key for a session
lockdelete Delete all or a specific session lock sessiondump --lockdelete 75d4d5c8
where 75d4d5c8 is the session lock for a session


Name Description Example
savetofile Save all results to a file sessiondump --allkeys --savetofile
json Show in json format sessiondump --json

How do I send a sessiondump command from BIG-IP Next Central Manager?

To send a sessiondump command to BIG-IP Next Access, you can use an API call.

  1. Authenticate with the BIG-IP Next Central Manager API. For details refer to How to: Authenticate with the BIG-IP Next Central Manager API.

  2. Send the command by sending a Post to the /api/apm/v1/sessions/{{mbiq_instance_id}}/{{mbiq_session_id}}/variable endpoint.

    POST https://{{big-ip_next_cm_mgmt_ip}}/api/apm/v1/sessions/{{mbiq_instance_id}}/{{mbiq_session_id}}/variable

SAML SP policy - Error Messages

Error message: SAML SSO: Error failed to base64 decode message

BIG-IP Next Access as SAML SP or IdP URL decodes POST binding SAML messages, and base64 decodes them. If Access as SAML SP or IdP receives a SAML message that is not URL encoded, then it will still URL decode the message and attempt to base64 decode, which may lead to failure in processing the SAML message and give the following error in Access logs.

SAML SSO: Error failed to base64 decode message:


This is expected behavior.

Note: SAML messages can be found in Access logs and session variables. A good base64 SAML message contains a large block of ASCII characters. If the SAML message contains a space, then it indicates the SAML request message was not URL encoded.

Error message: SAML assertion is invalid, error: Recipient should match acs url of BIG-IP (as SP)

When attempting SP initiated SAML, where the BIG-IP Next is the Service Provider, you may get the following error message:

SAML assertion is invalid, error: Recipient should match acs url of BIG-IP (as SP)


There are multiple reasons this error can be generated:

  • EntityID in the SP configuration is set to use http:// instead of https:// to build out the ACS URL of the SAMLRequest that is sent to the Identity Provider.

  • The Host value also has a protocol, such as placing http:// or https:// in front of the hostname.


  1. Update SP configuration to use the correct https:// scheme.

  2. Ensure there is no protocol included in the host field.

Error Message: SAML SSO: Error creating signed SAML message - failed to find certificate

BIG-IP Next as the SP fails to generate signed SAML requests/responses or SAML Single Logout (SLO) requests/responses after the signing certificate is modified or re-imported. SAML services are impacted when this happens, and the resources that need SAML authentication cannot be accessed. Subsequent SAML/SAML SLO requests/responses fail with the following error:

SAML SSO: Error creating signed SAML message - failed to find certificate


The certificate used for signing SAML requests/responses or SAML SLO requests/responses is modified or re-imported.


Delete and re-create the Access configuration.

Kerberos SSO

What is Kerberos constrained delegation?

Kerberos delegation is a Microsoft feature that allows an application to reuse end-user credentials to access resources hosted on a different server. Kerberos constrained delegation is a form of specifying applications that are allowed to reuse the user credentials. A server is configured to pass along a client’s identity and credentials to a secondary resource server, accessing a resource or service on behalf of the client while limiting the scope of where application services can act on the client’s behalf.

For more information, refer to the Microsoft Kerberos Constrained Delegation Overview document.

Setting up a delegation account to support Kerberos SSO

Before you can configure Kerberos SSO in Access, you must create a delegation account in Active Directory. For every server realm, you must create a delegation account in that realm.

Note: For up-to-date instructions on configuring the Kerberos delegation for your account, refer to the Microsoft documentation.

  1. Open the Active Directory Users and Computers administrative tool and create a new user account.

    The user account should be dedicated for delegation. Ensure that you have enabled the account user with change password and set the password to never expires.

  2. Set the service principal name (SPN) on the Windows server for the user account.

    For the support tools that you can use, and for the commands, such as setspn and ktpass, refer to Microsoft documentation.

    Note: If you use the ktpass command, it sets the SPN on the Windows server and creates a keytab file. Kerberos SSO for Access does not need or use a keytab file.

  3. Verify the result of setting the SPN.

    This example is purely for illustration. Refer to Microsoft documentation for up-to-date commands and correct usage.


    Registered ServicePrincipalNames for CN=acc,OU=users,DC=loc,DC=lab,DC=dnet,DC=com: HTTP/ where acc is the name of the user account that you created.

  4. Return to the Active Directory Users and Computers screen to open your account again.

    A Delegation tab should appear.

  5. Select Trust this user for delegation to specified services only.

  6. Select Use any authentication protocol, and add all your services to the list under Services to which this account can present delegated credentials.

    Every service should have Service Type HTTP (or http) and the host name of the pool member or web application resource host that you will use in your configuration.

  7. Click OK.

    This creates the new delegation account.

DNS server

You must configure the BIG-IP Next with a DNS server that contains the proper Kerberos SRV records. SRV records are in the form of _kerberos._udp.<DOMAIN> or _kerberos._tcp.<DOMAIN>. These DNS entries are queried when the KDC field (Key Distribution Center) from the Kerberos SSO profile is empty and the dns_lookup_kdc value in the /etc/krb5.conf file is set to true. This allows DNS to know which KDC handles the authentication for a given realm. Without these entries, SSO might fail.

If multiple entries exist for a service, UDP is used by default. In the event that the response contains too many KDC records (more than 512 bytes), DNS will switch to TCP on port 53 to request the same entries.

Required ports

The following ports are used in Kerberos and must be allowed for proper communication and authentication.

Port Protocol IP(s)
53 UDP/TCP DNS Server
123 UDP NTP server(s)
<Web Server port(s)> TCP Web server(s)

/etc/krb5.conf file

Example /etc/krb5.conf file:

 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes
   kdc =
# kdc = add as many kdc entries a you like 
   kdc =
   kdc =

Manually modifying the krb5.conf file allows you to define lists of KDCs for realms. However, configuring more than one KDC does not provide a load-balancing mechanism. Only the first entry will be used unless it is not available. Supported formats for supplying KDCs are fqdn|IP(:port).

For example:

kdc = kdc = kdc =

Note: F5 does not recommend modifying the krb5.conf file, unless you have no other options to accomplish your intended outcome. Back up working files to a separate location before making changes.

Refer to the article for additional information on troubleshooting issues with Kerberos SSO constrained delegation.

Kerberos SSO - Error Messages

Error Message: Client not found in Kerberos database

When you give an incorrect user name during the authentication process, the following error message is displayed in Access logs:

Client not found in Kerberos database, principal name: <username>@<domain>. Please verify Active Directory and DNS configuration


Possible AD items that may cause Access to report this error include the following:

  • Incorrect user name.

  • Incorrect configuration of constrained delegation.

  • Using multiple delegation accounts for the same realm.

  • Incorrect configuration of AD delegation account.


Use the correct user name and ensure that the constrained delegation is correctly configured for the account. If you are still unable to authenticate, contact your Active Directory administrator to resolve the issue.