Authentication & Access

Authentication and access overview

You can manage the rSeries system from the CLI, the webUI, or using REST APIs. The rSeries system has two levels of user management:

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

User roles overview

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

User roles

This table lists user roles at the system level.

Role Description
admin Provides access to the system CLI or webUI to configure system-level settings with unrestricted read/write access. Can unlock any system users. Logs in to the active management IP address. No Bash access. Has broader ability to configure management interfaces, install Base OS software, modify settings, activate licensing, perform user management, and configure network settings, port groups, interfaces, VLANs, LAGs, log settings, tenant deployments, and system settings.

Important: The default login credentials are admin/admin. When logging in as admin for the first time, the system prompts you to change the password, which also changes the default password for the root account to match that of the admin account.
limited F5 internal use only.
Operator Allows read access to system-level configuration from the CLI or webUI and write access to change password only. Logs in to the active management IP address. No Bash access.

Has read-only access to every screen and every configuration object at the level in which they are working. If an operator tries to modify any setting, the system displays a warning that explains that their role is unauthorized to make the configuration change.
resource admin Similar to the Admin user role, but cannot create, modify, or delete local user accounts; create, modify, or delete server groups; or modify any authentication settings. This user role can modify their own user detail to change their own password.
root Created by the system. Used by the system administrator. Provides Bash shell access to the entire system, including all components. The root user is the only user that has Bash access. The system root account can be accessed from the management IP address and from a console. The root password can be changed using the passwd command, or by an admin user from the CLI.

On first login, you are forced to change the password. If you change the root user password and the admin password is 'admin' at that time, the admin user will have the same new password.

Warning: F5 recommends disabling the root account using appliance mode in production to reduce the attack surface and protect it from vulnerabilities.
tenant-console Has virtual console access to tenants from the CLI. Tenant console access is authenticated by tenant root credentials. No access to any part of the rSeries system.
user This role grants users permission to view all objects on the system except for sensitive data such as events, user login activity, files and directories, and configuration backup. This user role cannot modify any system configurations; however, users can change their own password.
superuser This role provides sudo privileges and Bash access to the system, allowing users with the superuser role to execute commands from the Bash shell. To get the Bash shell, users must set the 'superuser-bash-access' flag in ConfD to 'true' and turn off appliance mode.

Remote authentication overview

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

Enable remote authentication from the webUI

If you want to use a remote authentication server with your rSeries system, you can configure remote authentication from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authentication & Access > Authentication Settings.

  3. For Authentication Methods, from the Available list, select one or more options and click the arrows to move them to the Selected list.

    The authentication server must be configured and reachable from the system.

    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.

When a user logs in, the system attempts to authenticate them against the configured authentication methods. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

Configure remote authentication priority from the webUI

You can configure the order in which the rSeries system attempts authentication methods when a user logs in to the system from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authentication & Access > Authentication Settings.

  3. For Authentication Methods, from the Selected list, select an authentication method and click the arrows to move it up or down in the list.

    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.

  • Click Save.

Create authentication server groups from the webUI

You can create authentication server groups to organize servers using the same type of authentication method.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authentication & Access > Server Groups.

  3. Click Add, The Add Server Group drawer form displays.

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

  5. For Provider Type, select LDAP, OCSP, RADIUS, or TACACS+ to qualify the type of servers that will be in the group.

  6. Click Save.

You have created the authentication server group.

Next, you can add servers to the server group.

Add servers to authentication server groups from the webUI

Before you add server groups, you must have previously created at least one server group. You can add servers to an authentication server group from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authentication & Access > Server Groups.

  3. Click the server group to which you want to add servers.

    A drawer displays which list all existing server in the server group.

  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.

Add as many servers as needed to the authentication server group. OCSP server groups can contain only one OCSP server.

Group IDs (GIDs) and system authentication roles

Users with the admin role can configure the system to use these authentication methods to authenticate users:

  • External LDAP Server (includes Active Directory)

  • External RADIUS Server

  • External TACACS+ Server

  • Local (local UNIX authentication)

Each user role is internally mapped to a group ID. Users created and managed on external LDAP, Active Directory, RADIUS, or TACACS+ servers must have the same group IDs on the external servers as they do on F5 rSeries systems to enable authentication and authorization to occur on rSeries systems. Users created on external LDAP, Active Directory, RADIUS, or TACACS+ servers must be associated with one of these group IDs on the system.

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 rSeries system.

If F5-F5OS-UID is not set, it defaults to 1001. F5-F5OS-GID is required; if not set, user authentication will fail. The F5-F5OS-USERINFO is a comment field. Essentially, F5-F5OS-GID is the only hard requirement and must coincide with the group ID’s user role.

