F5 Logo MyF5
Search
  1. MyF5 Home
  2. F5 rSeries Systems: Administration and Configuration
  3. User Management
Manual Chapter : User Management

Applies To:

Show Versions Show Versions

F5OS-A

  • 1.3.2, 1.3.1, 1.3.0
Manual Chapter

User Management

User management overview

You can manage the
rSeries
 system from the CLI, the webUI, or using REST APIs.
The
rSeries
 system has
two
 levels of user management:
System level
At the system level, after basic configuration is complete, the system includes default root (Bash access only) and admin accounts to log in to. 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, the users and user management are not covered in this guide. For more information, see the tenant documentation (such as
BIG-IP
 software documentation) at my.f5.com.

Configure the authentication token lifetime from the CLI

You can configure the length of the authentication token lifetime from the CLI. This enables you to bypass reauthenticating your SSH or webUI sessions for up to 24 hours.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Configure the authentication token lifetime.
    system aaa restconf-token config lifetime <
    number-of-minutes
    >
    This example configures the authentication token lifetime to 120 minutes:
    appliance-1(config)# system aaa restconf-token config lifetime 120
  4. Commit the configuration changes.
    commit

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.
rSeries user roles
Role
Description
admin
Provides access to the system CLI or webUI to configure the system-level settings with unrestricted read/write access. Can unlock any system users. Logs in to the active management IP address. No Bash access.
Has broader ability and can configure management interfaces, install Base OS system software, modify system settings, activate licensing, perform user management, and configure network settings, port groups, interfaces, VLANs, LAGs, log settings, tenant deployments, and system settings.
The default login credentials are admin/admin. When logging in as admin for the first time, the system prompts you to change the password. This also changes the default password for the root account to match that of the admin account.
limited
F5 internal use only.
operator
Allows read access to system level configuration from the CLI or webUI and write access to change password only. Logs in to the active management IP address. No Bash access.
Has read-only access to every screen and every configuration object at the level in which they are working. If an operator tries to modify any setting, however, the system displays a warning that explains that their role is unauthorized to make the configuration change.
root
Created by the system. Used by the system administrator. Provides Bash shell access to the entire system including all components. The system root account can be accessed from the management IP address and from a console. The root password can be changed using the
passwd
 command, or by an admin user from the CLI.
On first login, you are forced to change the password. If you change the root user password and the admin password is ‘admin’ at that time, the admin user will have the same new password.
F5
 recommends disabling the root account using appliance mode in production to reduce the attack surface of the system and protect it from any vulnerabilities.
tenant-console
Has virtual console access to tenants from the CLI. Tenant console access is authenticated by tenant root credentials. No access to any part of the
rSeries
 system.

Group IDs and system authentication roles

You 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
rSeries
 systems to enable authentication and authorization to occur on
rSeries
 systems. Users created on external LDAP, Active Directory, RADIUS, or TACACS+ servers must be associated with one of these group IDs on the system.
You can only use existing roles and cannot create new roles.
The group IDs are specified in a user configuration file on the external server (file locations vary on different servers). You can assign these F5 user attributes:
F5-F5OS-UID=1001
F5-F5OS-GID=9000   <-- THIS MUST MATCH /etc/group items   
F5-F5OS-HOMEDIR=/tmp  <-- Optional; prevents sshd warning msgs 
F5-F5OS-USERINFO=test_user  <-- Optional user info 
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. If F5-F5OS-GID is not set, it defaults to 0 (disallowed for authentication). The F5-F5OS-USERINFO is a comment field. Essentially, F5-F5OS-GID is the only hard requirement and must coincide with group ID's user role (except for the root role where the GID is 0).

Group IDs for system roles

This table lists group IDs for system roles.
Role
Group ID
admin
9000
operator
9001
root
0
tenant-console
9100

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-HOMEDIR := "/tmp",
        F5-F5OS-SHELL := "/var/lib/controller/f5_confd_cli"

TACACS+ server

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

user = test_tacacs_user {
	global = cleartext "test-tacplus"
	member = admin
}

Display user roles from the CLI

You can display the administrator roles with their associated group IDs from the CLI using an account with admin or operator access.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Display user roles for the system.
    show system aaa authentication roles
    A summary similar to this example displays: 
    appliance-1# show system aaa authentication roles
