Authentication & Access

Authentication and access overview

You can manage the VELOS system at all levelsfrom the CLI, the webUI, or using REST APIs. Each of these levels is distinct from one another requiring separate user names and passwords.

The VELOS system has twothree levels of user management:

System controller level (chassis)

At the system controller 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 controller 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 controller administrators or operators. The system controller administrator also creates the chassis partitions, terminal server administrators, or operators.

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.

Chassis partition level

At the chassis partition level, the chassis partition administrator logs into the chassis partition previously created by the system controller administrator. The chassis partition provides a default admin account and a chassis partition root account. The chassis partition administrator utilizes the admin account for managing the chassis partition, adding users, such as additional partition administrators, operators, and tenant console operators. You can use the root account to log into the blades in the partition (when accessing the serial consoles of the blades), but cannot log into the partition webUI or CLI.

Tenant level

Since the tenants are independent of the rest of the VELOS 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 VELOS system, and each role performs different sets of administrative actions at conceptually different levels.

On VELOS systems, users with admin access can make configuration changes at the level in which they are working (either the system controller level or the chassis partition level).

System controller-level user roles

This table lists user roles at the system controller level.

Chassis partition-level user roles

This table lists user roles at the chassis partition level.

Remote authentication overview

The VELOS 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 VELOS 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 VELOS system, you must configure the type of authentication and settings to use at both the system controller/chassis level and chassis partition level. You can configure LDAP, RADIUS, Active Directory, and/or TACACS+ for external authentication from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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.

   Note: 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.

The authentication settings are configured at the system controller/chassis level or the chassis partition in which you are working. 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 VELOS system attempts authentication methods when a user logs in to the system from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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.

   Note: 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 from either the system controller or chassis partition webUI to organize servers using the same type of authentication method at both the system controller/chassis level and the chassis partition level. This is because the authentication servers used on the chassis partition might differ from those used on the system controllers at the chassis level.

1. Log in to the VELOS system controller webUI or the chassis partition webUI using an account with admin access.

2. On the left, click AUTHENTICATION & ACCESS > Server Groups.

3. Click Add.

4. For Name, enter a recognizable name for the server group.

5. For Provider Type, select LDAP, OSCP, 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 either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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 VELOS systems to enable authentication and authorization to occur on VELOS systems. Users created on external LDAP, Active Directory, RADIUS, or TACACS+ servers must be associated with one of these group IDs on the system.

Important: 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 VELOS system.

The F5-F5OS-UID field is deprecated and no longer used by ‌F5OS systems. Even if configured on the remote server, the value will be ignored by ‌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.

This table lists group IDs for system controller roles.

This table lists group IDs for chassis partition roles.

Group IDs for system controller roles

This table lists group IDs for system controller roles.

Group IDs for chassis partition roles

This table lists group IDs for chassis partition roles.

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 for system controllers from the CLI

You can display the administrator roles with their associated group IDs from the system controller CLI using an account with admin or operator access.

1. Log in to the command line interface (CLI) of the system controller 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 controllers.

   show system aaa authentication roles

   A summary similar to this example displays:

   Copy

   syscon-2-active# 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.                                           -     
   partition_1     9101  -       -      Provides console access for partition-1.                                         -     
   partition_2     9102  -       -      Provides console access for partition-2.                                         -     
   partition_3     9103  -       -      Provides console access for partition-3.                                         -     
   partition_4     9104  -       -      Provides console access for partition-4.                                         -     
   partition_5     9105  -       -      Provides console access for partition-5.                                         -     
   partition_6     9106  -       -      Provides console access for partition-6.                                         -     
   partition_7     9107  -       -      Provides console access for partition-7.                                         -     
   partition_8     9108  -       -      Provides console access for partition-8.                                         -     
   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).                      -     
   ts_admin        9100  -       -      Provides admin access to the terminal server (TS).                               -     
   user            9002  -       -      Read-only access to non-sensitive system level data.                             -     

Display user roles for chassis partitions from the CLI

You can display the administrator roles with their associated group IDs from the chassis partition CLI using an account with admin or operator access.

1. Log in to the command line interface (CLI) of the chassis partition 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 chassis partition.

   show system aaa authentication roles

   A summary similar to this example displays:

   Copy

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

