Manual Chapter : Authentication & Access

Applies To:

Show Versions Show Versions

F5OS-A

  • 1.8.0
Manual Chapter

Authentication & Access

Authentication and access overview

You can manage the
rSeries
system from the CLI, the webUI, or using REST APIs.
The
rSeries
system has
two
levels of user management:
System level
At the system level, after basic configuration is complete, the system includes default root (Bash access only) and admin accounts that you can use to log in to the system. The system administrator uses the admin account and changes the default passwords when logging in the first time. At that point, the admin user can also create additional accounts for other users, such as other system administrators, terminal server administrators, or operators.
Tenant level
Since the tenants are independent of the rest of the
rSeries
system, management of tenant users is not covered in this guide. For more information, see the tenant documentation (such as
BIG-IP
software documentation at my.f5.com).

User roles overview

There are multiple user roles for managing the
rSeries
system, and each role performs different sets of administrative actions at conceptually different levels.

User roles

This table lists user roles at the system level.
Role
Description
admin
Provides access to the system CLI or webUI to configure the system-level settings with unrestricted read/write access. Can unlock any system users. Logs in to the active management IP address. No Bash access.
Has broader ability and can configure management interfaces, install Base OS system software, modify system settings, activate licensing, perform user management, and configure network settings, port groups, interfaces, VLANs, LAGs, log settings, tenant deployments, and system settings.
The default login credentials are admin/admin. When logging in as admin for the first time, the system prompts you to change the password. This also changes the default password for the root account to match that of the admin account.
limited
F5 internal use only.
operator
Allows read access to system level configuration from the CLI or webUI and write access to change password only. Logs in to the active management IP address. No Bash access.
Has read-only access to every screen and every configuration object at the level in which they are working. If an operator tries to modify any setting, however, the system displays a warning that explains that their role is unauthorized to make the configuration change.
resource admin
Similar to the Admin user role, but cannot create, modify, or delete local user accounts; create, modify, or delete server groups; or modify any authentication settings. This user role can modify their own user detail to change their own password.
root
Created by the system. Used by the system administrator. Provides Bash shell access to the entire system including all components. The root user is the
only
user that has Bash access. The system root account can be accessed from the management IP address and from a console. The root password can be changed using the
passwd
command, or by an admin user from the CLI.
On first login, you are forced to change the password. If you change the root user password and the admin password is ‘admin’ at that time, the admin user will have the same new password.
F5
recommends disabling the root account using appliance mode in production to reduce the attack surface of the system and protect it from any vulnerabilities.
tenant-console
Has virtual console access to tenants from the CLI. Tenant console access is authenticated by tenant root credentials. No access to any part of the
rSeries
system.
user
This role grants users permission to view all objects on the system except for sensitive data such as events, user login activity, files and directories, and configuration backup. This user role cannot modify any system configurations however users can change their own password.
superuser
This role provides root access privileges and bash access to the system, allowing users with the superuser role to execute commands from bash shell. To get the bash shell, users must set the 'superuser-bash-access' flag in ConfD to 'true' and turn off the appliance mode.

Remote authentication overview