Group IDs for system roles

This table lists the default group IDs for system roles.

Role Group ID
admin 9000
operator 9001
resource admin 9003
tenant-console 9100
user 9002
superuser 9004

Group ID configuration examples

RADIUS server

The user configuration file is often named /etc/raddb/users. This is an example of an entry for an administrator with admin privileges:

radius\_user Cleartext-Password := test F5-F5OS-UID := 1001, F5-F5OS-GID := 9000, F5-F5OS-SECONDARYGIDS := “9004”, F5-F5OS-HOMEDIR := "/tmp", F5-F5OS-SHELL := "/var/lib/controller/f5\_confd\_cli"

TACACS+ server

For example, on a TACACS+ server, the user configuration file is typically named /etc/tac_plus.conf. This is an example of an entry for an administrator with admin privileges:

group = admin { service = ppp protocol = ip { default attribute=permit F5-F5OS-UID=1001 F5-F5OS-GID=9000 F5-F5OS-HOMEDIR=/tmp F5-F5OS-USERINFO=test\_user }
}

user = test\_tacacs\_user { global = cleartext "test-tacplus" member = admin
}

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 configure multiple remote authentication methods at a time but can only assign one remote GID to a specific primary GID. If you switch from LDAP to RADIUS, for example, you will have to reconfigure the settings for RADIUS. If you then decide to go back to LDAP, you will have to reconfigure again. F5 recommends that you avoid assigning multiple F5-mapped GIDs to a single user account.

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

You can configure a custom remote group ID (GID) from the webUI to a specific role for all remote authentication methods (LDAP, RADIUS, TACACS+). You can also configure a LDAP group from the webUI to a specific role for the LDAP authentication method.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > Users & Roles.

  3. Expand the roles section to view all the Roles information.

  4. Click on any role from the Role Name to edit the role. The Edit Role drawer displays.

  5. Enter GID number and LDAP group name in the Remote GID and LDAP Group fields respectively.

    The LDAP group name must be a valid LDAP filter entry. For example, ‘cn=my_ldap_group’.

    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.

  6. Click Save.

LDAP/AD configuration overview

You can configure the rSeries system to use an LDAP or Microsoft Windows Active Directory (AD) server for authenticating rSeries system user accounts. Before you begin:

  • Verify that the LDAP service is set up on a server that is accessible to the rSeries system. The default port for the LDAP service is 389 for unsecure protocol (LDAP) or 636 for secure protocol (LDAPS). If the service is configured with a different port, make note of it, as you will need that port number during configuration.

  • Import one or more LDAP certificates if you want to verify the certificate of the authentication server.

  • Assign users to valid system group IDs on the external LDAP or Active Directory servers. For more information, see Group IDs (GIDs) and system authentication roles.

  • For the system to recognize an Active Directory user, the user’s uidNumber attribute must be set to a valid value. The gidNumber for important groups must also be set to a valid value. While these attributes are typically present in a basic LDAP configuration, they are often missing from a basic AD configuration.

LDAP/AD configuration from the webUI

Configure LDAP/AD authentication from the webUI

You can configure the use of LDAP/Active Directory (AD) authentication with rSeries systems from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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.

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

  2. For Base DN, type the base distinguished name (name-value pairs) from which to start the search for the LDAP user (for example, dc=example,dc=org).

  3. For Bind, specify the information for binding the LDAP service account.

    a. 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).

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

    c. For Confirm, retype the password.

    To clear the password, click Clear.

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

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

  6. For Idle Timeout, specify the maximum amount of time, in seconds, that an LDAP connection can be inactive before the connection is closed.

  7. For LDAP Version, select the version of the LDAP protocol to use. The default value is 3.

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

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

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

  1. For TLS CA Certificate, click Show and paste the contents of the X.509 certificate (self-signed or from a CA) for peer authentication.

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

  1. In the TLS Certificate field, click Show and paste the text of the local certificate for client TLS authentication.

  2. In the TLS Key field, click Show and paste the text of the private key for client TLS authentication.

  3. For Authenticate with Active Directory, select True if you want LDAP to authenticate against an Active Directory (AD) server.

  4. For Unix Attributes,

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

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

  5. Click Save.

    LDAP/AD authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

    Next, you can create a server group.

Configure an LDAP/AD server group from the webUI