Important: You can assign remote GID mappings for only one remote authentication method at a time. 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 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 either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

   Copy

   syscon-1-active(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:

   Copy

   syscon-2-active# 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.                                           -      
   partition_1     9101  -       -      Provides console access for partition-1.                                         -      
   partition_2     9102  -       -      Provides console access for partition-2.                                         -      
   partition_3     9103  -       -      Provides console access for partition-3.                                         -      
   partition_4     9104  -       -      Provides console access for partition-4.                                         -      
   partition_5     9105  -       -      Provides console access for partition-5.                                         -      
   partition_6     9106  -       -      Provides console access for partition-6.                                         -      
   partition_7     9107  -       -      Provides console access for partition-7.                                         -      
   partition_8     9108  -       -      Provides console access for partition-8.                                         -      
   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).                      -      
   ts_admin        9100  -       -      Provides admin access to the terminal server (TS).                               -      
   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 controller or chassis partition 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 an LDAP group filter.

   system aaa authentication roles role <*role-name*> config ldap-gid

   Note: For LDAP Group, F5 recommends you provide a fully distinguished name. For example:

   • samaccountname=<samaccountname assigned to group>
   • distinguishedName=<full DN of group>

   Note: The selected group must be under the configured LDAP base path (the Base DN configured in section ).

   The following example assigns a LDAP group to the admin user:

   Copy

   syscon-1-active(config)# system aaa authentication roles role admin config ldap-group 
   (<string>): distinguishedName=cn=my_ldap_group,ou=Otters,DC=example,DC=org

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:

   Copy

   `syscon-1-active# show system aaa authentication roles
                         REMOTE
   ROLENAME        GID   GID     LDAP GROUP                            DESCRIPTION                                                                      USERS
   -----------------------------------------------------------------------------------------------------------------------------------------------------------
   admin           9000  -       distinguishedName=cn=my_ldap_group,
                                 ou=Otters,DC=example,DC=org           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.                             -`

   Note:

   • 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.
   • When configuring an LDAP group, it may be appropriate to configure Unix Attributes to False.

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 VELOS system controller webUI or the chassis partition 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.

   For LDAP Group, F5 recommends you provide a fully distinguished name, such as:

   • samaccountname=<samaccountname assigned to group>
   • distinguishedName=<full DN of group> The following example shows a fully distinguished name.
   Copy

   distinguishedName=cn=my_ldap_group,ou=Otters,DC=example,DC=org

   Note:

   • 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.
   • When configuring an LDAP group, it may be appropriate to configure Unix Attributes to False in the AUTHENTICATION & ACCESS > Authentication Settings > Common LDAP Configuration section.

6. Click Save & Close.

LDAP/AD configuration overview

You can configure the VELOS system to use an LDAP or Microsoft Windows Active Directory (AD) server for authenticating VELOS system user accounts.

Before you begin:

• Verify that the LDAP service is set up on a server that is accessible to the VELOS 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 VELOS systems from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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.

   Note: 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.

   Note: 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, enter the base distinguished name (name-value pairs) from which to start the search for the LDAP user or group (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.

      Note: 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, or use the default of 3.

11. For Chase Referrals, select whether to enable LDAP referral chasing.

    Note: 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:

    • Select True (default) to use the gidNumber attribute for user and group role mapping.

    • Select False to automatically synthesize a gidNumber for role mapping from the Microsoft objectSid attribute. Note:

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

    • If Unix Attributes is set to False, ensure you configure LDAP Group for each role in AUTHENTICATION & ACCESS > Users & Roles > Roles > Edit Role.

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 either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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 VELOS for LDAP/Active Directory authentication from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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&gt;* 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:

   Copy

   syscon-1-active(config)# system aaa authentication ldap base dc=example,dc=local

   This example enables Active Directory authentication, by setting the active_directory option to true:

   Copy

   syscon-1-active(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 the server group.

      system aaa server-groups server-group ldap-group config name ldap-group type LDAP

   2. Add the server and IP address of the LDAP service.

      servers server <*ip-address*> config address <*ip-address*>

   3. Customize the LDAP configuration details.

      ldap config auth-port <*port-number*> type ldaps

      This example shows secure LDAP configuration:

      Copy

      syscon-1-active(config)# ldap config auth-port 636 type ldaps

   4. Commit the configuration changes.

      commit

LDAP/Active Directory authentication for users is configured on the system controllers or chassis partition in which you are working.

Create an LDAP server group from the CLI

You can create an LDAP server group (including Active Directory servers), if you have multiple external LDAP servers to which you want to connect, from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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 the 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-test:

   Copy

   syscon-1-active(config)# system aaa server-groups server-group ldap-test 
     config name ldap-test type LDAP

4. Commit the configuration changes.

   commit

5. Add the host name for the LDAP service.

   Note: This host name might have to be resolved in /etc/hosts or by DNS.

   This example adds a host name to the LDAP service:

   Copy

   syscon-1-active(config)# servers server ldap.company.com config 
     address ldap.company.com

6. Commit the configuration changes.

   commit

Add LDAP certificates from the CLI

You can add an LDAP certificate and key from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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*>)

   A summary similar to this example displays:

   Copy

   syscon-1-active(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*>)

   A summary similar to this example displays:

   Copy

   syscon-1-active(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 VELOS system to use a RADIUS server for authenticating VELOS system user accounts.

Important: Before you begin, you must verify that the RADIUS service is set up on a server that is accessible to the VELOS 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.

• Assign users to valid system group IDs on the external RADIUS server. For more information, see Group IDs (GIDs) and system authentication roles.

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.

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 VELOS systems from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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.

   Note: 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 either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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. Click Add.

9. For Server, enter the IPv4, IPv6 address, or FQDN of the RADIUS server to add.

10. For Port, make sure the port number is correct for RADIUS traffic.

    The default value is 1812.

11. For Secret, enter the shared secret used to access the server.

12. For Timeout (seconds), type the number of seconds to timeout if unable to access the server.

    The default value is 5.

13. 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 either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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 the server group.

      system aaa server-groups server-group radius-group config name radius-group type RADIUS

   2. Add the server and IP address for the RADIUS service.

      servers server <*ip-address*> config address <*ip-address*>

   3. Customize the RADIUS configuration details.

      radius config auth-port <*port-number*> secret-key secret timeout <*timeout-in-seconds*>

   4. Commit the configuration changes.

      commit

6. Enable message authentication on the device:

   system aaa authentication radius require_message_authenticator { false | true }

   Example:

   Copy

   appliance-1(config)# system aaa authentication radius require_message_authenticator
   Possible completions:
   false  true
   appliance-1(config)# system aaa authentication radius require_message_authenticator true
   appliance-1(config)# commit

   Note
   To get the bash shell for a superuser role, you must:\

   • Enabling Message authentication enhances the security of RADIUS communication between the F5OS device and the RADIUS server.
   • Ensure that message authentication is enabled on the RADIUS server by setting “require_message_authenticator = yes”. This enforces that all RADIUS requests from the F5OS device include a valid Message-Authenticator attribute.

RADIUS authentication for users is configured on the system controllers or chassis partition in which you are working.

Create a RADIUS server group from the CLI

If you have multiple RADIUS servers to which you want to connect, you can create a RADIUS server group from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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 the server group.

   system aaa server-groups server-group <*group-name*> config name <*group-name*> type RADIUS

   This example creates a RADIUS server group named radius-group:

   Copy

   syscon-1-active(config)# system aaa server-groups server-group radius-group 
     config name radius-group type RADIUS

4. Commit the configuration changes.

   commit

5. Add the server and IP address of the RADIUS service.

   servers server <*ip-address*> config address <*ip-address*>

6. Commit the configuration changes.

   commit

TACACS+ configuration overview

You can configure the VELOS system to use a TACACS+ server for authenticating VELOS system user accounts.

Before you begin:

• Verify that TACACS+ is set up on a server that is accessible to the VELOS system.
• Assign users to valid system group IDs on the external TACACS+ server. For more information, see Group IDs (GIDs) and system authentication roles.

TACACS+ configuration from the webUI

Configure TACACS+ authentication from the webUI

You can configure the use of TACACS+ authentication with VELOS systems from the webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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.

   Note: 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 VELOS system controller webUI or the chassis partition 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 either the system controller or chassis partition CLI..

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

      Copy

      syscon-1-active(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:

      Copy

      syscon-1-active(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*>

      This example shows configuring a port number:

      Copy

      syscon-1-active(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.

Note: The root and non-root users can login to the system through console using TACACS+ authentication.

OCSP configuration overview

Admin users can configure the VELOS 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 either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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. 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 OCSP responses.

8. For Response Time Skew, specify the maximum allowable time skew, in seconds, for 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 either the system controller or chassis partition webUI. The server group can contain only one OCSP server.

1. Log in to the VELOS system controller webUI or the chassis partition 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 controller or chassis partition 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.

     Copy

     syscon-1-active(config)# system aaa authentication ocsp config override-responder off

   • Provide the OCSP IP address using a server group.

     Copy

     syscon-1-active(config)# system aaa authentication ocsp config override-responder on
     syscon-1-active(config)# system aaa server-groups server-group ocsp1 config name ocsp1 type OCSP
     syscon-1-active(config-server-group-ocsp1)# servers server 192.0.2.17
     syscon-1-active(config-server-192.0.2.17)# config address 192.0.2.17
     syscon-1-active(config-server-192.0.2.17)# 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 controller or chassis partition 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:

   Copy

   syscon-1-active(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):

   Copy

   syscon-1-active(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 system controller or chassis partition 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 controller or chassis partition 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:

   Copy

   syscon-1-active(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 system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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 VELOS 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 VELOS 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 VELOS 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 either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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 either the system controller or chassis partition 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 controller or chassis partition 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:

   Copy

   syscon-1-active(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:

   Copy

   syscon-1-active(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 either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

   Copy

   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:

   Copy

   syscon-1-active(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:

   Copy

   syscon-1-active(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:

   Copy

   syscon-1-active(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”:

   Copy

   syscon-1-active(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 VELOS system from either the system controller or chassis partition CLI.

Important: 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:

   Copy

   syscon-1-active(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:

   Copy

   syscon-1-active(config)# system aaa authentication clientcert config client-cert-name-field san-gen-othername OID UPN

   Copy

   syscon-1-active(config)# system aaa authentication clientcert config client-cert-name-field san-gen-othername OID 1.1

   Copy

   syscon-1-active(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 or configure a TLS key and certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method in the system controller or chassis partition in which you are working (AUTHENTICATION & ACCESS > Authentication Settings).

You can view or replace TLS device certificates from either the system controller or chassis partition webUI. The device certificates apply only to the area in which you are working.

1. Log in to the VELOS system controller webUI or the chassis partition 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 field displays. 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 either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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, under CA Bundles, click the name of the bundle in the table and 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 VELOS system controller webUI or the chassis partition 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.

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

You can create a self-signed certificate from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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.

4. For Name, enter the common name of the certificate.

5. For Email, enter the contact email for the certificate.

6. In the Subject Alternative Name (SAN) field, enter additional domain names that you want to associate with the SSL certificate. Separate each domain name with a comma.

   For example, to associate the previous domain names with the SSL certificate, add the following comma-separated entries to Subject Alternative Name:

   Copy

   DNS:www.example.com, DNS:www.exchange.example.com, DNS:www.example.internal.net

7. For City, enter the city or locality.

8. For State, enter the state, county, or region.

9. For Organization, enter the full name of the certificate originator organization.

10. For Unit, enter the organizational unit or division.

11. For Version, enter the certificate version.

    The default value is 1.

12. For Days Valid, enter the number of days for which the certificate is valid.

    The default value is 30.

13. For Key Type, specify the type of key to use with the self-signed certificate from one of these options: ECDSA, RSA, ECDSA, Encrypted ECDSA, and Encrypted RSA

    Configure additional key options, as needed:

    • For ECDSA, select one of these Curve Name options: prime256v1 or secp384r1.
    • For RSA, select one of these Key Size options: 2048, 3072, or 4096.
    • For Encrypted ECDSA, select one of these Curve Name options: prime256v1 or secp384r1. Then, enter and confirm the Key Passphrase.
    • For RSA, select one of these Key Size options: 2048, 3072, or 4096. Then, enter and confirm the Confirm Key Passphrase.

14. For Store TLS, select whether to store the key and certificate in system/aaa/tls/config/key and system/aaa/tls/config/certificate.

    The default value is False.

15. Click Save.

Create a Certificate Signing Request (CSR) from the webUI

You can create a Certificate Signing Request (CSR) from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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. For Name, enter the common name of the certificate.

   For example, the server’s hostname.

5. For Email, enter the contact email address for the certificate.

6. In the Subject Alternative Name (SAN) field, enter additional domain names that you want to associate with the CSR. Separate each domain name with a comma.

   For example, to associate the previous domain names with the CSR, add the following comma-separated entries to Subject Alternative Name:

   Copy

   DNS:www.example.com, DNS:www.exchange.example.com, DNS:www.example.internal.net

7. For City, enter the city or locality.

8. For State, enter the state, county, or region.

9. For Country, enter the two-letter country code.

   For example, US for United States.

10. For Organization, enter the full name of the certificate originator organization.

    For example, your company’s name.

11. For Unit, enter the organizational unit or division name.

    For example, IT.

12. For Version, enter the certificate version.

    The default value is 1.

13. For Days Valid, enter the number of days for which the certificate is valid.

    The default value is 30.

14. For Key Type, specify the type of key to use with the self-signed certificate from one of these options: ECDSA, RSA, ECDSA, Encrypted ECDSA, and Encrypted RSA

    Configure additional key options, as needed:

    • For ECDSA, select one of these Curve Name options: prime256v1 or secp384r1.
    • For RSA, select one of these Key Size options: 2048, 3072, or 4096.
    • For Encrypted ECDSA, select one of these Curve Name options: prime256v1 or secp384r1. Then, enter and confirm the Key Passphrase.
    • For RSA, select one of these Key Size options: 2048, 3072, or 4096. Then, enter and confirm the Confirm Key Passphrase.

15. Click Save.

Certificate management from the CLI

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 either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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.

   Copy

   syscon-1-active(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.

   Copy

   syscon-1-active(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:

   Copy

   syscon-1-active# show system aaa tls state certificate
   response Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 322234828 (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:
                       bf: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:
                       bf: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:
                       4f: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:
                       c7: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
            47: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:
            08: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:
            49: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

Configure a Certificate Authority (CA) bundle from the CLI

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. You can add or delete a CA bundle from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller 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. To add a CA bundle.

   system aaa tls ca-bundles ca-bundle <*ca-bundle-name*> config name <*ca-bundle-name*> content

   1. Press Enter to enable multi-line mode and press ctrl-D to exit multi-line mode.

   In this example, you add a CA bundle named “test_caaaa”:

   Copy

   syscon-1-active(config)# system aaa tls ca-bundles ca-bundle 
     test_caaaa config name test_caaaa content

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”:

   Copy

   syscon-1-active(config)# no system aaa tls ca-bundles ca-bundle 
     test_caaaa

6. Commit the configuration changes.

   commit

Configure a Certification Revocation List (CRL) from the CLI

You can configure a Certificate Revocation List (CRL) entry from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller 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. To configure a CRL entry.

   system aaa tls crls crl <*crl-name*>

   In this example, you configure a CRL named “bbb”:

   Copy

   syscon-1-active(config)# system aaa tls crls crl bbb

   1. Press Enter to enable multi-line mode and press ctrl-D to exit multi-line mode.
   Copy

   Value for 'config revocation-key'(<string>):
   [Multiline mode, exit with ctrl-D.]
   > ...

   1. Enter the key value.

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”:

   Copy

   syscon-1-active(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:

   Copy

   syscon-1-active# show system aaa tls crls crl
            DATE
   NAME     ADDED
   --------------------
   *name*   3/11/2021

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

You can create a private key and a self-signed certificate from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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*> name <*additional name*> 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.

   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:

   Copy

   syscon-1-active(config)# system aaa tls create-self-signed-cert 
     city Seattle country US days-valid 365 email jdoe@company.com san URI:company.com,DNS:company1.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
   Z3RvbjEQMA4GA1UEBwwHU2VhdHRsZTETMBEGA1UECgwKRjUgTmV0b3JrczEQMA4G
   A1UECwwHU1dESUFHUzERMA8GA1UEAwwIR29kemlsbGExHTAbBgkqhkiG9w0BCQEW
   DmoubW9vcmVAZjUuY29tMFUwEwYHKoZIzj0CAQYIKoZIzj0DAQUDPgAEcUhJRMSL
   zAR0bSIEXeKpOLmblvrbFRJuE4mtdHx3RLqH5qe+mj3GsfdAptW5pwXtlI0yPa1f
   /DKpU14+MAoGCCqGSM49BAMCA0MAMEACHh38OAyBBjAsVRBklBXZUIuynHq3/tr4
   3VUQsMtYHQIeeP3vCrRm2qjPtK62QwtbkqDA9h2qTvuDj6uYL8EI
   -----END CERTIFICATE-----

4. Commit the configuration changes.

   commit

Create a Certificate Signing Request (CSR) from the CLI

You can create a text-based certificate signing request (CSR) from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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*> san <*additional name*> 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:

   Copy

   syscon-1-active# (config): system aaa tls create-csr city name company email test@company.com region CA san URI:company.com,DNS:company1.com
   response
   
   
   -----BEGIN RSA PRIVATE KEY-----
   MIIJKAIBAAKCAgEAn+QcmdPmtC27QOAii+6JtNxpGiqBSwAsb6GfWqWhNeZyKW1Y
   1i9w9s7CKT8mTGZd8fnjDG9rJNJ+Qixj1aziuaMTFj0ckOQ6DYsZDuCxCgCmoY9T
   He//sTb+jOPoPKc5s80oO1MBwFgXSdEl3s6HzEFPmI8kuTwutaL+WH+m83S03hnk
   fs8NLqJh5Is1sQLHcNG3e5n2FX2BKQ2520P8y7FU3W5EekJqtqZJz+XKEJSredfZ
   zm6oJwQwJFECAkrMbbMb61pHEKeY9CsII8LjukKbuDQcR5//k6PTz6/vyb5ThYN6
   yfL+0/nQtdwuQnoST8oqkT/GOTAwuGqR25LHaL/DVvqEHK0HxHrxnHEZd0rJd/dl
   b7eVKTSnJjOCvZr/1ctGFVVERIQ2MnoVNFXyD6gqYxyfuc1cZxPZA7PoD/3hvFWf
   RViGmALyxiJgbuS/NGBizVVQUxcdhqmRg1U3MbGfwpIdEg5CQfpgtAqe+atAeuMV
   rSEWsJE5nDOqpu4BuRRNEZijYXGMuD7zv02fL5S8Yn7wQgiCA97ZuskoBzh9HI4R
   o5hR7U2W6A8JONBqZoFSMfB1BxSLF/qf/VmqYrIVwOyNxo8b+BOpKEkmIqZppgeK
   QaNad45HeE2W4ykofTiUQL/X1PZV/1zBLoK1xD5WZN2CCwaNjB6r6P2C0BUCAwEA
   AQKCAgAO4Ti0LB81N2hMwk8UvK8+EKELWVdM9ogsH1toIS/eh0Kqjk2NKT8XCOjS
   09iplYE6qqmxl5DeDWTInb7wvLUg14dIM4m8BjFM31wGoWx4ZNUdBeyTRamDAX4w
   +Gi9dEaPcBFFbBUmpEwOh5NBp/DFVnKk3PVq86nZJ4EKFV8hGwRWAwzbrEMqytvX
   XAk0HvEWk73Cl/Jpz5M8kdVxDWOyRR+Dt+ZRhmrN8q291kG2x08p+KeBaZTmhKJC
   TvOj6PgbYWbAwVcJur8mQfbw9QsiY16AhwD2vXIYeE+W7WWgXcECFNlRf/atHXuJ
   4SLA9wFLQaIygD/fRJfUIb7PM1qxRCsSZay7lqPEpCUmailVUXfi8wEwv5mB8qj5
   h3NYoAUedO6BHn/KwV5RaXEGUXS1bdQbT/zakm5hampkdpsWpJ+U8cJRVK47ktLw
   c4LS6P+AHmmV0My6F+ugVFDxsUrDAhlrzF0Mlgt9bKTYWzrjf/SpOeDSozijK/fl
   33irBaagS+393Hvo4cshJZXP0VjuPeUdwwiuBHlLYNVcvXqBoARbCMa5dmSIXW/E
   6mzjnzb6BqV2xQkqQyVAXrgWvxTisIiDN0WID8+Vbepv1YrxISy9TTYGC/mNBxIT
   k0rQAOOeDESq8OuhmXajqqRzctYu5afE624jkR2DS8xSVGq4gQKCAQEA1L9xtGuX
   ils13ftD4t3t9lrWN4qZmu578EsQBJnxpNOIQTyK/cT/4E5WYSeeEFfBiF4jKHKS
   k8lr/7ulcRu7ax7Tkw1uZTacS9PuTrr27en9OH2/LiRL2WsDorqONUgsIVzk/TXB
   OReK3Qm5RUGSCnNPz80go9ntZC2dhrx+O4Q4nasQLIsCGiehRslBoqDzj7/3g/Pp
   2+z+0DO9DOZmJ+NAjp9kfJxT106rLSmDT/4cRwbsFqDBd4zWg3r0PWodwf3N0eJK
   iB+FrKffBZdSmAnYQkAXFu8KsuZijzHnAw5oHCZ+ZG3jv9lq/+zrkvy+fRzmAh/W
   BMq60p33tImLtQKCAQEAwGW2prb2EnUDeP/O/lBgn46j+odcOlulaSybI6pgyVBB
   MlriUcAbf7iQbZ0MfiQG6eFw2YQO3jLTFfg56VQFrJDk7RQU3L+qaLu7DjsL7itB
   56UTwupCZbXb+OSOh7dveFFklFKFC2Tp5cv2G9I64+lIhLzA3vvFH5H7mIzXocHh
   O3qvQkxyaPtGibvfSwJH/UorFuwDrIGMy8tocLFRYETGleQ89m/DxfGBKn9K4hJU
   UTu5mC83n3K2UpDjtEvym+1QgW7cIjNBRY6qWdBDmx5uHSC6GZhr3Y65w1TFQl3K
   EPCVa4zCSCXQSjAOFDa0P3RnLNpWSBsynzif80Ku4QKCAQEAqsSEw3p9aEwwX985
   LZhQUye0vV5eT7NP/qBx2g+rnE9DFoI/WtVPQj//K/r98EZQjWJqvCPDLidGrj5z
   3OeSt7hFwcrNKyb7rA4QQlfmry/b1wVweNwfmgRBJdSzI2esLJeBIxKL54TTLPuK
   IGIylHrcvIL9ySe7WmcXA7i3ZpSKUVynHenypQXceZJAQgcJmgBP8DXQKH0CSCLP
   g9RIeYn7HsAoi7F7xt5ZnmWtBn+FOSoARWWCBbEh2uXNuKI+AqH0HJ2Uj9ElnmId
   LUK6xFlaoksJfZogr1soD6LRuG1O+hGX8IsYfb1KGuWUbia7zHdu1JOzWaNU9Ixh
   8SNa5QKCAQBCXtQzjso0c8lO5HAzquaqJDrNIgTe3N6i+ZBLLWtWByl2hYOtT+gs
   ly67oYG9wg/gfrS/VJ8MZ9wJqCfSJfoPHazbXCIWRMg0eQ5+SkBDWQjTME8w3j8p
   dyL7KV1B1DXP+8QGprDezWEitMmhr1RBayhpIfQm+BN4YJO6fFumoYthSWFMLbMK
   JCShPv44kgDjj8Jtld1ulQJNC05sEb9Qxmj7LFEbclLG5hj44BClDE2p+EB+D0vQ
   5XGf6fujJs/6mlM7U1L9OVE6/Ywmj4HC8SxrP+7zBXGwbJwIliW2T0R1s4jYISak
   XOcNsKYqsvRbL3yoLGm3ViqQYqhK8qYBAoIBAC/TchzVUR4AQAJXSml4dEPNYpXw
   Ez1s1k3IDDONRD61vG61YuKD/tSygAfIkhUi9clzKW5vJfdyJrSejBr2foRa0Unw
   YJhItq3yTW+pHdK2pCN79G/yxi5h9IkuwLLyEaoJXcGjLmT/DeaLaf37YVLmQhnE
   iHlZnlshwbwfDNSFIjD+dZckliV4HPPt2mI7MO7x5ZebDgpqTmOWZPp718uzJje6
   mhOCvrUsx9c0IbTCUm3/KrzSZFiKXC5amf1jbBw219KHVe5fdeZsxvtViYz9tH0Q
   xhYQRszqtATohYK/3hjSZeFZTw14m2nEo7M4OwNCd41RHiVc8WCtEDBYMZc=
   -----END RSA PRIVATE KEY-----
   
   
   -----BEGIN CERTIFICATE REQUEST-----
   MIIE0TCCArkCAQEwVjEUMBIGA1UEAwwLeWFua3Rvbi5jb20xCzAJBgNVBAgMAkNB
   MRAwDgYDVQQHDAdUb3JvbnRvMR8wHQYJKoZIhvcNAQkBFhB5YW5rQHlhbmt0b24u
   Y29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAn+QcmdPmtC27QOAi
   i+6JtNxpGiqBSwAsb6GfWqWhNeZyKW1Y1i9w9s7CKT8mTGZd8fnjDG9rJNJ+Qixj
   1aziuaMTFj0ckOQ6DYsZDuCxCgCmoY9THe//sTb+jOPoPKc5s80oO1MBwFgXSdEl
   3s6HzEFPmI8kuTwutaL+WH+m83S03hnkfs8NLqJh5Is1sQLHcNG3e5n2FX2BKQ25
   20P8y7FU3W5EekJqtqZJz+XKEJSredfZzm6oJwQwJFECAkrMbbMb61pHEKeY9CsI
   I8LjukKbuDQcR5//k6PTz6/vyb5ThYN6yfL+0/nQtdwuQnoST8oqkT/GOTAwuGqR
   25LHaL/DVvqEHK0HxHrxnHEZd0rJd/dlb7eVKTSnJjOCvZr/1ctGFVVERIQ2MnoV
   NFXyD6gqYxyfuc1cZxPZA7PoD/3hvFWfRViGmALyxiJgbuS/NGBizVVQUxcdhqmR
   g1U3MbGfwpIdEg5CQfpgtAqe+atAeuMVrSEWsJE5nDOqpu4BuRRNEZijYXGMuD7z
   v02fL5S8Yn7wQgiCA97ZuskoBzh9HI4Ro5hR7U2W6A8JONBqZoFSMfB1BxSLF/qf
   /VmqYrIVwOyNxo8b+BOpKEkmIqZppgeKQaNad45HeE2W4ykofTiUQL/X1PZV/1zB
   LoK1xD5WZN2CCwaNjB6r6P2C0BUCAwEAAaA2MDQGCSqGSIb3DQEJDjEnMCUwIwYD
   VR0RBBwwGoYLeWFua3Rvbi5jb22CC3lhbmt0b24uY29tMA0GCSqGSIb3DQEBCwUA
   A4ICAQAcGnkhqrfD/I8s9DahUCK2QvONinqouacqAUCLTymjjM8GTGP/bqawyHFk
   09PRwtVP3kj1hE/bla4RRJMByb9sNZJh75R9yyjhO7xPhZrEOxL+mChyjMM4cm0z
   IPceOm2Os7LhlBcBEL7PR4H6AlrZbyf8n0ywGZYVdR5FRYASCGm/2eTVyksZiSdn
   M3OpQGX95IH8rahhfHJ1lqAp9WGUKy4Hp+WyIK346fsx1Ue4qVH6L37Cpvdqz7gT
   btQPpj8t6c+Vixub/laX7fJIOB8u3TBW/akBTqsHrAECd/dJWvTQo5xsIdR0YOHZ
   tyH2vPdKXktBFoNUBb2NUJrAKriGPO0FPHlukAbEoRLVQQ604IUA8wpDUZHgHIQZ
   8mBx+jHNl/DaGwPXdPVclKbtng4CiEP/5tXvjo5xAQXqUY1Cc7Sjev0bE+fnii6L
   xme4iV9iIiCctmq5sFZ5G9zcpeR6rvSpqvOUFJ5MYi29tr9nBYZq77tckmMhpE6D
   aSCASDvd3Ox9Ita0KYQJwAv/y0m+ZFmN6PglEInJtjIj+nUgcOXMzH8UrLoVPLnT
   q2W5cT90nyShP5DtEazHAuoQhZY6gw3OU73WoJidKnT56j/EdlEMqy0YEMvsst1h
   qexcqQ9yjvVgmmbA+N8nRmmVCyEIG0oPGxTnGCrSWIXdoeVzFA==
   -----END CERTIFICATE REQUEST-----

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 either the system controller or the chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition 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 VELOS system controller webUI or the chassis partition 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.

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). You can configure local password policy at both the chassis and the chassis partition levels from either the system controller or chassis partition webUI.

1. Log in to the VELOS system controller webUI or the chassis partition webUI using an account with admin access.

2. On the left, click AUTHENTICATION & ACCESS > Authentication Settings.

3. Click Show to display the Local Password Policy area.

4. For Minimum Length, enter the minimum number of characters required for a password.

   The allowed range is 6 to 255.

5. For Required Characters, enter the minimum number of Numeric, Uppercase, Lowercase, and Special characters required in a valid password.

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

7. For Number of Previous User Passwords Remembered, enter the number of past or previous passwords the system should remember.

   The default value is 0.

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

9. Set Apply Password Policy to Root Account to:

   • True - To apply the password policy for admin roles to set password for other user accounts.
   • False - To apply the password policy for user to set password for changing their own password. The default value is True.

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

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

12. For Lockout Duration, enter the duration, in seconds, required for a previously suspended user’s account to be unlocked.

    The default auto value is 60 seconds. If the value is set to 0, the administrator will have to manually unlock the user’s account.

13. For Password Expiry Warning Period, specify how many days in advance you would like to receive alerts for password expiration.

    The default value is 0.

14. For Max Password Age, specify the number of days after which the password will expire following a password change.

    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.

15. For Minimum days between password updates, specify the minimum number of days required between password updates.

    The default value is 0.

16. For Maximum Class Repeat, specify the maximum number of repetitive charecters that can be used in the password. This includes uppercase and lowercase letters, numbers, and special characters (!@#$%).

17. For Max Letter Repeat, specify the maximum number of times that the lowercase letters can be repeated in the password.

18. For Max Sequence Repeat, specify the maximum number of consecutive uppercase/lowercase letters or number allowed in the password.

19. Click Save.

You have configured the local password policy for the system or on the chassis partition in which you are working. On the same screen, you can configure other authentication settings.

Add users from the webUI

You can add users at both the chassis level and the chassis partition level. Default root and admin accounts are provided on the system. You can change the passwords on those accounts, but they cannot be deleted.

Note: You can create only admin and operator users from the webUI. You can create other roles from the CLI.

1. Log in to the VELOS system controller webUI or the chassis partition 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, enter a name for the user.

6. For Set Password, enter 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:

   At the chassis level:

   Option	Description
   Admin	Used for the chassis administrator. Provides access to the chassis CLI or chassis webUI to configure the system at the chassis level (unrestricted read/write access). Can unlock any chassis users. Logs in to the active system controller or floating IP address.
   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	Used for the chassis operator. Provides read access to chassis level configuration; write access to change password only. Logs in to the active system controller or floating IP address.
   User	Provides read-only access to view all the non-sensitive information on the system controller. Has write access to change password only.

   Option	Description
   Admin	Used for the chassis partition administrator. Provides access to the chassis partition CLI and webUI to configure the system at the chassis partition level (unrestricted read/write access). Can unlock Operator users. Logs in to the chassis partition management IP address.
   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.
   Operator	Used for the chassis partition operator. Provides read access to chassis partition configuration using the chassis partition CLI and webUI. Has write access to change password only. Logs in to the chassis partition management IP address.
   User	Provides read-only access to view all the non-sensitive information on the chassis partition. Has write access to change password only.

9. For Authorized Keys, add the required list of keys.

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 existing expiry date including lengthening or shortening the duration/date. The selected and saved date will be in YYYY-MM-DD format.

11. Click Save & Close.

The user account is created where you are working at either the chassis level or the chassis partition. Create as many users as needed to manage the system at the chassis level and the chassis partition.

Authentication and access management 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.

Add a user from the CLI

You can create additional users on your system from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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. 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:

   Copy

   syscon-1-active(config)# system aaa authentication users user testuser 
     config username test role admin expiry-date 2025-12-20

   Note: The dates specified in the example use local time. However, the operating system uses midnight UTC on the specified date, not the local time shown.

   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 (chassis or chassis partition).
   limited	Is for F5 internal use only.
   operator	Has read-only access to every screen and every configuration object at the level in which they are working (chassis or chassis partition).
   partition_n	Has admin access to a specific chassis partition. The chassis administrator can create one terminal server role per chassis partition, where n refers to the chassis partition ID. When a user with the chassis partition_n role logs in to a specific blade port, they are presented with the blade console through the terminal server. This is for troubleshooting and debugging the system.
   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	Has full read/write access and can make configuration changes at all levels, including the Bash shell.
   ts_admin	Has admin access to the terminal server (TS). A user with this role has terminal server access to all consoles on the system regardless of chassis partition restrictions.
   user	Is unprivileged and cannot do anything on the system. One or more supported roles need to be assigned to make this user account useful.
   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 to set a password for the user named testuser:

   Copy

   syscon-1-active(config)# system aaa authentication users user testuser config set-password password

   Note: 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 the following fields if required.

   Field	Description
   authorised-keys	SSH public key for the user
   expiry-status	Account expiration 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 VELOS system from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

   Copy

   syscon-1-active(config)# system aaa authentication users user testuser 
   config expiry-status locked

   Note: The dates specified in the example use local time. However, the operating system uses midnight UTC on the specified date, not the local time shown.

4. Commit the configuration changes.

   commit

Delete a user from the CLI

You can delete a specified user from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

   Copy

   syscon-1-active(config)# no system aaa authentication users user testuser

4. Commit the configuration changes.

   commit

Configure local password policy from the CLI

A password policy lets you ‌to set rules for valid passwords. You can configure local password policy at both the chassis and the chassis partition levels from either the system controller or the chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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 local password policy.

   system aaa password policy config

   A summary of the example displays:

   Copy

   syscon-1-active(config)# system aaa password-policy config
   Possible completions:
     apply-to-root          Apply password policy to administrators when setting passwords for other user 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-days               Number of days the user must wait before changing their password again.
     min-length             Minimum length of a new password.
     reject-username        Reject passwords that contain the username.
     remember               Number of previous user passwords that will be saved in the system.
     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.
     warn-age               Number of days before the password expires to start warning the user.

   In the following example, you can specify the number of days after which a password will expire since it was last changed:

   Copy

   syscon-1-active(config)# system aaa password-policy config max-age <number-of-days>

   Set the expiry-date to a future date in yyyy-mm-dd format or set the expiry-date to -1 to indicate that the account never expires:

   Copy

   syscon-1-active(config)# system aaa authentication users user <user-name> config expiry-date { -1 | <yyyy-mm-dd> }

   Note: The dates specified in the example use local time. However, the operating system uses midnight UTC on the specified date, not the local time shown.

   Similarly, you can set up the other required fields as described in the above example.

4. Commit the configuration changes.

   commit

Set an admin password from the CLI

You can set an admin user’s password from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

   Copy

   syscon-1-active(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 either the system controller or chassis partition 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 controller or chassis partition 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*>

   Set the expiry-date to a future date in yyyy-mm-dd format or set the expiry-date to -1 to indicate that the account never expires.

   system aaa authentication users user <*user-name*> config expiry-date { -1 | <*yyyy-mm-dd*> }

   This example indicates that passwords expire on 2021-12-12:

   Copy

   syscon-1-active(config)# system aaa password-policy config max-age 2021-12-12

   Note: The dates specified in the example use local time. However, the operating system uses midnight UTC on the specified date, not the local time shown.

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.

Change a password from the CLI

You can change the password for a specified user from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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:

   Copy

   syscon-1-active(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 user options from the CLI

You can modify or set options for a specified user from either the system controller or chassis partition CLI.

1. Log in to the command line interface (CLI) of the system controller or chassis partition 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 <*mm-dd-yyyy*>

   This example sets a last change date of zero (0) and an expiration date of January 1, 2030 for an admin user named testuser:

   Copy

   syscon-1-active(config)#  system aaa authentication users user testuser 
     config last-change 0 expiry-date 01-01-2030

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 controller or chassis partition 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:

   Copy

   syscon-1-active(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.

   Copy

   system aaa authentication config basic enabled: Changing the basic auth will restart the HTTP service.Proceed? { yes | no }

6. Commit the configuration changes.

   commit

Note: 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 controller or chassis partition 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:

   Copy

   syscon-1-active(config)# system aaa restconf-token config lifetime 120

   Note: The default RESTCONF token lifetime is 15 minutes and can be configured for a maximum of 1440 minutes.

4. Commit the configuration changes.

   commit

Note: 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 controller or chassis partition 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:

   Copy

   syscon-1-active(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 controller or chassis partition 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.

   Copy

   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 through 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 through 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 controller 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.

   system aaa authentication roles role superuser config users <*user-name*>

   This example sets a superuser named testuser:

   Copy

   syscon-1-active(config)# system aaa authentication roles role superuser config users [ testuser ]

   Note: 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:

   Copy

   bash-4.2$ f5sh show vlans vlan

   Configure sshd idle timeout:

   Copy

   
   
     bash-4.2$ f5sh "config; system settings config sshd-idle-timeout 100; commit"

   Parse command output with unix command line utilities:

   Copy

   
   
     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