The
rSeries
system includes support for using a remote authentication server to store system user accounts. After you have created system accounts on the remote server (using the server vendor's instructions), you can configure the
rSeries
system to use that server type to authenticate and authorize users. You can enable all available remote authentication methods and use either the CLI or webUI to indicate the order in which you would like the methods to be attempted when a user logs in.

Enable remote authentication from the webUI

If you want to use a remote authentication server with your
rSeries
system, you can configure remote authentication from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Authentication Methods
    , from the
    Available
    list, select one or more options and click the arrows to move them to the
    Selected
    list.
    The authentication server must be configured and reachable from the system.
    The
    Local (Always Selected)
    option is always enabled and cannot be changed. Local authentication is always enabled, by default, so the administrator can always access the system in case of external authentication server failure.
  4. Click
    Show
    to display additional settings, as needed, such as those in the Common LDAP Configuration area.
    This is required only if you want to use LDAP and create LDAP server groups with LDAP servers.
  5. Click
    Save
    .
When a user logs in, the system attempts to authenticate them against the configured authentication methods. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

Configure remote authentication priority from the webUI

You can configure the order in which the
rSeries
system attempts authentication methods when a user logs in to the system from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Authentication Methods
    , from the
    Selected
    list, select an authentication method and click the arrows to move it up or down in the list.
    The
    Local (Always Selected)
    option is always enabled and cannot be changed. Local authentication is always enabled, by default, so the administrator can always access the system in case of external authentication server failure.
  4. Click
    Save
    .

Create authentication server groups from the webUI

You can create authentication server groups to organize servers using the same type of authentication method.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Server Groups
    .
  3. Click
    Add
    .
  4. For
    Name
    , create a recognizable name for the server group.
  5. For
    Provider Type
    , select
    LDAP
    ,
    OCSP
    ,
    RADIUS
    , or
    TACACS+
    to qualify the type of servers that will be in the group.
  6. Click
    Save & Close
    .
You have created the authentication server group.
Next, you can add servers to the server group.

Edit servers to authentication server groups from the webUI

Before you add server groups, you must have previously created at least one server group.
You can add servers to an authentication server group from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Server Groups
    .
  3. Click the server group to which you want to add servers.
    The Edit Server Group screen displays.
  4. Click
    Add
    .
  5. Add server information for the server group.
    • Provider Type
      is set when you create the server group and cannot be changed.
    • For an LDAP server group, you can change the
      Port
      number or
      Type
      of the server.
      Select from these options:
      LDAP over TCP
      or
      LDAP over SSL
      (requires SSL certificate) depending on which protocol the LDAP server uses.
    • For an OCSP server group, you can change the
      Port
      number.
    • For a RADIUS server group, you can change the
      Port
      number,
      Secret
      (string or password), or
      Timeout
      (seconds to wait for a response from the server).
    • For a TACACS+ server group, you can change the
      Port
      number,
      Secret
      (string or password), or
      Source Address
      .
  6. Click
    Save & Close
    .
Add as many servers as needed to the authentication server group. OCSP server groups can contain only one OCSP server.

Group IDs (GIDs) and system authentication roles

Users with the admin role can configure the system to use these authentication methods to authenticate users:
  • External LDAP Server (includes Active Directory)
  • External RADIUS Server
  • External TACACS+ Server
  • Local (local UNIX authentication)
Each user role is internally mapped to a group ID. Users created and managed on external LDAP, Active Directory, RADIUS, or TACACS+ servers must have the same group IDs on the external servers as they do on
F5
rSeries
systems to enable authentication and authorization to occur on
rSeries
systems. Users created on external LDAP, Active Directory, RADIUS, or TACACS+ servers must be associated with one of these group IDs on the system.
You can only use existing roles and cannot create new roles.
The group IDs are specified in a user configuration file on the external server (file locations vary on different servers). You can assign these F5 user attributes:
F5-F5OS-UID=1001 F5-F5OS-GID=9000 <-- Required; must match with the GID of a role in F5OS (or correspond to the ‘remote-gid’ configured for a role) F5-F5OS-HOMEDIR=/tmp <-- Optional; prevents sshd warning msgs F5-F5OS-USERINFO=test_user <-- Optional user info F5-F5OS-SECONDARYGIDS <-- Optional; comma-separated list of secondary GIDs. Must match with the GID of a role in F5OS (or correspond to the 'remote-gid' for a role). F5-F5OS-SHELL=/bin/bash <-- Ignored; always set to /var/lib/controller/f5_confd_cli
Setting
F5-F5OS-HOMEDIR=/tmp
is a good idea to avoid warning messages from sshd that the directory does not exist. Also, the source address in the TACACS+ configuration is not used by the
rSeries
system.
The F5-F5OS-UID field is deprecated and no longer used by the F5OS systems. Even if configured on the remote server, the value will be ignored by the F5OS systems. Instead, the F5OS system assigns the user a unique UID during authentication. Once assigned, the user keeps its UID across different sessions on the same system. F5-F5OS-GID is required; if not set, user authentication will fail. The F5-F5OS-USERINFO is a comment field. Essentially, F5-F5OS-GID is the only hard requirement and must coincide with the group ID's user role.

Group IDs for system roles

This table lists the default group IDs for system roles.
Role
Group ID
admin
9000
operator
9001
resource admin
9003
tenant-console
9100
user
9002
superuser
9004

Group ID configuration examples

RADIUS server

The user configuration file is often named
/etc/raddb/users
. This is an example of an entry for an administrator with admin privileges:
radius_user Cleartext-Password := test F5-F5OS-UID := 1001, F5-F5OS-GID := 9000, F5-F5OS-SECONDARYGIDS := “9004”, F5-F5OS-HOMEDIR := "/tmp", F5-F5OS-SHELL := "/var/lib/controller/f5_confd_cli"

TACACS+ server

For example, on a TACACS+ server, the user configuration file is typically named
/etc/tac_plus.conf
. This is an example of an entry for an administrator with admin privileges:
group = admin { service = ppp protocol = ip { default attribute=permit F5-F5OS-UID=1001 F5-F5OS-GID=9000 F5-F5OS-HOMEDIR=/tmp F5-F5OS-USERINFO=test_user } } user = test_tacacs_user { global = cleartext "test-tacplus" member = admin }

Display user roles from the CLI

You can display the administrator roles with their associated group IDs from the CLI using an account with admin or operator access.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Display user roles for the system.
    show system aaa authentication roles
    A summary similar to this example displays:
    appliance-1# show system aaa authentication roles REMOTE LDAP ROLENAME GID GID GROUP DESCRIPTION USERS ----------------------------------------------------------------------------------------------------------------------------- admin 9000 - - Unrestricted read/write access. - operator 9001 - - Read-only access to system level data. - resource-admin 9003 - - Restricted read/write access. No access to modify authentication configuration. - superuser 9004 - - Sudo privileges and Bash access to the system (if enabled). - user 9002 - - Read-only access to non-sensitive system level data. -

Custom remote group IDs (GIDs)

Using an account with admin or operator access, you can configure a custom remote group ID (GID) for all remote authentication methods (LDAP, TACACS+, RADIUS). For example, this enables LDAP administrators to specify admin and operator groups, and then associate those GIDs to the associated roles rather than the hard-coded 9000 and 9001. The default GID fields (that is, 9000 and 9001) are not affected, and the system maps the remote GID to the default GID.
You can configure multiple remote authentication methods at a time but can only assign one remote GID to a specific primary GID. If you switch from LDAP to RADIUS, for example, you will have to reconfigure the settings for RADIUS. If you then decide to go back to LDAP, you will have to reconfigure it again. F5 recommends that you avoid assigning multiple F5-mapped GIDs to a single user account.

Configure remote group IDs (GIDs) from the CLI

Using an account with admin or operator access, you can configure a custom group ID (GID) for all remote authentication methods (LDAP, TACACS+, RADIUS) from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure a remote GID.
    system aaa authentication roles role <
    role-name
    > config remote-gid
    This example assigns a remote GID to the admin user:
    appliance-1(config)# system aaa authentication roles role admin config remote-gid (<unsignedInt>) (9000): 6000
  4. Commit the configuration changes.
    commit
  5. Return to user (operational) mode.
    end
  6. Verify that the operator user role is assigned the custom remote GID.
    show system aaa authentication roles
    A summary similar to this example displays:
    appliance-
    1
    # show system aaa authentication roles
    REMOTE LDAP
    ROLENAME GID GID GROUP DESCRIPTION USERS
    -----------------------------------------------------------------------------------------------------------------------------
    admin
    9000
    6000
    - Unrestricted read/write access. -
    operator
    9001
    - - Read-only access to system level data. -
    resource-admin
    9003
    - - Restricted read/write access. No access to modify authentication configuration. -
    superuser
    9004
    - - Sudo privileges and Bash access to the system (
    if
    enabled). -
    user
    9002
    - - Read-only access to non-sensitive system level data. -
Verify that the remote GID for the user matches the GID on the remote authentication server.

Configure LDAP group name from the CLI

Using an account with admin access, you can configure a LDAP group name for the LDAP authentication method from the CLI. One group name can be configured for every role. The LDAP group must be in the form of a LDAP query, such as "cn=...." or "dn=....".
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure a remote GID.
    system aaa authentication roles role <
    role-name
    > config ldap-gid
    The following example assigns a LDAP group to the admin user:
    appliance-1(config)# system aaa authentication roles role admin config ldap-group (<string>): cn=my_ldap_group
  4. Commit the configuration changes.
    commit
  5. Return to user (operational) mode.
    end
  6. Verify that the operator user role is assigned the custom remote LDAP group.
    show system aaa authentication roles
    A summary similar to this example displays:
    appliance-
    1
    # show system aaa authentication roles
    REMOTE
    ROLENAME GID GID LDAP GROUP DESCRIPTION USERS
    ----------------------------------------------------------------------------------------------------------------------------------------
    admin
    9000
    - cn=my_ldap_group Unrestricted read/write access. -
    operator
    9001
    - - Read-only access to system level data. -
    resource-admin
    9003
    - - Restricted read/write access. No access to modify authentication configuration. -
    superuser
    9004
    - - Sudo privileges and Bash access to the system (
    if
    enabled). -
    user
    9002
    - - Read-only access to non-sensitive system level data. -
    If both LDAP group and remote GID are configured for a role, the system considers the LDAP group for LDAP authentication. Therefore, only LDAP users in the LDAP groupare allowed into the system as the role. However, LDAP group configurations do not affect RADIUS and TACACS+ users. To avoid authentication failure for LDAP users, ensure to configure 'base' path for LDAP search. For more information, see LDAP/AD Configuration Overview

Configure custom remote group IDs (GIDs) and LDAP groups from the webUI

You can configure a custom remote group ID (GID) from the webUI to a specific role for all remote authentication methods (LDAP, RADIUS, TACACS+). You can also configure a LDAP group from the webUI to a specific role for the LDAP authentication method.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Users & Roles
    .
  3. In the
    Roles
    section, click
    Show
    to expand and view the configurations assigned to each role.
  4. Click on any role from the
    Role Name
    to edit the role. The
    Edit Role
    screen displays.
  5. Enter GID number and LDAP group name in the
    Remote GID
    and
    LDAP Group
    fields respectively.
    The LDAP group name must be a valid LDAP filter entry. For example, 'cn=my_ldap_group'.
    If both
    LDAP Group
    and
    Remote GID
    are configured for a role, the system considers the
    LDAP Group
    for LDAP authentication. Therefore, only LDAP users in the
    LDAP Group
    are allowed into the system as the role. However,
    LDAP Group
    configurations do not affect RADIUS and TACACS+ users. To avoid authentication failure for LDAP users, ensure to configure 'base' path for LDAP search. For more information, see LDAP/AD Configuration Overview.
  6. Click
    Save & Close
    .

LDAP/AD configuration overview

You can configure the
rSeries
system to use an LDAP or Microsoft Windows Active Directory (AD) server for authenticating
rSeries
system user accounts.
Before you begin:
  • Verify that the LDAP service is set up on a server that is accessible to the
    rSeries
    system. The default port for the LDAP service is 389 for unsecure protocol (LDAP) or 636 for secure protocol (LDAPS). If the service is configured with a different port, make note of it, as you will need that port number during configuration.
  • Import one or more LDAP certificates if you want to verify the certificate of the authentication server.
  • Assign users to valid system group IDs on the external LDAP or Active Directory servers. For more information, see Group IDs (GIDs) and system authentication roles.
  • For the system to recognize an Active Directory user, the user's uidNumber attribute must be set to a valid value. The gidNumber for important groups must also be set to a valid value. While these attributes are typically present in a basic LDAP configuration, they are often missing from a basic AD configuration.

LDAP/AD configuration from the webUI

Configure LDAP/AD authentication from the webUI

You can configure the use of LDAP/Active Directory (AD) authentication with
rSeries
systems from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Authentication Methods
    , from the
    Available
    list, select
    LDAP
    and click the arrows to move it to the
    Selected
    list.
    The LDAP server must be configured and reachable from the system.
    The
    Local (Always Selected)
    option is always enabled and cannot be changed. Local authentication is always enabled, by default, so the administrator can always access the system in case of external authentication server failure.
  4. In the Common LDAP Configuration area, click
    Show
    to expand the settings.
    The Common LDAP Configuration settings are required only if you want to use LDAP and create LDAP server groups with LDAP servers.
  5. For
    Base DN
    , type the base distinguished name (name-value pairs) from which to start the search for the LDAP user (for example,
    dc=example,dc=org
    ).
  6. For
    Bind
    , specify the information for binding the LDAP service account.
    1. For
      DN
      , enter the distinguished name with which to bind to the LDAP directory server for lookups (for example:
      cn=admin,dc=example,dc=org
      ).
    2. For
      Password
      , enter the admin password for the LDAP server.
      F5 recommends that the LDAP service account password is set to never expire. Otherwise, if it expires, LDAP authentication will not be possible and might result in users getting locked out of the system.
    3. For
      Confirm
      , retype the password.
    To clear the password, click
    Clear
    .
  7. For
    Connect Timeout
    , specify the maximum amount of time, in seconds, that the system waits before timing out when trying to reach the LDAP server.
  8. For
    Read Timeout
    , specify the maximum amount of time, in seconds, that the system waits to receive an LDAP response before aborting the read attempt.
  9. For
    Idle Timeout
    , specify the maximum amount of time, in seconds, that an LDAP connection can be inactive before the connection is closed.
  10. For
    LDAP Version
    , select the version of the LDAP protocol to use.
    The default value is
    3
    .
  11. For
    Chase Referrals
    , select whether to enable LDAP referral chasing.
    The default value is
    True
    , which specifies that the system queries all LDAP servers in the domain. This might cause delays and timeouts when authenticating against an LDAP server.
  12. If the LDAP server has Transport Layer Security (TLS) support, from
    TLS
    , select whether to use TLS to encrypt the transfer of authentication data between the LDAP server and the system.
    Option
    Description
    On
    Use TLS to secure all connections.
    Off
    Do not use TLS.
    StartTLS
    Starts a connection in unencrypted mode on a port configured for plain text and negotiates the encryption with the client. If selected, it is used rather than raw LDAP over SSL.
    If set to
    On
    or
    StartTLS
    , additional TLS-related fields are enabled.
  13. For
    TLS Certificate Validation
    , specify what checks to perform on a server-supplied certificate
    Option
    Description
    Never
    TLS certificate is not required.
    Allow
    Allow the connection. The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it is ignored and the session proceeds normally.
    Try
    Request the TLS certificate. The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated.
    Demand
    Request the certificate. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated.
    Hard
    Request the certificate. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated.
  14. For
    TLS CA Certificate
    , click
    Show
    and paste the contents of the X.509 certificate (self-signed or from a CA) for peer authentication.
  15. For
    Cipher String
    , enter the cipher string to specify the type of encryption to use (for example, ECDHE-RSA-AES256-GCM-SHA384 or ECDHE-RSA-AES128-GCM-SHA256).
    The cipher string can take several additional forms. It can consist of a single cipher suite such as RC4-SHA. It can represent a list of cipher suites containing a certain algorithm, or cipher suites of a certain type. For example, SHA1 represents all cipher suites using the digest algorithm SHA1, and SSLv3 represents all SSLv3 algorithms.
    You can combine lists of cipher suites into a single cipher string using the + character as a logical AND operation. For example, SHA1+DES represents all cipher suites containing the SHA1 and DES algorithms.
    For additional information, see the ciphers man page at www.openssl.org/docs/manpages.html.
  16. In the
    TLS Certificate
    field, click
    Show
    and paste the text of the local certificate for client TLS authentication.
  17. In the
    TLS Key
    field, click
    Show
    and paste the text of the private key for client TLS authentication.
  18. For
    Authenticate with Active Directory
    , select
    True
    if you want LDAP to authenticate against an Active Directory (AD) server.
  19. For
    Unix Attributes
    ,
    1. Select
      True
      (default) to use the
      gidNumber
      attribute for user and group role mapping.
    2. Select
      False
      to automatically synthesize a
      gidNumber
      for role mapping from the Microsoft
      objectSid
      attribute.
    Unix Attributes
    is only applicable when
    Active Directory
    is set to
    True
    . When
    Active Directory
    is set to
    False
    ,
    Unix Attributes
    is ignored and the
    gidNumber
    attribute is required.
  20. Click
    Save
    .
LDAP/AD authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.
Next, you can create a server group.

Configure an LDAP/AD server group from the webUI

You can configure an LDAP/Active Directory (AD) server group from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Server Groups
    .
  3. Click
    Add
    .
  4. For
    Name
    , create a recognizable name for the server group.
  5. For
    Provider Type
    , select
    LDAP
    to qualify the type of servers that will be in the group.
  6. Click
    Save & Close
    .
  7. Click the server group to which you want to add servers. The
    Edit Server Group
    screen displays.
    1. For
      Server
      , type the IPv4, IPv6 address, or FQDN of the LDAP server to add.
    2. For
      Port
      , make sure the port number is correct for LDAP traffic.
      The default value is
      636
      .
    3. From the
      Type
      list, select
      LDAP over TCP
      or
      LDAP over SSL
      (secured) depending on which is supported.
  8. Click
    Save & Close
    .
Add as many servers as needed to the group.

LDAP/AD configuration from the CLI

Configure LDAP/Active Directory authentication from the CLI

You can configure LDAP/Active Directory authentication from the CLI. You can also create an LDAP server group (including Active Directory servers), if you have multiple external LDAP servers to which you want to connect.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Set the authentication method to LDAP.
    system aaa authentication config authentication-method LDAP_ALL
  4. Commit the configuration changes.
    commit
  5. Set the LDAP or Active Directory configuration details.
    system aaa authentication ldap active_directory {
    true
    |
    false
    } base <
    dn-name
    > bind_timelimit <
    number-of-seconds
    > binddn <
    dn-acct-info
    > bindpw <
    password
    > chase-referrals {
    true
    |
    false
    } idle_timelimit <
    number-of-seconds
    > ldap_version <
    version-number
    > ssl {
    on
    |
    off
    |
    start_tls
    } timelimit <
    number-of-seconds
    > tls_cacert <
    path-to-cert>
    tls_cert <
    path-to-cert
    > tls_ciphers <
    cipher-suite
    > tls_key <
    path-to-file
    > tls_reqcert {
    never
    |
    allow
    |
    try
    |
    demand
    |
    hard
    }
    This example specifies a search base distinguished name for LDAP authentication:
    appliance-1(config)# system aaa authentication ldap base dc=example,dc=local
    This example enables Active Directory authentication, by setting the
    active_directory
    option to true:
    appliance-1(config)# system aaa authentication config authentication-method LDAP all system aaa authentication ldap active_directory true
  6. Add the LDAP/AD server details to the authentication server groups.
    1. Create a server group.
      system aaa server-groups server-group <
      group-name
      > config name <
      group-name
      > type LDAP
      This example creates an LDAP server group named
      ldap-group
      :
      appliance-1(config)# system aaa server-groups server-group ldap-group config name ldap-group type LDAP
    2. Add a server to the server group.
      servers server <
      ip-address
      > config address <
      ip-address
      >
      This example adds a server at specified IP address:
      appliance-1(config-server-group-ldap-group)# servers server 192.0.2.21
    3. Customize other LDAP configuration details, as needed.
      ldap config auth-port <
      port-number
      > type {
      ldap
      |
      ldaps
      }
      This example shows configuring a port number and LDAP over SSL.
      appliance-1(config-server-192.0.2.21)# ldap config auth-port 636 type ldaps
    4. Exit to the top level.
      top
    5. Add the host name for the LDAP service.
      This host name might have to be resolved in
      /etc/hosts
      or by DNS.
      system aaa server-groups server-group <
      group-name
      > servers server <
      host-name
      >
      This example adds a host name to the LDAP service:
      appliance-1(config)# system aaa server-groups server-group ldap-group servers server ldap.company.com
    6. Commit the configuration changes.
      commit
LDAP/AD authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

Add LDAP certificates from the CLI

You can add the LDAP certificates and key from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Add the TLS config key:
    system aaa tls config key (<
    AES-encrypted-string
    >)
    Press Enter to enable multi-line mode and paste the contents. Press Ctrl-D to exit multi-line mode.
    A summary similar to this example displays:
    appliance-1(config)# system aaa tls config key (<AES encrypted string>): [Multiline mode, exit with ctrl-D.] > -----BEGIN PRIVATE KEY----- > MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDarxbhnYlm8DoQ > W23fxEm6qZF5+DEBinym3IAZe7V3eV/v1UmuqSMKmz3pLX5oYTZ0Fqj+mW4XdMxK > kW93w91xYLZoOOn/P9ELt4Cu9YIoDTy3OU68EETjQarw9wd+0/JqKTRPWa+VAWGn > hMg6N2OCY7hNc8FWFU2YD2x6MryacVCgCi20uhzde2G89pJlqGrm9KpbCN1ZV4Hc > 4OWEnMAO/yyb8FceKQNgJ0pk9+kBosKfyYypZ8SjP9Bg4E76of5xMHBtbXNu/f3Y > hJk/0gmMyuoTKl5d9AAUhU+gOZP6z2GTc2UfWnG0dfG6SWUGVmBtZ8u8y3nPi7Y9 > G1K5R3TzAgMBAAECggEAVamQhQB4+mHP3OhzudviJcSWv/iA+eGNwq9NXq4e/5YE > Bqa+HjUTDOyS6+xuP+UUt5TIzjK79WRDQlKGH5wR+n+v9FOXFe2hrb1MIzz4p0fI > KN3CAdk9oufuVkXuIbhUlVFetFalePD5l+1joapgyIrXfz+A1H+zzYT9MUD+sGBJ > bYkTqxFgAwsJoMaPruemfzFLHeWRDh/o0fG7aA6v4AA+urIaK13bEs+U/38A6D4X > j+Mzr2RP4bQJHBKE5vYJ0bwqfO3we21CPYpkla4APJUNGOLuZwfGhH1QREQy31rA > sIru7KRBcxYikvfKI4oL8aUfPurcZbnaCD1bdUhlQQKBgQD3lQ4Qp53c3QGww/bQ > s0tvJD6T86t5ve47j0V6hKHbp8Kq/zm+3jkRVNjH8nipyleQ44YJuSqPfo4EVKLC > OYPDEEQP+2fAWmt1LUugoB/ilQHOHMJVuPUj9Hyt7wetp1EeFZqNqpgohdP9eM5/ > R8jSIuNhqIjPKTliqwOn4hLnvwKBgQDiHoE/O87/GadvmS/G6ExWFAE2j7l16y1f > pz/cqY/p674TF/VUYsyKaLKM08iOhT6XeDACto+z7TYd5YNYAgawuxcDvDWXOZxe > mWLpdzlQGzumeTz2Rsx3U3NnXETlGBWEjj6kAUq4oqFrRSBNGbHb4D7XVNuQPPSX > rZ8CfNxfzQKBgG/rZ7JLs2c2WR9JVve9NWqGnetQCcI9A8bU23mpH2omii+2tKn9 > 1xpomp64k6ddmvwafmtC02SOtzBp+jGGwnOZlMsMwTgJJ+6OjVONTxykc25zPb52 > oAqi6QHPvk7YBiltZrKH3cTjypMY23BaSQQFVXi+MSpE3nYmDL8FyboNAoGAVIDp > 9GO5nAROWpp5DHDL9m9LdMSJntPhBRpP93s22UjMo/4UJRE3N5KhB5guH3UUSy8T > YjAvzCIeU1Xum/lF3s5Mb4zqyjUxhvjzyiRQOuuygyhT7AXRa9a4DiyhYqx5fixa > pJgHALFmedw/khDEM1O+qGKCG4lsLzMndZqMERECgYEA5LQ128pxYmpp3lyK6a62 > 01W/1/BtuiApuEFdcqwk6MTtateS5Kpb5uA9orWISmtd7mZLcXZGTBuJEoWsHBs4 > BE/B1urijsnmFzGRwmwF9DwhhDuyLW/cAqQSWAb4IBkU0lo0MOwm80EgcLwoy/53 > zicLAzdPQOiNQEyIh5U46xg= > -----END PRIVATE KEY-----
  4. Add the TLS config certificate.
    system aaa tls config certificate (<
    string
    >)
    Press Enter to enable multi-line mode and paste the contents. Press Ctrl-D to exit multi-line mode.
    In this example, you add a certificate:
    appliance-1(config)# system aaa tls config certificate (<string>): [Multiline mode, exit with ctrl-D.] > -----BEGIN CERTIFICATE----- > MIIESzCCAzOgAwIBAgIJALgGgs+5qgX1MA0GCSqGSIb3DQEBCwUAMIG7MQswCQYD > VQQGEwItLTESMBAGA1UECAwJU29tZVN0YXRlMREwDwYDVQQHDAhTb21lQ2l0eTEZ > MBcGA1UECgwQU29tZU9yZ2FuaXphdGlvbjEfMB0GA1UECwwWU29tZU9yZ2FuaXph > dGlvbmFsVW5pdDEeMBwGA1UEAwwVbG9jYWxob3N0LmxvY2FsZG9tYWluMSkwJwYJ > KoZIhvcNAQkBFhpyb290QGxvY2FsaG9zdC5sb2NhbGRvbWFpbjAeFw0yMDEwMjMy > MjMwNTZaFw0yMTEwMjMyMjMwNTZaMIG7MQswCQYDVQQGEwItLTESMBAGA1UECAwJ > U29tZVN0YXRlMREwDwYDVQQHDAhTb21lQ2l0eTEZMBcGA1UECgwQU29tZU9yZ2Fu > aXphdGlvbjEfMB0GA1UECwwWU29tZU9yZ2FuaXphdGlvbmFsVW5pdDEeMBwGA1UE > AwwVbG9jYWxob3N0LmxvY2FsZG9tYWluMSkwJwYJKoZIhvcNAQkBFhpyb290QGxv > Y2FsaG9zdC5sb2NhbGRvbWFpbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC > ggEBANqvFuGdiWbwOhBbbd/ESbqpkXn4MQGKfKbcgBl7tXd5X+/VSa6pIwqbPekt > fmhhNnQWqP6Zbhd0zEqRb3fD3XFgtmg46f8/0Qu3gK71gigNPLc5TrwQRONBqvD3 > B37T8mopNE9Zr5UBYaeEyDo3Y4JjuE1zwVYVTZgPbHoyvJpxUKAKLbS6HN17Ybz2 > kmWoaub0qlsI3VlXgdzg5YScwA7/LJvwVx4pA2AnSmT36QGiwp/JjKlnxKM/0GDg > Tvqh/nEwcG1tc279/diEmT/SCYzK6hMqXl30ABSFT6A5k/rPYZNzZR9acbR18bpJ > ZQZWYG1ny7zLec+Ltj0bUrlHdPMCAwEAAaNQME4wHQYDVR0OBBYEFJ8f90ExRYYD > 0j2rQSKhMbRaKz0vMB8GA1UdIwQYMBaAFJ8f90ExRYYD0j2rQSKhMbRaKz0vMAwG > A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBACzFSIiJ01qLtl9Nom5rtFRh > m+iH0RewmO2YV9rQTl53shma1/Wa2D5PXsFt6w0wiXRa6Gab1YVxaHkP9E4RK6us > B5s5pR+SijP02Ijw5y4RICegkWApx86wlW09NDBgPFQdz+xQnpx8LfAFDzkAEf02 > eI4SI25Vi3fDW6qeOKeQmS5itcRFXBi/E2+FwYu3zvtMEIp7WB90f0mvxiEd1bz8 > UY0pODHlYUzc/4jl9CGWGPl+80KHsjppqwsFzZs3koe2IyKbzMKfpdQ+oIiJP17+ > IVJgNbRCO5TgGXtFW3p3CJ2fHzEPongFdvbPOTr/cE/KkGxKqcoeN7d22g7POas= > -----END CERTIFICATE-----
  5. Commit the configuration changes.
    commit

RADIUS configuration overview

You can configure the
rSeries
system to use a RADIUS server for authenticating
rSeries
system user accounts.
Before you begin, you must verify that the RADIUS service is set up on a server that is accessible to the
rSeries
system. The default port for RADIUS service is 1812. If the service is configured with a different port, make note of it, as you will need it during the configuration.

RADIUS dictionary

When configuring remote RADIUS authentication for the
F5
system, you add these
F5OS
vendor-specific attributes (VSA) to the
F5
vendor-specific RADIUS dictionary file on the RADIUS server. Be sure to add the vendor lines if you are using the RADIUS server for the first time.
VENDOR F5 3375 BEGIN-VENDOR F5 ATTRIBUTE F5-F5OS-UID 21 integer ATTRIBUTE F5-F5OS-GID 22 integer ATTRIBUTE F5-F5OS-HOMEDIR 23 string ATTRIBUTE F5-F5OS-SHELL 24 string ATTRIBUTE F5-F5OS-USERINFO 25 string ATTRIBUTE F5-F5OS-SECONDARYGIDS 26 string END-VENDOR F5

RADIUS configuration from the webUI

Configure RADIUS authentication from the webUI

You can configure the use of RADIUS authentication with
rSeries
systems from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Authentication Methods
    , from the
    Available
    list, select
    RADIUS
    and click the arrows to move it to the
    Selected
    list.
    The RADIUS server must be configured and reachable from the system.
    The
    Local (Always Selected)
    option is always enabled and cannot be changed. Local authentication is always enabled, by default, so the administrator can always access the system in case of external authentication server failure.
  4. Click
    Save
    .
RADIUS authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.
Next, you can create a server group.

Configure a RADIUS server group from the webUI

You can configure a RADIUS server group from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Server Groups
    .
  3. Click
    Add
    .
  4. For
    Name
    , create a recognizable name for the server group.
  5. For
    Provider Type
    , select
    RADIUS
    to qualify the type of servers that will be in the group.
  6. Click
    Save & Close
    .
  7. Click the server group to which you want to add servers.
    The Edit Server Group screen displays.
  8. For
    Server
    , enter the IPv4, IPv6 address, or FQDN of the RADIUS server to add.
  9. For
    Port
    , make sure the port number is correct for RADIUS traffic.
    The default value is
    1812
    .
  10. For
    Secret
    , enter the shared secret used to access the server.
  11. For
    Timeout (seconds)
    , type the number of seconds to timeout if unable to access the server.
    The default value is
    5
    .
  12. Click
    Save & Close
    .
Add as many servers as needed to the group.

RADIUS configuration from the CLI

Configure RADIUS authentication from the CLI

You can configure the system for RADIUS authentication from the CLI. You can also create a RADIUS server group, if you have multiple external RADIUS servers to which you want to connect.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Set the authentication method to RADIUS.
    system aaa authentication config authentication-method RADIUS_ALL
  4. Commit the configuration changes.
    commit
  5. Add the RADIUS service details to the authentication server groups:
    1. Create a server group.
      system aaa server-groups server-group <
      group-name
      > config name <
      group-name
      > type RADIUS
      This example creates an RADIUS server group named
      radius-group
      :
      appliance-1(config)# system aaa server-groups server-group radius-group config name radius-group type RADIUS
    2. Add a server to the server group.
      servers server <
      ip-address
      > config address <
      ip-address
      >
      This example adds a server at specified IP address:
      appliance-1(config-server-group-radius-group)# servers server 192.0.2.20
    3. Customize other RADIUS configuration details, as needed.
      radius config auth-port <
      port-number
      > secret-key <
      secret
      > timeout <
      timeout-in-seconds
      >
      This example shows configuring a port number:
      appliance-1(config-server-192.0.2.20)# radius config port 1812
    4. Commit the configuration changes.
      commit
RADIUS authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

TACACS+ configuration overview

You can configure the
rSeries
system to use a TACACS+ server for authenticating
rSeries
system user accounts.
Before you begin:

TACACS+ configuration from the webUI

Configure TACACS+ authentication from the webUI

You can configure the use of TACACS+ authentication with
rSeries
systems from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Authentication Methods
    , from the
    Available
    list, select
    TACACS+
    and click the arrows to move it to the
    Selected
    list.
    The TACACS+ server must be configured and reachable from the system.
    The
    Local (Always Selected)
    option is always enabled and cannot be changed. Local authentication is always enabled, by default, so the administrator can always access the system in case of external authentication server failure.
  4. Click
    Save
    .
TACACS+ authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.
Next, you can create a server group.

Configure a TACACS+ server group from the webUI

You can configure a TACACS+ server group from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Server Groups
    .
  3. Click
    Add
    .
  4. For
    Name
    , create a recognizable name for the server group.
  5. For
    Provider Type
    , select
    TACACS+
    to qualify the type of servers that will be in the group.
  6. Click
    Save & Close
    .
  7. Click the server group to which you want to add servers.
    The Edit Server Group screen displays.
  8. Click
    Add
    .
  9. For
    Server
    , type the IPv4, IPv6 address, or FQDN of the TACACS+ server to add.
  10. For
    Port
    , make sure the port number is correct for TACACS+ traffic.
    The default value is
    49
    .
  11. For
    Secret
    , enter the shared secret used to access the server.
  12. Click
    Save & Close
    .
Add as many servers as needed to the group.

TACACS+ configuration from the CLI

Configure TACACS+ authentication from the CLI

You can configure TACACS+ authentication from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Set the authentication method to TACACS+.
    system aaa authentication config authentication-method TACACS_ALL
  4. Commit the configuration changes.
    commit
  5. Add the TACACS+ service details to the authentication server groups.
    1. Create a server group.
      system aaa server-groups server-group <
      group-name
      > config name <
      group-name
      > type TACACS
      This example creates a TACACS+ server group named
      tacacs-group
      :
      appliance-1(config)# system aaa server-groups server-group tacacs-group config name tacacs-group type TACACS
    2. Add a server to the server group.
      servers server <
      ip-address
      > config address <
      ip-address
      >
      This example adds a server at specified IP address:
      appliance-1(config-server-group-tacacs-group)# servers server 192.0.2.22
    3. Customize other TACACS+ configuration details, as needed.
      tacacs config port <
      port-number
      > secret-key <
      secret
      > source-address <
      ip-address
      >
      This example shows configuring a port number:
      appliance-1(config-server-192.0.2.22)# tacacs config port 49
    4. Commit the configuration changes.
      commit
TACACS+ authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

OCSP configuration overview

Admin users can configure the
rSeries
system to use Online Certificate Status Protocol (OCSP) to verify certificate validity and revoke expired certificates. The system sends an OCSP request, which includes the certificate serial number, to an OCSP responder, and receives a response with the certificate status (good, revoked, or unknown). OCSP is a similar to CRL checking, and you can configure the system to use both at the same time.

OCSP configuration from the webUI

Configure OCSP for certificate validation from the webUI

You can configure Online Certificate Status Protocol (OCSP) for certificate validation from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. In the OCSP Configuration area, click
    Show
    to expand the settings.
  4. For
    OCSP Checking
    , select
    Disabled
    or
    Enabled
    .
    The default value is Disabled.
  5. In the OCSP Configuration area, for
    Nonce Request
    , specify whether queries to OCSP responders should include a nonce (a unique identifier) in the request.
  6. For
    Override Responder
    , specify whether the OCSP default responder is required for certificate validation.
  7. For
    Response Max Age
    , specify the maximum amount of time, in seconds, for Online Certificate Status Protocol (OCSP) responses.
  8. For
    Response Time Skew
    , specify the maximum allowable time skew, in seconds, for Online Certificate Status Protocol (OCSP) response validation.
  9. Click
    Save
    .
Next, you can create a server group.

Configure an OCSP server group from the webUI

You can configure an Online Certificate Status Protocol (OCSP) server group from the webUI. The server group can contain only one OCSP server.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Server Groups
    .
  3. Click
    Add
    .
  4. For
    Name
    , create a recognizable name for the server group.
  5. The
    Provider Type
    , select
    OCSP
    to qualify the type of servers that will be in the group.
  6. Click
    Save & Close
    .
  7. Click the server group to which you want to add servers.
    The Edit Server Group screen displays.
  8. For
    Host
    , type the IPv4 address, IPv6 address, or the fully qualified domain name (FQDN) of the OCSP server.
  9. For
    Port
    , enter the port for the OCSP server.
    The default value is 80.
  10. Click
    Save
    .
The OSCP server is added to the server group.

OCSP configuration from the CLI

Configure OCSP for certificate validation from the CLI

You can configure Online Certificate Status Protocol (OCSP) for certificate validation from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Enable OCSP.
    system aaa authentication ocsp config enabled
  4. Configure the OCSP responder address that will be used for client certificate validation using one of these methods:
    • Provide the OCSP responder address using the client certificate.
      appliance-1(config)# system aaa authentication ocsp config override-responder off
    • Provide the OCSP IP address using a server group.
      appliance-1(config)# system aaa authentication ocsp config override-responder on appliance-1(config)# system aaa server-groups server-group ocsp1 config name ocsp1 type OCSP appliance-1(config-server-group-ocsp1)# servers server 192.0.2.10 appliance-1(config-server-192.0.2.10)# config address 192.0.2.10 appliance-1(config-server-192.0.2.10)# ocsp config port 23456
  5. Configure additional OCSP options, if needed.
    The system creates the responder address using default values for
    nonce-request
    (
    on
    ) and
    response-time-skew
    (
    300
    ).
    system aaa authentication ocsp config nonce-request {
    off
    |
    on
    } response-max-age <
    time-in-seconds
    > response-time-skew <
    time-in-seconds
    >
    For
    nonce-request
    , the default value is
    on
    . For
    response-max-age
    , the default value is
    -1
    , which disables the maximum age check. The range is from -1 to 214748364. For
    response-time skew
    , the default value is
    300
    .
  6. Commit the configuration changes.
    commit
Next, you can create a server group.

Configure an OCSP server group from the CLI

You can configure an Online Certificate Status Protocol (OCSP) server group from the CLI. The server group can contain only one OCSP server.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Create an OCSP server group.
    system aaa server-groups server-group <
    group-name
    > config name <
    group-name
    > type OCSP
    This example creates an OCSP server group named
    ocsp-group
    :
    appliance-1(config)# system aaa server-groups server-group ocsp-group config type OCSP
  4. Add an OCSP server to the server group.
    servers server <
    ip-address
    > config address <
    ip-address
    >
    This example adds a server at a specified IP address, with the default value for port number (
    80
    ):
    appliance-1(config-server-group-ocsp-group)# servers server 192.0.2.25 ocsp config port 88
  5. Commit the configuration changes.
    commit

SSH public key authentication overview

Using SSH public key authentication to connect to a remote system is a robust, more secure alternative to logging in with an account password or passphrase. SSH public key authentication relies on asymmetric cryptographic algorithms that generate a pair of separate keys (a key pair), one "private" and the other "public". You keep the private key a secret and store it on the computer you use to connect to the remote system.

Configure SSH public key authentication from the CLI

You can configure Secure Shell (SSH) public key authentication from the CLI. You can configure multiple authorized keys in one step. This feature supports all SSH key algorithms that are supported in the latest SSHD version. Root users cannot use this feature.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure SSH public key authentication.
    system aaa authentication users user <
    username
    > config authorized_keys
    Press Enter to enable multi-line mode and paste the contents. Paste the first SSH public key into the prompt, press enter to paste the next key, and continue until you have entered all keys. Press Ctrl-D to exit multi-line mode.
    In this example, you configure public key authentication for a specified user:
    appliance-1(config)# system aaa authentication users user jdoe config authorized_keys (<string, min: 1 chars>): [Multiline mode, exit with ctrl-D.] > hdsjhfashlksdfklahkjdhsakfdhaskhfkjasdhfjashd
  4. Commit the configuration changes.
    commit

Delete SSH public key authentication from the CLI

You can delete a Secure Shell (SSH) public key authentication from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Remove the authorized key.
    no system aaa authentication users user <
    username
    > config authorized_keys
  4. Commit the configuration changes.
    commit

Transport Layer Security (TLS) configuration overview

Before
rSeries
systems can exchange data with one another, they must exchange device certificates, that is, digital certificates and keys used for secure communication.
If you are using LDAP with transport layer security (TLS) for user authentication, you can choose to require TLS Certificate Validation in the authentication settings. You can add a certificate and key into the system, and when you create a certificate signing request (CSR), it saves the generated key and certificate to these directories:
  • system/aaa/tls/config/key
  • system/aaa/tls/config/certificate
When you install an SSL certificate, you also install a certificate authority (CA) bundle, which is a file that contains root and intermediate certificates. The CA bundle and server certificate complete the SSL chain of trust.
The
rSeries
system also supports using self-signed certificates.
You can also configure a Certificate Revocation List (CRL) entry for the system to use to check revocation status of a certificate prior to authenticating a client. Note that once you have configured a CRL, there must be a CRL certificate for each CA. If there are two CAs configured and one CRL is been added for one of the CAs, you need to provide a CRL for the other CA even if it is not revoked.
As an alternative to CRLs, you can also use Online Certificate Status Protocol (OCSP). You can configure the system to use both at the same time. For more information about OCSP, see OCSP configuration overview.
For information about client certification authentication, see Client certificate authentication overview.

Client certificate authentication overview

For enhanced security, users with admin access can configure the system so that webUI users use a client certificate to provide a username and authenticate before granting access to the
rSeries
system. The system verifies a user's identity by validating the client certificate against a list of trusted Certificate Authority (CA) certificates, and optionally checks the certificate status against a configured Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) responder. The system extracts the user name from the certificate and uses it to query an external server for group membership information for the user, which is used to determine what features they can access on the system. You can also configure client certificate authentication to work with an LDAP authentication provider.

Client certificate authentication from the webUI

Configure client certificate verification from the webUI
You can enable verification of httpd client certificates from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. In the Client Certificate Verification area, click
    Settings
    .
    The Client Certificate Verification screen displays.
  4. For
    Verify Client
    , select whether to enable client certificate verification.
    The default value is false (verification is disabled).
  5. For
    Client Depth
    , select the client certificate verification depth.
    The default value is 1, which indicates that the client certificate can be self-signed or must be signed by a Certificate Authority (CA) that is known to the server. A depth of 0 indicates that only self-signed client certificates are accepted. The range is from 0 to 100. The value you provide for depth indicates the maximum number of CA certificates allowed to be followed while verifying the client certificate. You might need to raise the default depth if you received more than one chained root certificate in addition to a client certificate from your CA.
  6. Click
    Save
    .
Log in to the system webUI using a client certificate
Before you can log in to the webUI using client certificate authentication, you must have configured client certificate authentication from the CLI and imported the certificate to your browser. This procedure varies depending on operating system and browser.
You can log in to the webUI using a client certificate for authentication.
  1. Connect to the webUI by entering the management IP address in your browser.
  2. On the login screen, review the client certificate authentication agreement, if available, and then click
    Log in
    .
  3. When prompted to select a certificate, select the certificate from the list and click
    OK
    .
    When authentication completes, the Dashboard displays. If you did not import a certificate to your browser, the authentication fails and displays an error message.

Client certificate authentication from the CLI

Configure client certificate verification settings from the CLI
You can configure client certificate verification settings from the CLI. The value you provide for depth indicates the maximum number of Certificate Authority (CA) certificates allowed to be followed while verifying the client certificate. You might need to raise the default depth if you received more than one chained root certificate in addition to a client certificate from your CA. The default depth of 1 indicates that the client certificate can be self-signed or must be signed by a CA that is known to the server. A depth of 0 indicates that only self-signed client certificates are accepted.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Specify whether to use client certificate verification.
    system aaa tls config verify-client {
    false
    |
    true
    }
    In this example, you enable client certificate verification:
    appliance-1(config)# system aaa tls config verify-client true
  4. Configure client certificate verification depth.
    The default value is 1. The range is from 1 to 100.
    system aaa tls config verify-client-depth <
    depth
    >
    In this example, you specify a depth of 10:
    appliance-1(config)# system aaa tls config verify-client-depth 10
  5. Commit the configuration changes.
    commit
Configure client certificate verification with self-signed certificates from the CLI
Before you configure client certificate verification on your system, you must first:
  • Create your self-signed certificates, ensuring that the CN name for the server is the server name from the client's perspective (either an IP address or fully-qualified domain name (FQDN)).
  • Configure the server name in your SSL server's httpd configuration files.
You can configure HTTP server SSL settings with client certificate verification and self-signed certificates from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Add the TLS config key:
    system aaa tls config key (<
    AES-encrypted-string
    >)
    Press Enter to enable multi-line mode and paste the contents. Press Ctrl-D to exit multi-line mode.
    A summary similar to this example displays:
    appliance-1(config)# system aaa tls config key (<AES encrypted string>): [Multiline mode, exit with ctrl-D.] > -----BEGIN PRIVATE KEY----- > MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDarxbhnYlm8DoQ > W23fxEm6qZF5+DEBinym3IAZe7V3eV/v1UmuqSMKmz3pLX5oYTZ0Fqj+mW4XdMxK > kW93w91xYLZoOOn/P9ELt4Cu9YIoDTy3OU68EETjQarw9wd+0/JqKTRPWa+VAWGn > hMg6N2OCY7hNc8FWFU2YD2x6MryacVCgCi20uhzde2G89pJlqGrm9KpbCN1ZV4Hc > 4OWEnMAO/yyb8FceKQNgJ0pk9+kBosKfyYypZ8SjP9Bg4E76of5xMHBtbXNu/f3Y > hJk/0gmMyuoTKl5d9AAUhU+gOZP6z2GTc2UfWnG0dfG6SWUGVmBtZ8u8y3nPi7Y9 > G1K5R3TzAgMBAAECggEAVamQhQB4+mHP3OhzudviJcSWv/iA+eGNwq9NXq4e/5YE > Bqa+HjUTDOyS6+xuP+UUt5TIzjK79WRDQlKGH5wR+n+v9FOXFe2hrb1MIzz4p0fI > KN3CAdk9oufuVkXuIbhUlVFetFalePD5l+1joapgyIrXfz+A1H+zzYT9MUD+sGBJ > bYkTqxFgAwsJoMaPruemfzFLHeWRDh/o0fG7aA6v4AA+urIaK13bEs+U/38A6D4X > j+Mzr2RP4bQJHBKE5vYJ0bwqfO3we21CPYpkla4APJUNGOLuZwfGhH1QREQy31rA > sIru7KRBcxYikvfKI4oL8aUfPurcZbnaCD1bdUhlQQKBgQD3lQ4Qp53c3QGww/bQ > s0tvJD6T86t5ve47j0V6hKHbp8Kq/zm+3jkRVNjH8nipyleQ44YJuSqPfo4EVKLC > OYPDEEQP+2fAWmt1LUugoB/ilQHOHMJVuPUj9Hyt7wetp1EeFZqNqpgohdP9eM5/ > R8jSIuNhqIjPKTliqwOn4hLnvwKBgQDiHoE/O87/GadvmS/G6ExWFAE2j7l16y1f > pz/cqY/p674TF/VUYsyKaLKM08iOhT6XeDACto+z7TYd5YNYAgawuxcDvDWXOZxe > mWLpdzlQGzumeTz2Rsx3U3NnXETlGBWEjj6kAUq4oqFrRSBNGbHb4D7XVNuQPPSX > rZ8CfNxfzQKBgG/rZ7JLs2c2WR9JVve9NWqGnetQCcI9A8bU23mpH2omii+2tKn9 > 1xpomp64k6ddmvwafmtC02SOtzBp+jGGwnOZlMsMwTgJJ+6OjVONTxykc25zPb52 > oAqi6QHPvk7YBiltZrKH3cTjypMY23BaSQQFVXi+MSpE3nYmDL8FyboNAoGAVIDp > 9GO5nAROWpp5DHDL9m9LdMSJntPhBRpP93s22UjMo/4UJRE3N5KhB5guH3UUSy8T > YjAvzCIeU1Xum/lF3s5Mb4zqyjUxhvjzyiRQOuuygyhT7AXRa9a4DiyhYqx5fixa > pJgHALFmedw/khDEM1O+qGKCG4lsLzMndZqMERECgYEA5LQ128pxYmpp3lyK6a62 > 01W/1/BtuiApuEFdcqwk6MTtateS5Kpb5uA9orWISmtd7mZLcXZGTBuJEoWsHBs4 > BE/B1urijsnmFzGRwmwF9DwhhDuyLW/cAqQSWAb4IBkU0lo0MOwm80EgcLwoy/53 > zicLAzdPQOiNQEyIh5U46xg= > -----END PRIVATE KEY-----
  4. Add the TLS config certificate.
    system aaa tls config certificate (<
    string
    >)
    Press Enter to enable multi-line mode and paste the contents. Press Ctrl-D to exit multi-line mode.
    In this example, you add a certificate:
    appliance-1(config)# system aaa tls config certificate (<string>): [Multiline mode, exit with ctrl-D.] > -----BEGIN CERTIFICATE----- > MIIESzCCAzOgAwIBAgIJALgGgs+5qgX1MA0GCSqGSIb3DQEBCwUAMIG7MQswCQYD > VQQGEwItLTESMBAGA1UECAwJU29tZVN0YXRlMREwDwYDVQQHDAhTb21lQ2l0eTEZ > MBcGA1UECgwQU29tZU9yZ2FuaXphdGlvbjEfMB0GA1UECwwWU29tZU9yZ2FuaXph > dGlvbmFsVW5pdDEeMBwGA1UEAwwVbG9jYWxob3N0LmxvY2FsZG9tYWluMSkwJwYJ > KoZIhvcNAQkBFhpyb290QGxvY2FsaG9zdC5sb2NhbGRvbWFpbjAeFw0yMDEwMjMy > MjMwNTZaFw0yMTEwMjMyMjMwNTZaMIG7MQswCQYDVQQGEwItLTESMBAGA1UECAwJ > U29tZVN0YXRlMREwDwYDVQQHDAhTb21lQ2l0eTEZMBcGA1UECgwQU29tZU9yZ2Fu > aXphdGlvbjEfMB0GA1UECwwWU29tZU9yZ2FuaXphdGlvbmFsVW5pdDEeMBwGA1UE > AwwVbG9jYWxob3N0LmxvY2FsZG9tYWluMSkwJwYJKoZIhvcNAQkBFhpyb290QGxv > Y2FsaG9zdC5sb2NhbGRvbWFpbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC > ggEBANqvFuGdiWbwOhBbbd/ESbqpkXn4MQGKfKbcgBl7tXd5X+/VSa6pIwqbPekt > fmhhNnQWqP6Zbhd0zEqRb3fD3XFgtmg46f8/0Qu3gK71gigNPLc5TrwQRONBqvD3 > B37T8mopNE9Zr5UBYaeEyDo3Y4JjuE1zwVYVTZgPbHoyvJpxUKAKLbS6HN17Ybz2 > kmWoaub0qlsI3VlXgdzg5YScwA7/LJvwVx4pA2AnSmT36QGiwp/JjKlnxKM/0GDg > Tvqh/nEwcG1tc279/diEmT/SCYzK6hMqXl30ABSFT6A5k/rPYZNzZR9acbR18bpJ > ZQZWYG1ny7zLec+Ltj0bUrlHdPMCAwEAAaNQME4wHQYDVR0OBBYEFJ8f90ExRYYD > 0j2rQSKhMbRaKz0vMB8GA1UdIwQYMBaAFJ8f90ExRYYD0j2rQSKhMbRaKz0vMAwG > A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBACzFSIiJ01qLtl9Nom5rtFRh > m+iH0RewmO2YV9rQTl53shma1/Wa2D5PXsFt6w0wiXRa6Gab1YVxaHkP9E4RK6us > B5s5pR+SijP02Ijw5y4RICegkWApx86wlW09NDBgPFQdz+xQnpx8LfAFDzkAEf02 > eI4SI25Vi3fDW6qeOKeQmS5itcRFXBi/E2+FwYu3zvtMEIp7WB90f0mvxiEd1bz8 > UY0pODHlYUzc/4jl9CGWGPl+80KHsjppqwsFzZs3koe2IyKbzMKfpdQ+oIiJP17+ > IVJgNbRCO5TgGXtFW3p3CJ2fHzEPongFdvbPOTr/cE/KkGxKqcoeN7d22g7POas= > -----END CERTIFICATE-----
  5. Enable client certificate verification.
    system aaa tls config verify-client {
    false
    |
    true
    }
    In this example, you enable client certificate verification:
    appliance-1(config)# system aaa tls config verify-client true
  6. Configure client certificate verification depth.
    The default value is 1. The range is from 1 to 100.
    system aaa tls config verify-client-depth <
    depth
    >
    In this example, you specify a depth of 10:
    appliance-1(config)# system aaa tls config verify-client-depth 10
  7. Add a CA bundle.
    system aaa tls ca-bundles ca-bundle <
    ca-bundle-name
    > config name <
    ca-bundle-name
    > content
    Press Enter to enable multi-line mode and paste the contents. Press Ctrl-D to exit multi-line mode.
    In this example, you add a CA bundle named "test_caaaa":
    appliance-1(config)# system aaa tls ca-bundles ca-bundle test_caaaa config name test_caaaa content (<string>): [Multiline mode, exit with ctrl-D.]
  8. Commit the configuration changes.
    commit
Configure client certificate authentication from the CLI
Before you configure client certificate authentication, be sure that you have enabled client certificate verification. For more information, see Configure client certificate verification settings from the CLI.
You can configure client certificate authentication settings on the
rSeries
system from the CLI.
Only users with admin access can configure client certificate authentication.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Enable client certificate authentication.
    system aaa authentication config cert-auth {
    disabled
    |
    enabled
    }
    In this example, you enable client certificate authentication:
    appliance-1(config)# system aaa authentication config cert-auth enabled
  4. Configure the client certificate name field if you want to use a custom OID value for the client certificate username.
    system aaa authentication clientcert config client-cert-name-field {
    san-gen-dns
    |
    san-gen-email
    |
    san-gen-othername
    OID { <
    OID
    > |
    UPN
    } |
    san-gen-uri
    |
    subjectname-cn
    }
    In these examples, you configure an OID using one of these valid formats:
    appliance-1(config)# system aaa authentication clientcert config client-cert-name-field san-gen-othername OID UPN
    appliance-1(config)# system aaa authentication clientcert config client-cert-name-field san-gen-othername OID 1.1
    appliance-1(config)# system aaa authentication clientcert config client-cert-name-field san-gen-othername OID 1.3.6.1.4.1.311.20.2.3
  5. Commit the configuration changes.
    commit
Next, you can configure the login banner with a client certificate agreement, if needed. For more information, see General system configuration overview.

Certificate management from the webUI

View a certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method in the system (
AUTHENTICATION & ACCESS
Authentication Settings
).
You can view a certificate from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. To display a
    TLS Certificate
    , a
    TLS Key
    that was previously installed, or the
    TLS Details
    , click
    Show
    .
    A text area opens and displays the certificate, key, or details.

View or configure a TLS key and certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method (
AUTHENTICATION & ACCESS
Authentication Settings
).
You can view or replace TLS device certificates from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. To display a previously-installed TLS certificate or key, or to install a TLS certificate or key, in the TLS Certificate & Key area, click
    Show
    .
    A text area opens and displays the certificate or key, if one has been previously installed.
  4. To install a
    TLS Certificate
    , paste the text of the local certificate for client TLS authentication into the text box.
  5. To install a
    TLS Key
    , paste the text of the local certificate for client TLS authentication into the text box.
    1. If the TLS key is encrypted, a TLS key passphrase is required. For
      TLS Key Passphrase
      , enter the passphrase.
  6. Click
    Save
    .

Configure a Certificate Authority (CA) bundle from the webUI

You can add or delete a Certificate Authority (CA) bundle from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. In the CA Bundles area, click
    Add
    .
    The Add CA Bundle screen displays.
  4. For
    Name
    , enter the bundle name.
  5. For
    TLS CA Certificate
    , paste the certificate text.
  6. Click
    Save
    .
  7. To delete a CA bundle, in the CA Bundles area, select the bundle name in the table and then click
    Delete
    .

Configure a Certification Revocation List (CRL) from the webUI

You can add or delete a Certificate Revocation List (CRL) from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. In the Certificate Revocation List area, click
    Add
    .
    The Add CRL screen displays.
  4. For
    Name
    , enter the list name.
  5. For
    Revocation Key
    , paste the revocation key.
  6. Click
    Save & Close
    .
  7. To delete a Certificate Revocation List, in the Certificate Revocation List area, select the list name in the table and then click
    Delete
    .

Create a self-signed certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method in the system (
AUTHENTICATION & ACCESS
Authentication Settings
).
You can create or view a self-signed certificate from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. In the Self-Signed Certificate area, click
    Create Certificate
    .
    The Create Certificate screen displays.
  4. In the
    Name
    field, enter a name for the certificate.
    For example, the server's hostname.
  5. In the
    Email
    field, enter the email address for the certificate contact.
  6. In the
    SAN
    field, enter additional domain names that you want to associate with the self-signed certificate.
  7. In the
    City
    field, enter the city or locality name.
  8. In the
    State
    field, enter the state, county, or region.
  9. In the
    Country
    field, enter the two-letter country code.
    For example, US for United States.
  10. In the
    Organization
    field, enter the certificate originator name.
    For example, your company's name.
  11. In the
    Unit
    field, enter the organizational unit name.
    For example, IT.
  12. In the
    Version
    field, specify the version number for the certificate.
  13. In the
    Days Valid
    field, specify the number of days the certificate is valid.
  14. For
    Key Type
    , select a key type.
    Available options are RSA, ECDSA, Encrypted RSA, or Encrypted ECDSA. If you select an encrypted option, the additional fields display.
    • For
      ECDSA
      , select the
      Curve Name
      .
    • For
      RSA
      , select the
      Key Size
      .
    • For
      Encrypted ECDSA
      , select the
      Curve Name
      , enter the
      Key Passphrase
      , and re-enter the key passphrase in the
      Confirm Key Passphrase
      to confirm.
    • For
      Encrypted RSA
      , select the
      Key Size
      , enter the
      Key Passphrase
      , and re-enter the key passphrase in the
      Confirm Key Passphrase
      to confirm.
    For
    Key Passphrase
    , the range is between 6 and 255 characters.
  15. In the
    Store TLS
    field, choose whether to store your TLS information.
  16. Click
    Save
    .

Create a Certificate Signing Request (CSR) from the webUI

You can create and view certificate signing requests (CSRs) from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    TLS Configuration
    .
  3. In the Certificate Signing Request area, click
    Create CSR
    .
    The Create CSR screen displays.
  4. In the
    Name
    field, enter the common name for the certificate.
    For example, the server's hostname.
  5. In the
    Email
    field, enter the contact email address for the certificate.
  6. In the
    SAN
    field, enter additional domain names that you want to associate with the self-signed certificate.
  7. In the
    City
    field, enter the city or locality name.
  8. In the
    State
    field, enter the state, county, or region.
  9. In the
    Country
    field, enter the two-letter country code.
    For example, US for United States.
  10. In the
    Organization
    field, enter the full name of the certificate originator organization.
    For example, your company's name.
  11. In the
    Unit
    field, enter the organizational unit or division name.
    For example, IT.
  12. In the
    Version
    field, specify the certificate version.
    The default value is 1.
  13. For
    Key Type
    , select a key type.
    Available options are RSA, ECDSA, Encrypted RSA, or Encrypted ECDSA. If you select an encrypted option, the additional fields display.
    • For
      ECDSA
      , select the
      Curve Name
      .
    • For
      RSA
      , select the
      Key Size
      .
    • For
      Encrypted ECDSA
      , select the
      Curve Name
      , enter the
      Key Passphrase
      , and re-enter the key passphrase in the
      Confirm Key Passphrase
      to confirm.
    • For
      Encrypted RSA
      , select the
      Key Size
      , enter the
      Key Passphrase
      , and re-enter the key passphrase in the
      Confirm Key Passphrase
      to confirm.
    For
    Key Passphrase
    , the range is between 6 and 255 characters.
  14. Click
    Save
    .

Certificate management from the CLI

Create a private key and self-signed certificate from the CLI

You can create a private key and a self-signed certificate from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Create a private key and self-signed certificate.
    system aaa tls create-self-signed-cert name <
    name
    > email <
    email-address
    > city <
    city
    > region <
    region
    > country <
    country
    > organization <
    org-name
    > unit <
    org-unit
    > version <
    cert-version
    > days-valid <
    number
    > key-type {
    rsa
    |
    ecdsa
    } store-tls {
    true
    |
    false
    }
    The
    store-tls
    option stores the private key and self-signed certificate in
    system/aaa/tls/config/key
    and
    system/aaa/tls/config/certificate
    instead of returning in the CLI output. If set to false, the key and certificate can be cut and pasted externally.
    This example creates a private key and self-signed certificate with city, country, days valid, email, key type, name, organization, region, unit and version options specified, and with store TLS set to false:
    appliance-1(config)# system aaa tls create-self-signed-cert city Seattle country US days-valid 365 email jdoe@company.com key-type ecdsa name Godzilla organization "Company" region Washington unit DEV version 1 curve-name prime239v2 store-tls false response -----BEGIN EC PRIVATE KEY----- MHECAQEEHiyJEVihDTnVi+v9RjfK3LhZ2PdSOXZFMJf3lyXaoaAKBggqhkjOPQMB BaFAAz4ABHFISUTEi8wEdG0iBF3iqTi5m5b62xUSbhOJrXR8d0S6h+anvpo9xrH3 QKbVuacF7ZSNMj2tX/wyqVNePg== -----END EC PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIICAzCCAa4CCQCR5RKtuBFcxTAKBggqhkjOPQQDAjCBjTELMAkGA1UEBhMCVVMx EzARBgNVBAgMCldhc2hpbmd0b24xEDAOBgNVBAcMB1NlYXR0bGUxEzARBgNVBAoM CkY1IE5ldG9ya3MxEDAOBgNVBAsMB1NXRElBR1MxETAPBgNVBAMMCEdvZHppbGxh MR0wGwYJKoZIhvcNAQkBFg5qLm1vb3JlQGY1LmNvbTAeFw0yMTAzMjcwMjE2NTFa Fw0yMjAzMjcwMjE2NTFaMIGNMQswCQYDVQQGEwJVUzETMBEGA1UECAwKV2FzaGlu Z3RvbjEQMA4GA1UEBwwHU2VhdHRsZTET3hdhv1UECgwKRjUgTmV0b3JrczEQMA4G A1UECwwHU1dESUFHUzERMA8GA1UEAwwIR29kemlsbGExHTAbBgkqhkiG9w0BCQEW DmoubW9vcmVAZjUuY29tMFUwEwYHKoZIzj0CAQYIKoZIzj0DAQUDPgAEcUhJRMSL zAR0bSIEXeKpOLmblvrbF4jsv4mtdHx3RLqH5qe+mj3GsfdAptW5pwXtlI0yPa1f /DKpU14+MAoGCCqGSM49BAMCA0MAMEACHh38OAyBBjAsVRBklBXZUIuynHq3/tr4 3VUQsMtYHQIeeP3vCrRm2qjPtK62QwtbkqDA9h2qTvuDj6uYL8EI -----END CERTIFICATE-----
  4. Commit the configuration changes.
    commit

Configure a TLS key and certificate from the CLI

Before you can enable TLS encryption, you must have already configured a key and certificate on the system.
You can configure a TLS key and certificate from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Configure a certificate.
    system aaa tls config certificate
    Press Enter to enable multi-line mode and then paste the contents. Press Ctrl-D to exit multi-line mode.
    appliance-1(config)# system aaa tls config certificate (<string>): [Multiline mode, exit with ctrl-D.] > ...
  3. Commit the configuration changes.
    commit
  4. Configure a key.
    system aaa tls config key
    Press Enter to enable multi-line mode and then paste the contents. Press Ctrl-D to exit multi-line mode.
    appliance-1(config)# system aaa tls config key (<string>): [Multiline mode, exit with ctrl-D.] > ...
  5. Commit the configuration changes.
    commit
  6. Return to user (operational) mode.
    end
  7. Verify that the certificate is configured.
    show system aaa tls state certificate
    A summary similar to this example displays:
    appliance-1# show system aaa tls state certificate response Certificate: Data: Version: 3 (0x2) Serial Number: 123434828 (0x1334e9cc) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=WA, L=Seattle, O=MyCompany, OU=IT, CN=localhost.localdomain/emailAddress=root@localhost.localdomain Validity Not Before: Mar 18 21:40:28 2020 GMT Not After : Mar 16 21:40:28 2030 GMT Subject: C=US, ST=WA, L=Seattle, O=MyCompany, OU=IT, CN=localhost.localdomain/emailAddress=root@localhost.localdomain Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:bc:ba:b9:8d:51:c7:c9:fe:81:86:52:ea:ef:08: ab:af:68:df:dc:22:6d:a3:23:fa:a5:5b:cd:89:3e: be:fb:cb:92:c4:bc:d7:a6:a5:f3:8b:6b:84:fa:b4: 31:39:88:8b:9a:96:2a:35:1c:3f:ee:23:4a:25:8f: cd:ca:ae:fa:e2:38:5d:9f:43:9d:18:c2:8f:1f:f7: 27:a7:75:a1:12:71:2f:ec:8f:37:e2:a6:74:cc:59: d4:c4:68:26:0c:0d:b6:b0:92:76:38:59:86:e1:54: 40:0e:0e:5d:6e:d6:e7:21:07:94:9e:43:6d:f0:50: 25:5a:68:64:39:fe:a6:df:6d:3f:f8:3c:69:9b:68: 5d:e7:36:88:5c:67:5a:02:01:99:e3:2c:d9:08:cc: d5:9e:1c:cd:46:28:3a:85:76:59:fb:b3:f1:61:bc: ef:03:57:2c:20:5d:6c:1d:11:1e:56:30:b2:91:67: 99:32:3f:d3:08:6d:4f:cd:a3:8d:f6:e6:34:9c:87: 04:8e:f2:79:f2:8c:1f:cc:1a:8b:2c:25:cf:b4:0c: ab:73:93:e4:49:d5:03:00:eb:1f:90:3c:04:c3:59: 10:90:c9:dd:29:32:cb:27:9f:04:37:f5:05:20:f9: 79:32:c1:50:66:76:1d:6d:2d:78:95:16:d2:65:7b: 4c:f1 Exponent: 65530 (x10001) Signature Algorithm: sha256WithRSAEncryption 12:21:0e:06:80:ab:df:05:9f:04:80:9f:d6:db:b9:2e:c8:d7: 39:8b:ac:6a:cf:cc:7b:5b:64:5c:59:2c:72:fe:57:d5:46:91: 0a:d4:40:0d:42:c1:95:a6:69:d9:1e:36:ac:d1:dd:f4:a1:b0: 34:3c:71:09:31:57:1a:0b:33:83:13:17:99:84:e4:70:82:85: f3:72:c7:fa:ba:0e:1a:fe:55:a1:ce:f7:96:2b:39:ef:4d:7a: 7a:23:71:44:01:c1:6c:10:58:e8:5f:6b:a8:b6:70:cc:8f:65: c8:cd:7b:aa:4b:e2:6a:bc:1c:fe:59:8f:c8:85:08:f0:46:67: 8d:15:a6:01:d0:a3:a2:fd:9c:db:c5:5b:51:07:6f:db:59:f8: bc:ba:9d:4a:30:ea:a7:7c:0c:fb:bb:9a:ea:c9:c2:a4:c1:82: e3:b8:2e:57:cd:32:6a:b1:a8:95:75:e3:82:8a:ea:c2:f8:37: c4:6f:a2:b4:e5:82:6c:3a:5d:c1:1f:a7:8e:da:7d:4c:51:d1: 45:36:da:97:31:4a:64:92:bf:bb:85:e3:bd:67:16:79:fe:53: 92:df:a8:3f:dc:8c:4e:e4:7c:b9:5e:ba:d6:ab:3d:7d:29:59: 01:27:d9:ca:52:10:58:60:00:02:19:f9:1d:74:07:5c:0d:f7: 5e:c2:d6:82

Create a Certificate Signing Request (CSR) from the CLI

You can create a text-based certificate signing request (CSR) from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Create a CSR.
    system aaa tls create-csr
    name <
    name
    > email <
    email-address
    > city <
    city
    > region <
    region
    > country <
    country
    > organization <
    org-name
    > unit <
    org-unit
    > version <
    cert-version
    >
    This example creates a CSR with name, email, organization, and unit options specified:
    appliance-1# (config): system aaa tls create-csr name company.com email dev@company.com organization "Company" unit engineering response -----BEGIN CERTIFICATE REQUEST----- MIIC0zCCAbsCAQEwgY0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9u MRAwDgYDVQQHEwdTZWF0dGxlMRQwEgYDVQQKFAtGNV9OZXR3b3JrczEUMBIGA1UE CxMLZGV2ZWxvcG1lbnQxGTAXBgkqhkiG9w0BCQEWCmRldkBmNS5jb20xEDAOBgNV BAMTB3Rlc3Rjc3IwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCinnAV Dv/G6+qbiBVO7zIPmFFatYcrzdUnvpTGXf30vhBRqcW90jJy12FwtYOL8P6mED+ gfjpxRWe+vjnztjZSIDpyh7Dn+F3MRF3zkgnSKlYKI9qqzlRHRAwi2U7GfujeR5H CXrJ4uxYK2Wp8WVSa7TWwj6Bnps8Uldnj0kenBJ1eUVUXoQAbUmZQg6l+qhKRiDh 3E/xMOtaGWg0SjD7dEQij5l+8FBEHVhQKEr52d4OifR62/MZSnPw2MY5OJ69p2Wn k7Fr7m4I5z9lxJduYDNmiddVilpWdqRaCB2j29XCmpVJduF2v6EsMx693K18IJ1h iRice6oKL7eoI/NdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAGjWSAqKUPqMY eLlSDs8fhj+ckia5r/TITqamMN+m8TqQI8Pk0tAnwHCl8HHS+4cI8QuupgS/3aU ls7OtxceoQZ1VFX2sQFkrDJFe0ewZQLm5diip5kxFrnap0oA0wRy84ks0wxeiCWD New3hgSXfzyXI0g0auT6KNwsGaO8ZuhOX3ICNnSLbfb00aYbhfI9jKopXQgZG/LO pOct33fdpf/U6kQA9Rw/nzs3Hz/nsVleOrl3TH1+9veMMF+6eq8KKPpbYKh9bhA+ pYI3TtbZHuyRyQbq/r4gf4JkIu/PGszzy/rsDWy+b9g9nXMh1oFj+xhTrBjBk8a2 0ov+Osy2iA== -----END CERTIFICATE REQUEST-----
  4. Commit the configuration changes.
    commit

Configure a Certificate Revocation List (CRL) from the CLI

You can configure a Certificate Revocation List (CRL) entry from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure a CRL entry.
    system aaa tls crls crl <
    crl-name
    >
    Press Enter to enable multi-line mode and then paste the contents. Press Ctrl-D to exit multi-line mode.
    In this example, you configure a CRL named "bbb":
    appliance-1(config)# system aaa tls crls crl bbb Value for 'config revocation-key'(<string>): [Multiline mode, exit with ctrl-D.] > ...
  4. Commit the configuration changes.
    commit
  5. To delete a CRL entry.
    no system aaa tls crls crl <
    crl-name
    >
    In this example, you delete a CRL entry named "bbb":
    appliance-1(config)# no system aaa tls crls crl bbb
  6. Commit the configuration changes.
    commit
  7. Return to user (operational) mode.
    end
  8. View the CRLs currently on the system.
    show system aaa tls crls crl
    This example shows the CRLs currently on the system:
    appliance-1# show system aaa tls crls crl DATE NAME ADDED -------------------- *name* 3/11/2021

Delete a Certificate Revocation List (CRL) from the CLI

You can delete a Certificate Revocation List (CRL) entry from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Delete a CRL entry.
    no system aaa tls crls crl <
    crl-name
    >
    In this example, you delete a CRL entry named "bbb":
    appliance-1(config)# no system aaa tls crls crl bbb
  4. Commit the configuration changes.
    commit

Configure a Certificate Authority (CA) bundle from the CLI

When you install an SSL certificate, you add a certificate authority (CA) bundle, which is a file that contains root and intermediate certificates, in addition to the certificate. You can add or delete a CA bundle from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Add a CA bundle.
    system aaa tls ca-bundles ca-bundle <
    ca-bundle-name
    > config name <
    ca-bundle-name
    > content
    Press Enter to enable multi-line mode and paste the contents. Press Ctrl-D to exit multi-line mode.
    In this example, you add a CA bundle named "test_caaaa":
    appliance-1(config)# system aaa tls ca-bundles ca-bundle test_caaaa config name test_caaaa content (<string>): [Multiline mode, exit with ctrl-D.]
  4. Commit the configuration changes.
    commit
  5. To delete a CA bundle.
    no system aaa tls ca-bundles ca-bundle <
    ca-bundle-name
    >
    In this example, you delete a CA bundle named "test_caaaa":
    appliance-1(config)# no system aaa tls ca-bundles ca-bundle test_caaaa
  6. Commit the configuration changes.
    commit

Delete a Certificate Authority (CA) bundle from the CLI

You can delete a configured Certificate Authority (CA) bundle from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Delete a CA bundle.
    no system aaa tls ca-bundles ca-bundle <
    ca-bundle-name
    >
    In this example, you delete a CA bundle named "test_caaaa":
    appliance-1(config)# no system aaa tls ca-bundles ca-bundle test_caaaa
  4. Commit the configuration changes.
    commit

Authentication and access management from the webUI

Configure basic authentication from the webUI

You can configure basic authentication (user name and password) from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Basic Authentication
    , select whether to enable authenticating using a username and password.
    The default value is
    Enabled
    .
  4. Click
    Save
    .

Configure token lifetime from the webUI

You can choose how long your webUI session will remain active (in minutes) by configuring the token lifetime from the webUI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. For
    Token Lifetime
    , enter the token lifetime length in minutes.
    The range is from 1 to 1440 minutes. The default value is
    15
    .
  4. Click
    Save
    .
RESTCONF token will be automatically renewed when the token’s lifetime is less than one-third of its original token lifetime. For example, if we set the token lifetime to two minutes, it will be renewed and a new token will be generated, when the token’s lifetime is less than one-third of its original lifetime, that is, anytime between 80 to 120 seconds. If the system does not receive a new RESTCONF request within the buffer time (80 to 120 seconds), then the token will be expired without getting renewed and you will be logged out of the session. The RESTCONF token will be renewed up to five times. After this, token will not be renewed and you will need to re-login into the system.

Configure local password policy from the webUI

A password policy enables you to qualify criteria for valid passwords and configure maximum password attempts for local authentication (
/etc/passwd
).
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Authentication Settings
    .
  3. In the Local Password Policy area, for
    Minimum Length
    , type the minimum number of characters required for a password.
    The allowed range is 6 to 255.
  4. For
    Required Characters
    , enter the minimum number of
    Numeric
    ,
    Uppercase
    ,
    Lowercase
    , and
    Special
    characters required in a valid password.
  5. For
    New/Old Password Differential
    , enter the number of character changes in the new password that differentiate it from the old password.
    The default value is 8.
  6. For
    Disallow Username
    , select whether to check the password for the user name in forward or reversed form.
    When set to
    True
    , if any variant of the username is found in the password, the new password is rejected.
  7. Set
    Apply Password Policy to Root Account
    to
    True
    to use the same password policy for the root account.
    The default value is
    False
    .
  8. For
    Maximum Password Retries
    , enter the number of times a user can try to create an acceptable password at the prompt.
    The default value is 3.
  9. For
    Maximum Login Attempts
    , enter the allowed number of times a user can attempt to log in before the account is temporarily suspended.
    The default value is 10 tries. If set to 0, there is no limit to the number of login attempts.
  10. For
    Lockout Duration
    , type the amount of time in minutes that must lapse before a previously suspended user's account is unlocked.
    The default auto value is 1 minute. If the value is set to 0, the administrator will have to manually unlock the user's account.
  11. For
    Max Password Age
    , type the maximum number of days after which the password will expire after being changed.
    If the last change was today and Maximum Password Age is 90, then the password will expire in 91 days. If set to 0 (the default), the password never expires.
  12. For
    Max Class Repeat
    , type the maximum number of repeating upper/lowercase letters, digits or special characters such as '!@#$%' allowed in the password.
  13. For
    Max Letter Repeat
    , type the maximum number of repeating lower-case letters allowed in the password
  14. For
    Max Sequence Repeat
    , type the maximum number of repeating upper/lowercase letters or digits allowed in the password.
  15. Click
    Save
    .
You have configured the local password policy. On the same screen, you can configure other authentication settings.

Add users from the webUI

You can add users to the
rSeries
system from the webUI. Default root and admin accounts are provided on the system. You can change the passwords on those accounts, but they cannot be deleted.
You can create only admin and operator users from the webUI. You can create other roles from the CLI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    AUTHENTICATION & ACCESS
    Users & Roles
    .
  3. Click
    Add
    .
  4. For
    Authentication Method
    , the value is fixed as
    Local
    .
  5. For
    Username
    , create a name for the user.
  6. For
    Set Password
    , create a valid password according to the local password policy defined in the Authentication Settings.
  7. For
    Confirm Password
    , retype the password.
  8. From the
    Role
    list, select the role to assign appropriate capabilities for the user. Both
    Primary Role
    and
    Secondary Role
    fields have the following options:
    Option
    Description
    Admin
    Used for the system administrator. Provides access to the CLI or webUI to configure the system (unrestricted read/write access). Can unlock any users.
    Resource Admin
    Similar to the Admin user role, but cannot create, modify, or delete local user accounts; create, modify, or delete server groups; or modify any authentication settings. This user role can modify their own user detail to change their own password.
    Operator
    Provides read access to system. Has write access to change password only.
    User
    Provide read-only access to view all the non-sensitive information on the system. Has write access to change password only.
  9. For
    Authorized Keys
    , add the required list of keys.
    Users with Admin roles or privileges can add, change, or remove authorized keys for themselves or other user accounts. A new multi-line field labeled
    Authorized Keys
    is added to the Add or Edit User form, and only administrators have access to it. When an administrator creates a new user account, they can add one or more authorized keys to the field, in addition to setting the user's password, role, and expiration date.
  10. From the
    Expiry Status
    list, select the applicable status.
    Available options are:
    Option
    Description
    Enabled
    This option enables the selected expiry date which means the user account login is available.
    Locked
    This options allows the expiry date is locked until the new expiry date is selected. It means the user account login is not available or expired.
    Expiry date
    When
    Expiry date
    is selected, this option displays a calendar widget. The user can select a future date and adjust an existingexpiry date including lengthening or shortening the duration/date. The selected and saved date will be in YYYY-MM-DD format.
  11. Click
    Save & Close
    .
Create as many users as needed to manage the system.

Authentication and access management from the CLI

Add a user from the CLI

You can create additional users on your system from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Add a user.
    system aaa authentication users user <
    user-name
    > config username <
    user-name
    > role <
    role
    > expiry-date <
    yyyy-mm-dd
    >
    Where expiry-date is the date <
    yyyy-mm-dd
    > you want the account to expire. Some other values for expiry-date are -1 for no expiration date (the default value), and 1 for expired.
    This example creates an admin user named
    testuser
    with an account expiration date of November 20, 2025:
    appliance-1(config)# system aaa authentication users user testuser config username test role admin expiry-date 2023-11-20
    These roles are available:
    Role
    Description
    admin
    Has full read/write access and can make configuration changes at the level in which they are working.
    limited
    F5 internal use only
    operator
    Has read-only access to every screen and every configuration object at the level in which they are working.
    resource-admin
    Similar to the Admin user role, but cannot create, modify, or delete local user accounts; create, modify, or delete server groups; or modify any authentication settings. This user role can modify their own user detail to change their own password.
    root
    Provides Bash shell access to the entire system including all components.
    tenant console
    Has virtual console access to tenants from the CLI but no access to the rSeries syste
    user
    Has read-only access to view all the non-sensitive information on the system.`
    superuser
    Provides root access privileges and bash access to the system, allowing users with the superuser role to execute commands from a bash shell. To get the bash shell, an F5OS admin or resource admin must set the 'superuser-bash-access' flag in ConfD to 'true' and turn off the appliance mode.
  4. Commit the configuration changes.
    commit
  5. Set the password for the user.
    system aaa authentication users user <
    user-name
    > config set-password password
    This example shows you set password for the user named 'testuser':
    appliance-1(config)# system aaa authentication users user testuser config set-password password
    When you create a new user, only the admin user can set the password. However, users have the privilege to change the password.
    You can also configure following the fields if required.
    Name
    Description
    authorised-keys
    Authorized keys for the user
    expiry-status
    Account expiation date
    last-change
    Date of last password change
    tally-count
    Login failure count
  6. Commit the configuration changes.
    commit
The system creates the account with the specified role.

Disable a user from the CLI

You can disable user accounts on your system from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Disable a user.
    An expiry-status of "locked" disables the account immediately, and "enabled" causes the account never to expire. You can also set the expiry-status to a future date. In that case, set the expiry-status in yyyy-mm-dd format to the date you want the account to expire.
    system aaa authentication users user <
    user-name
    > config expiry-status [ locked | enabled | <yyyy-mm-dd> ]
    This example disables a user named
    testuser
    :
    appliance-1(config)# system aaa authentication users user testuser config expiry-status locked
  4. Commit the configuration changes.
    commit

Delete a user from the CLI

You can delete a specified user from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Delete a user.
    no system aaa authentication users user <
    user-name
    >
    This example deletes a user named
    testuser
    :
    appliance-1(config)# no system aaa authentication users user testuser
  4. Commit the configuration changes.
    commit

Set an admin password from the CLI

You can set an admin user's password from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Set a password for an admin user.
    system aaa authentication users user <
    user-name
    > config set-password
    This example sets the password for an admin user named
    testadmin
    :
    appliance-1(config)# system aaa authentication users user testadmin config set-password
    The system prompts you to set a new password for the specified admin user.

Set maximum password age

You can globally set the maximum password age for all users from the CLI. To do this, you specify the number of days after which the password will expire since it was last changed. For example, if the last change was today and the maximum age is 1, the password will expire tomorrow.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Specify the number of days after which a password will expire since it was last changed.
    system aaa password-policy config max-age <
    number-of-days
    >
    In this example, you set the number of days to 14:
    appliance-1(config)# system aaa password-policy config max-age 14
  4. Commit the configuration changes.
    commit
When you log in to the CLI, you receive a message that the password will expire in the specified number of days.
appliance-1# ssh admin@localhostadmin@localhost's password: Warning: your password will expire in 1 day Last login: Wed Jan 18 05:56:21 2020 from ::1

Change a password from the CLI

You can change the password for a specified user from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Change a specified user's password.
    system aaa authentication users user <
    user-name
    > config change-password
    This example changes the password for a user named
    testuser
    :
    appliance-1(config)# system aaa authentication users user testuser config change-password
    The system prompts you to confirm the old password, set a new password, and confirm the new password for the specified user.
  4. Commit the configuration changes.
    commit

Modify the password policy from the CLI

You can modify the password policy (such as the required length, required characters, repeated characters) from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Change a property of the password policy.
    system aaa password-policy config <property>
    Property
    Description
    apply-to-root
    Apply password restrictions to root accounts.
    max-age
    Number of days after which the user will have to change the password.
    max-class-repeat
    Reject passwords with this many repeating upper/lowercase letters, digits or special characters such as '!@#$%' in the password.
    max-letter-repeat
    Reject passwords with this many repeating lower-case letters in the password.
    max-login-failures
    Number of unsuccessful login attempts allowed before lockout.
    max-sequence-repeat
    Reject passwords with this many repeating upper/lowercase letters or digits in the password.
    min-length
    Minimum length of a new password.
    reject-username
    Reject passwords that contain the username.
    required-differences
    Required number of differences between the old and new passwords.
    required-lowercase
    Required number of lowercase characters in password.
    required-numeric
    Required number of numeric digits in password.
    required-special
    Required number of "special" characters in password.
    required-uppercase
    Required number of uppercase character in password.
    retries
    Number of times to prompt before failing.
    root-lockout
    Enable lockout of root users.
    root-unlock-time
    Time (seconds) before the root account is automatically unlocked.
    unlock-time
    Time (seconds) before a locked account is automatically unlocked.
    The system prompts you to enter the desired value for the password policy property.
  4. Commit the configuration changes.
    commit

Modify user options from the CLI

You can modify or set options for a specified user from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Change user options for a user.
    system aaa authentication users user <
    user-name
    > config last-change <
    time
    > expiry-date <
    yyyy-mm-dd
    >
    This example sets a last change date of zero (0) and an expiration date of January 1, 2030 for an admin user named
    testuser
    :
    appliance-1(config)# system aaa authentication users user testuser config last-change 0 expiry-date 2030-01-01
  4. Commit the configuration changes.
    commit

Configure basic authentication from the CLI

You can configure basic authentication (that is, logging in to the system using a username and password) from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure basic authentication.
    system aaa authentication config basic {
    disabled
    |
    enabled
    }
    This example enables basic authentication:
    appliance-1(config)# system aaa authentication config basic enabled
  4. Commit the configuration changes.
    commit
  5. When the
    system aaa authentication config basic
    is changed from enabled to disabled or vice versa, the system prompts for your confirmation to proceed to restart the HTTP service.
    system aaa authentication config basic enabled: Changing the basic auth will restart the HTTP service.Proceed? { yes | no }
  6. Commit the configuration changes.
    commit
After disabling ‌basic authentication, when you call
/api
or
/api/
URI, you will receive a success message (200 - OK) with auth token in response. All other API calls for authentication are unauthorized and will receive a failure message (401 - access denied).

Configure RESTCONF token lifetime from the CLI

You can choose how long your webUI session will remain active (in minutes) by configuring the token lifetime from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure authentication token lifetime.
    system aaa restconf-token config lifetime <
    minutes
    >
    This example sets the authentication token lifetime for 120 minutes:
    appliance-1(config)# system aaa restconf-token config lifetime 120
    The default RESTCONF token lifetime is 15 minutes and can be configured for a maximum of 1440 minutes.
  4. Commit the configuration changes.
    commit
RESTCONF token will be automatically renewed when the token’s lifetime is less than one-third of its original token lifetime. For example, if we set the token lifetime to two minutes, it will be renewed and a new token will be generated, when the token’s lifetime is less than one-third of its original lifetime, that is, anytime between 80 to 120 seconds. If the system does not receive a new RESTCONF request within the buffer time (80 to 120 seconds), then the token will be expired without getting renewed and you will be logged out of the session. The RESTCONF token will be renewed up to five times. After this, token will not be renewed and you will need to re-login into the system.

Invalidate RESTCONF token from the CLI

The RESTCONF token will be expired or invalid in the case when the user:
  • Logs out of the current session
  • Not uses the RESTCONF token for more than one minute (Idle timeout for RESTCONF token is one minute)
  • Changes the current password
  • Changes the user role
  • User account ‌expires
In addition to the above scenarios, you can invalidate the RESTCONF token manually from the CLI if required.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure authentication token lifetime.
    system aaa restconf-token invalidate id <
    token id
    >
    The following example invalidates the token:
    appliance-1(config)# system aaa restconf-token invalidate id eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJTZXNzaW9uIElEIjoidGVzdDExNzE4MzQ0NjA3IiwiYXV0aGluZm8iOiJhZG1pbiAxMDA0IDkwMDAgXC92YXJcL0Y1XC9zeXN0ZW0iLCJidWZmZXJ0aW1lbGltaXQiOiIxMDAiLCJleHAiOjE3MTgzNDQ5MDcsImlhdCI6MTcxODM0NDYwNywicmVuZXdsaW1pdCI6IjUiLCJ1c2VyaW5mbyI6InRlc3QxIDE3Mi4xOC4yMzguODkifQ.5rnyGIoZ9rTRGRMSnJ_1HRoNEvYvRwI0609qWG6nZzU
  4. Commit the configuration changes.
    commit

Show system login activity from the CLI

You can display the login time, method, host, and status of system login activity from the CLI. The system maintains information for 7 login records before overwriting the earliest records.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Display the system login activity.
    show system login-activity
    This example displays the system login activity.
    syscon-1-active# show system login-activity admin 2023-04-26 16:21:23 http 172.18.65.114 success 2023-04-26 16:55:32 http 172.18.65.114 success root 2023-04-14 01:21:55 ssh 10.145.71.88 success 2023-04-14 01:23:08 ssh 10.145.71.88 success

Running f5sh to access ConfD from Bash shell

F5sh is a utility that allows a user with superuser role to execute ConfD CLI commands from the bash shell. All the ConfD CLI commands prepended with "f5sh" can be executed from the bash shell.
When f5sh is run with command line arguments, the output may then be piped into standard unix shell commands for parsing. For more information on ConfD CLI commands, see F5OS-A/F5 rSeries - CLI documentation.
When the users run the f5sh commands:
  • With arguments - The system runs these commands via a non-interactive session with ConfD. However, commands that require interaction do not work. Most of these interactions can be automated by turning off prompting, or using confirmation arguments to the commands.
  • With no arguments (only f5sh) - The system starts an interactive ConfD session. Hence, all commands can be executed.
When logged in to the system, superusers can access the bash shell, run the "f5sh" command to access ConfD, and use the "sudo" command. Since the superusers have the ability to use "sudo" to become root, they will have full access to the system. Root can also run the ConfD commands via the "f5sh" command and these commands will be logged and audited as being run by root, unlike when the "su admin" command is used. By default the superusers group is disabled and no superusers exist by default.

Accessing ConfD from bash shell using F5sh

To access ConfD from bash shell using f5sh, follow the steps below:
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure superuser role to an existing user.
    appliance-1(config)# system aaa authentication roles role superuser config users <
    user-name
    >
    This example sets a superuser named testuser:
    appliance-1(config)# system aaa authentication roles role superuser config users [ testuser ]
    To get the bash shell for a superuser role, you must:
    • Set the 'superuser-bash-access' flag in ConfD to 'true' and turn off the appliance mode.
    • Add 'F5-F5OS-SECONDARYGIDS' attribute to the RADIUS dictionary.
  4. Commit the configuration changes.
    commit
  5. Log in to the system with the superuser role.
    Now, you can run the f5sh utility from bash shell and execute ConfD CLI commands.
    The following examples showing running ConfD commands using f5sh utility:
    Show configured vlans:
    bash-4.2$ f5sh show vlans vlan
    Configure sshd idle timeout:
    bash-4.2$ f5sh "config; system settings config sshd-idle-timeout 100; commit"
    Parse command output with unix command line utilities:
    bash-4.2$ f5sh "f5sh show system mgmt-ip | grep -- ipv4-address system mgmt-ip state floating ipv4-address 10.255.144.41 ipv4-address 10.255.144.39 ipv4-address 10.255.144.40