ROLENAME        GID   USERS
-----------------------------
admin           9000  -
operator        9001  -
root            0     -
tenant-console  9100  -

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 the
    Group IDs and system authentication roles
     section.

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
    USER MANAGEMENT
    Auth Settings
    .
  3. To enable an external authentication server, in Authentication Methods, select
    LDAP
    .
    The LDAP server must be configured and reachable from the system.
    By default, local authentication is always enabled, so an administrator can access the system in case of external authentication server failure.
  4. In the Common LDAP Configuration area, 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
    ).
    The settings in the Common LDAP Configuration area are required only if you want to use LDAP and create LDAP server groups with LDAP servers.
  5. For
    Bind
    , specify the information for binding the LDAP service account.
    1. For
      DN
      , type 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
      , type the admin password for the LDAP server.
      F5 recommends that the LDAP service account password is set to never expire. Otherwise, if it expires, LDAP authentication will not be possible and might result in users getting locked out of the system.
    3. For
      Confirm
      , retype the password.
  6. For
    Connect Timeout (seconds)
    , specify the maximum amount of time, in seconds, that the system waits before timing out when trying to reach the LDAP server.
  7. For
    Read Timeout (seconds)
    , specify the maximum amount of time, in seconds, that the system waits to receive an LDAP response before aborting the read attempt.
  8. For
    Idle Timeout (seconds)
    , specify the maximum amount of time, in seconds, that an LDAP connection can be inactive before the connection is closed.
  9. For
    LDAP Version
    , select the version of the LDAP protocol to use.
    The default value is
    3
    .
  10. For
    Chase Referrals
    , select whether to enable LDAP referral chasing.
    The default value is
    True
    , which specifies that the system queries all LDAP servers in the domain. This might cause delays and timeouts when authenticating against an LDAP server.
  11. If the LDAP server has Transport Layer Security (TLS) support, from the
    TLS
     list, 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.
  12. 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.
  13. For
    TLS CA Certificate
    , click
    Show
     and paste the contents of the X.509 certificate (self-signed or from a CA) for peer authentication.
  14. For
    Cipher String
    , type 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.
  15. In the
    TLS Certificate
     field, click
    Show
     and paste the text of the local certificate for client TLS authentication.
  16. In the
    TLS Key
     field, click
    Show
     and paste the text of the private key for client TLS authentication.
  17. For
    Authenticate with Active Directory
    , select
    True
     if you want LDAP to authenticate against an Active Directory (AD) server.
  18. Click
    Save
    .
  19. Create a server group:
    1. On the left, click
      USER MANAGEMENT
      Server Groups
      .
    2. Click
      Add
      .
    3. For
      Name
      , create a recognizable name for the server group.
    4. For
      Provider Type
      , select
      LDAP
       to qualify the type of servers that will be in the group.
    5. Click
      Save & Close
      .
  20. Add servers to the server group:
    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.
    4. Click
      Save & Close
      .
      Add as many servers as needed to the group.
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.

LDAP/AD configuration from the CLI

Configure LDAP/Active Directory authentication from the CLI

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

Add LDAP certificates from the CLI

You can add the LDAP certificates and key from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Add the TLS config key:
    system aaa tls config key (<
    AES-encrypted-string
    >)
    A summary similar to this example displays:
    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:
    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
rSeries
 system to use a RADIUS server for authenticating
rSeries
 system user accounts.
Before you begin, you must verify that the RADIUS service is set up on a server that is accessible to the
rSeries
 system. The default port for RADIUS service is 1812. If the service is configured with a different port, make note of it, as you will need it during the configuration.
  • Assign users to valid system group IDs on the external RADIUS server. See the
    Group IDs and system authentication roles
     section for more information.

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

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
    USER MANAGEMENT
    Auth Settings
    .
  3. To enable an external authentication server, in Authentication Methods, select
    RADIUS
    .
    The RADIUS server must be configured and reachable from the system.
    By default, local authentication is always enabled, so an administrator can access the system in case of external authentication server failure.
  4. Click
    Save
    .
  5. Create a server group:
    1. On the left, click
      USER MANAGEMENT
      Server Groups
      .
    2. Click
      Add
      .
    3. For
      Name
      , create a recognizable name for the server group.
    4. For
      Provider Type
      , select
      RADIUS
       to qualify the type of servers that will be in the group.
    5. Click
      Save & Close
      .
  6. Add servers to the server group:
    1. On the left, click
      USER MANAGEMENT
      Server Groups
      .
    2. Click the server group to which you want to add servers.
      The Edit Server Group screen displays.
    3. Click
      Add
      .
    4. For
      Server
      , type the IPv4, IPv6 address, or FQDN of the RADIUS server to add.
    5. For
      Port
      , make sure the port number is correct for RADIUS traffic.
      The default value is
      1812
      .
    6. For
      Secret
      , type the shared secret used to access the server.
    7. For
      Timeout (seconds)
      , type the number of seconds to timeout if unable to access the server.
      The default value is
      5
      .
    8. Click
      Save & Close
      .
      Add as many servers as needed to the group.
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.