You can configure an LDAP/Active Directory (AD) server group from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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.

  7. Add servers to the server group:

    On the Server Group screen, click on the Server Group name, it opens a drawer from that shows existing servers in the server group.

    Click on Add to Add a new server in the server group.

    a. For Host, type the IPv4, IPv6 address, or FQDN of the LDAP server to add.

    b. For Port, make sure the port number is correct for LDAP traffic. The default value is 636.

    c. From the Type list, select LDAP over TCP or **LDAP over SSL **(secured) depending on which is upported.

  8. Click Save.

Add as many servers as needed to the group.

RADIUS configuration overview

You can configure the rSeries system to use a RADIUS server for authenticating rSeries 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 rSeries system. The default port for RADIUS service is 1812. If the service is configured with a different port, make note of it, as you will need it during the configuration.

RADIUS dictionary

When configuring remote RADIUS authentication for the F5 system, you add these F5OS vendor-specific attributes (VSA) to the F5 vendor-specific RADIUS dictionary file on the RADIUS server. Be sure to add the vendor lines if you are using the RADIUS server for the first time.

VENDOR          F5                     3375 
BEGIN-VENDOR    F5
ATTRIBUTE       F5-F5OS-UID                 21   integer
ATTRIBUTE       F5-F5OS-GID                 22   integer
ATTRIBUTE       F5-F5OS-HOMEDIR             23   string
ATTRIBUTE       F5-F5OS-SHELL               24   string
ATTRIBUTE       F5-F5OS-USERINFO            25   string
ATTRIBUTE       F5-F5OS-SECONDARYGIDS       26   string
END-VENDOR      F5

RADIUS configuration from the webUI

Configure RADIUS authentication from the webUI

You can configure the use of RADIUS authentication with rSeries systems from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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 the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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.

  7. Click the server group to which you want to add servers.

A drawer that shows servers within the Server Group displays.

  1. Click Add.

  2. For Host, enter the IPv4, IPv6 address, or FQDN of the RADIUS server to add.

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

    The default value is 1812.

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

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

    The default value is 5.

  6. Click Save.

Add as many servers as needed to the group.

TACACS+ configuration overview

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

TACACS+ configuration from the webUI

Configure TACACS+ authentication from the webUI

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

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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.

  1. Click Save.

TACACS+ authentication for users is configured on the system. When a user logs in, the system attempts to authenticate them against the configured authentication method. When the account has a match within any of the configured authentication methods, the user is authenticated and given access.

Next, you can create a server group.

Configure a TACACS+ server group from the webUI

You can configure a TACACS+ server group from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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.

  7. Click the server group to which you want to add servers.

    A drawer displays that shows the servers in that server group.

  8. Click Add.

  9. For Host, 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.

Add as many servers as needed to the group.

OCSP configuration overview

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

OCSP configuration from the webUI

Configure OCSP for certificate validation from the webUI

You can configure Online Certificate Status Protocol (OCSP) for certificate validation from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > Authentication Settings.

  3. In the OCSP Configuration area, click Show to expand the settings.

  4. For OCSP Checking, select Disabled or Enabled.

    The default value is Disabled.

  5. In the OCSP Configuration area, for Nonce Request, specify whether queries to OCSP responders should include a nonce (a unique identifier) in the request.

  6. For Override Responder, specify whether the OCSP default responder is required for certificate validation.

  7. For Response Max Age, specify the maximum amount of time, in seconds, for Online Certificate Status Protocol (OCSP) responses.

  8. For Response Time Skew, specify the maximum allowable time skew, in seconds, for Online Certificate Status Protocol (OCSP) response validation.

  9. Click Save.

    Next, you can create a server group.

Configure an OCSP server group from the webUI

You can configure an Online Certificate Status Protocol (OCSP) server group from the webUI. The server group can contain only one OCSP server.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > Server Groups.

  3. The Provider Type is set when you create the server group, and it cannot be changed here.

  4. For Host, type the IPv4 address, IPv6 address, or the fully qualified domain name (FQDN) of the OCSP server.

  5. For Port, enter the port for the OCSP server.

    The default value is 80.

  6. Click Save.

    The OSCP server is added to the server group.

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.

Transport Layer Security (TLS) configuration overview

Before rSeries systems can exchange data with one another, they must exchange device certificates, that is, digital certificates and keys used for secure communication.

If you are using LDAP with transport layer security (TLS) for user authentication, you can choose to require TLS Certificate Validation in the authentication settings. You can add a certificate and key into the system, and when you create a certificate signing request (CSR), it saves the generated key and certificate to these directories:

  • system/aaa/tls/config/key

  • system/aaa/tls/config/certificate

When you install an SSL certificate, you also install a certificate authority (CA) bundle, which is a file that contains root and intermediate certificates. The CA bundle and server certificate complete the SSL chain of trust.

The rSeries system also supports using self-signed certificates.

You can also configure a Certificate Revocation List (CRL) entry for the system to use to check revocation status of a certificate prior to authenticating a client. Note that once you have configured a CRL, there must be a CRL certificate for each CA. If there are two CAs configured and one CRL is been added for one of the CAs, you need to provide a CRL for the other CA even if it is not revoked.

As an alternative to CRLs, you can also use Online Certificate Status Protocol (OCSP). You can configure the system to use both at the same time. For more information about OCSP, see OCSP configuration overview.

For information about client certification authentication, see Client certificate authentication overview.

Client certificate authentication overview

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

Client certificate authentication from the webUI

Configure client certificate verification from the webUI

You can enable verification of httpd client certificates from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > TLS Configuration.

  3. In the Client Certificate Verification area, click Edit icon.

    The Client Certificate Verification drawer 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.

Certificate management from the webUI

View a certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method in the system (AUTHENTICATION & ACCESS > Authentication Settings).

You can view a certificate from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click AUTHENTICATION & ACCESS > TLS Configuration.

  3. To display a TLS Certificate, a TLS Key that was previously installed, or the TLS Details, click Show.

    A text area opens and displays the certificate, key, or details.

View or configure a TLS key and certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method (AUTHENTICATION & ACCESS > Authentication Settings).

You can view or replace TLS device certificates from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click AUTHENTICATION & ACCESS > TLS Configuration.

  3. To display a previously-installed TLS certificate or key, or to install a TLS certificate or key, in the TLS Certificate & Key area, click Show.

    A text area opens and displays the certificate or key, if one has been previously installed.

  4. To install a TLS Certificate, paste the text of the local certificate for client TLS authentication into the text box.

  5. To install a TLS Key, paste the text of the local certificate for client TLS authentication into the text box.

    a. If the TLS key is encrypted, a TLS key passphrase is required. For TLS Key Passphrase, enter the passphrase.

  6. Click Save.

Configure a Certificate Authority (CA) bundle from the webUI

You can add or delete a Certificate Authority (CA) bundle from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click AUTHENTICATION & ACCESS > TLS Configuration.

  3. In the CA Bundles area, click Add.

    The Add CA Bundle screen displays.

  4. For Name, enter the bundle name.

  5. For TLS CA Certificate, paste the certificate text.

  6. Click Save.

  7. To delete a CA bundle, in the CA Bundles area, select the bundle name in the table and then click Delete.

Create a self-signed certificate from the webUI

Before you can install device certificates, you must enable LDAP as an authentication method in the system (Authenticate & Access > Authentication Settings).

You can create or view a self-signed certificate from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > TLS Configuration.

  3. In the TLS Certificate & Key Section, click Create Certificate.

    The Create Certificate drawer displays.

  4. In the Name field, enter a name for the certificate.

    For example, the server’s hostname.

  5. In the Email field, enter the email address for the certificate contact.

  6. In the SAN field, enter additional domain names that you want to associate with the self-signed certificate.

  7. In the City field, enter the city or locality name.

  8. In the State field, enter the state, county, or region.

  9. In the Country field, enter the two-letter country code.

    For example, US for United States.

  10. In the Organization field, enter the certificate originator name.

    For example, your company’s name.

  11. In the Unit field, enter the organizational unit name.

    For example, IT.

  12. In the Version field, specify the version number for the certificate.

  13. In the Days Valid field, specify the number of days the certificate is valid.

  14. For Key Type, select a key type.

    Available options are RSA, ECDSA, Encrypted RSA, or Encrypted ECDSA. Additional fields display. If you select an encrypted option, the Key Passphrase and Confirm Key Passphrase fields display. a) For Key Passphrase, enter the key passphrase.

    This field is required. The range is between 6 and 255 characters.

    b) For Confirm Key Passphrase, re-enter the key passphrase to confirm.

  15. In the Store TLS field, choose whether to store your TLS information.

  16. Click Save.

Create a Certificate Signing Request (CSR) from the webUI

You can create and view certificate signing requests (CSRs) from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > TLS Configuration.

  3. In the TLS Certificate & Key section area, click Create CSR.

    The Create CSR drawer displays.

  4. In the Name field, enter the common name for the certificate.

    For example, the server’s hostname.

  5. In the Email field, enter the contact email address for the certificate.

  6. In the SAN field, enter additional domain names that you want to associate with the self-signed certificate.

  7. In the City field, enter the city or locality name.

  8. In the State field, enter the state, county, or region.

  9. In the Country field, enter the two-letter country code. For example, US for United States.

  10. In the Organization field, enter the full name of the certificate originator organization. For example, your company’s name.

  11. In the Unit field, enter the organizational unit or division name. For example, IT.

  12. In the Version field, specify the certificate version.

    The default value is 1.

  13. Click Save.