RADIUS configuration from the CLI

Configure RADIUS authentication from the CLI

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

TACACS+ configuration overview

You can configure the
rSeries
 system to use a TACACS+ server for authenticating
rSeries
 system user accounts.
Before you begin:
  • Verify that TACACS+ is set up on a server that is accessible to the
    rSeries
     system.
  • Assign users to valid system group IDs on the external TACACS+ server. For more information, see the
    Group IDs for system roles
     section.

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
    USER MANAGEMENT
    Auth Settings
    .
  3. To enable an external authentication server, in Authentication Methods, select
    TACACS+
    .
    The TACACS+ server must be configured and reachable from the system.
    By default, local authentication is always enabled, so an administrator can access the system in case of external authentication server failure.
  4. Click
    Save
    .
  5. Create a server group:
    1. On the left, click
      USER MANAGEMENT
      Server Groups
      .
    2. Click
      Add
      .
    3. For
      Name
      , create a recognizable name for the server group.
    4. For
      Provider Type
      , select
      TACACS+
       to qualify the type of servers that will be in the group.
    5. Click
      Save & Close
      .
  6. Add servers to the server group:
    1. On the left, click
      USER MANAGEMENT
      Server Groups
      .
    2. Click the name of the server group to which you want to add servers.
      The Edit Server Group screen displays.
    3. Click
      Add
      .
    4. For
      Server
      , type the IPv4 address, IPv6 address, or FQDN of the TACACS+ server to add.
    5. For
      Port
      , make sure the port number is correct for TACACS+ traffic.
      The default value is
      49
      .
    6. For
      Secret
      , type the shared secret used to access the server.
    7. Click
      Save & Close
      .
      Add as many servers as needed to the group.
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.

TACACS+ configuration from the CLI

Configure TACACS+ authentication from the CLI

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

User management from the webUI

Configure local password policy from the webUI

A password policy enables you to qualify criteria for valid passwords and configure maximum password attempts for local authentication (
/etc/passwd
).
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    USER MANAGEMENT
    Auth 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
    , type the minimum number of
    Numeric
    ,
    Uppercase
    ,
    Lowercase
    , and
    Special
     characters required in a valid password.
  5. For
    New/Old Password Differential
    , type 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 one of these options:
    Option
    Description
    True
    Check whether the name of the user in forward or reversed form is contained in the password.
    False
    Check for username in password is not required.
    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
    , type 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
    , type 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 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. Click
    Save
    .
You have configured the local password policy. On the same screen, you can configure other authentication settings.

Add users from the webUI

You can add users to the
rSeries
 system from the webUI. Default root and admin accounts are provided on the system. You can change the passwords on those accounts, but they cannot be deleted.
You can create only admin and operator users from the webUI. You can create other roles from the CLI.
  1. Log in to the webUI using an account with admin access.
  2. On the left, click
    USER MANAGEMENT
    Users
    .
  3. Click
    Add
    .
  4. For
    Username
    , create a name for the user.
  5. For
    Set Password
    , create a valid password according to the local password policy defined in the Auth Settings.
  6. For
    Confirm Password
    , retype the password.
  7. From the
    Role
     list, select the role to assign appropriate capabilities for the user.
    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.
    Operator
    Provides read access to system. Has write access to change password only.
  8. Click
    Save & Close
    .
Create as many users as needed to manage the system.

User management from the CLI

Add a user from the CLI

You can create additional users on your system from the CLI.
  1. Log in to the command line interface (CLI) of the system using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Add a user.
    system aaa authentication users user <
    user-name
    > config username <
    user-name
    > role [ admin | root ] expiry-date <
    yyyy-mm-dd
    >
    Where expiry-date is the date <
    yyyy-mm-dd
    > you want the account to expire. Some other values for expiry-date are -1 for no expiration date (the default value), and 1 for expired.
    This example creates an admin user named
    testuser
     with an account expiration date of November 20, 2025:
    appliance-1(config)# system aaa authentication users user testuser config 
username test role admin expiry-date 2023-11-20
    These roles are available:
    Role
    Description
    admin
    Has full read/write access and can make configuration changes at the level in which they are working.
    limited
    F5 internal use only
    operator
    Has read-only access to every screen and every configuration object at the level in which they are working.
    root
    Provides Bash shell access to the entire system including all components.
    tenant console
    Has virtual console access to tenants from the CLI but no access to the rSeries system.
  4. Commit the configuration changes.
    commit
The system creates the account with the specified role.

Disable a user from the CLI

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

Delete a user from the CLI

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

Set an admin password from the CLI

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

Set maximum password age

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

Change a password from the CLI

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

Modify user options from the CLI

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

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information