Authentication and access management from the webUI

Configure basic authentication from the webUI

You can configure basic authentication (user name and password) from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > Authentication Settings.

  3. For Basic Authentication, select whether to enable authenticating using a username and password.

    The default value is Enabled.

  4. Click Save.

Configure token lifetime from the webUI

You can choose how long your webUI session will remain active (in minutes) by configuring the token lifetime from the webUI.

  1. Log in to the webUI using an account with admin access.

  2. On the left, click Authenticate & 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.

    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.

Configure local password policy from the webUI

Password Policy Configuration

A password policy enables you to qualify criteria for valid passwords and configure maximum password attempts for local authentication (/etc/passwd).

  1. Log into the webUI using an account with admin access.

  2. On the left, click Authenticate & Access > Authentication Settings.

  3. In the Local Password Policy area:

    • For Minimum Length, type the minimum number of characters required for a password. The allowed range is 6 to 255.

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

  5. For New/Old Password Differential, enter the number of character changes in the new password that differentiate it from the old password.

    The default value is 8.

  6. For Disallow Username, select whether to check the password for the user name in forward or reversed form.

    When set to True, if any variant of the username is found in the password, the new password is rejected.

  7. Set Apply Password Policy to Root Account to True to use the same password policy for the root account. The default value is False.

  8. For Maximum Password Retries, enter the number of times a user can try to create an acceptable password at the prompt.

    The default value is 3.

  9. For Maximum Login Attempts, enter the allowed number of times a user can attempt to log in before the account is temporarily suspended.

    The default value is 10 tries. If set to 0, there is no limit to the number of login attempts.

  10. For Lockout Duration, type the amount of time in minutes that must lapse before a previously suspended user’s account is unlocked.

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

  11. For Max Password Age, type the maximum number of days after which the password will expire after being changed.

    If the last change was today and Maximum Password Age is 90, then the password will expire in 91 days. If set to 0 (the default), the password never expires.

  12. For Max Class Repeat, type the maximum number of repeating upper/lowercase letters, digits, or special characters such as !@#$% allowed in the password.

  13. For Max Letter Repeat, type the maximum number of repeating lower-case letters allowed in the password.

  14. For Max Sequence Repeat, type the maximum number of repeating upper/lowercase letters or digits allowed in the password.

  15. Click Save.

You have configured the local password policy. On the same screen, you can configure other authentication settings.

Add users from the webUI

You can add users to the rSeries system from the webUI. Default root and admin accounts are provided on the system.

You can change the passwords on those accounts, but they cannot be deleted.

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 webUI using an account with admin access.

  2. On the left, click Authenticate & Access > Users & Roles.

  3. Click Add.

  4. For Authentication Method, the value is fixed as Local.

  5. For Username, create a name for the user.

  6. For Set Password, create a valid password according to the local password policy defined in the Authentication Settings.

  7. For Confirm Password, retype the password.

  8. From the Role list, select the role to assign appropriate capabilities for the user. Both Primary Role and Secondary Role fields have the following options:

Option Description
Admin Used for the system administrator. Provides access to the CLI or webUI to configure the system (unrestricted read/write access). Can unlock any users.
Resource Admin Similar to the Admin user role, but cannot create, modify, or delete local user accounts; create, modify, or delete server groups; or modify any authentication settings. This user role can modify their own user detail to change their own password.
Operator Provides read access to system. Has write access to change password only.
User Provide read-only access to view all the non-sensitive information on the system. Has write access to change password only.

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

    **Note:**Users with Admin roles or privileges can add, change, or remove authorized keys for themselves or other user accounts. A new multi-line field labeled Authorized Keys is added to the Add or Edit User form, and only administrators have access to it. When an administrator creates a new user account, they can add one or more authorized keys to the field, in addition to setting the user’s password, role, and expiration date.

  2. From the Expiry Status list, select the applicable status.

Available options are:

Option Description
Enabled This option enables the selected expiry date which means the user account login is available.
Locked This options allows the expiry date is locked until the new expiry date is selected. It means the user account login is not available or expired.
Expiry date When Expiry date is selected, this option displays a calendar widget. The user can select a future date and adjust an existingexpiry date including lengthening or shortening the duration/date. The selected and saved date will be in YYYY-MM-DD format.

  1. Click Save.

Create as many users as needed to manage the system.