1. Configuration Guide
  2. Getting Started
  3. User Accounts

User Accounts

In addition to the two factory accounts user and admin, you may also authenticate using local accounts, RADIUS, or TACACS+.

Local User Accounts

The SBC comes with two local, factory accounts for access. System administrators may create additional local accounts for each user or administrator who needs to access the SBC. Local accounts ensure your ability to audit an individual's activity on the SBC.

When creating local accounts, you must specify the username and the user class. Usernames must be unique, and neither user nor admin may be used.

There are two user classes: user and admin. Local accounts in the user class have the same access level as the factory user account, and local accounts in the admin class have the same access level as the factory admin account.

After a second administrator account has been created, you may disable the factory user and admin accounts. The SBC requires at least one administrator account. Only administrators may delete accounts, and administrators may not delete their own account. Use the command factory-accounts to disable or re-enable the factory accounts.

The file cli.audit.log records the timestamp, the local account name, the connecting IP address, and the command run by any user or administrator.
2020-10-01 15:35:06.530 TaskID: 0xab7c8710, admin@10.2.2.7 : 'show users'
2020-10-01 15:36:14.112 TaskID: 0xab7c8710, alice@10.2.2.8 : 'show users'

Local Accounts and TACACS+

When the tacacs-authentication-only attribute is enabled in the security configuration element or when the Admin Security entitltement is enabled, authentication to a local account changes when TACACS+ is configured. If a TACACS+ server is configured and available, then authentication uses TACACS+ and the SBC rejects attempts to authenticate to local accounts. If a TACACS+ server is configured but unavailable, the SBC allows authentication to local accounts. This ensures that, when TACACS+ is configured, authentication to local accounts is only possible when the TACACS+ server is down. If no TACACS+ server is configured, local accounts are accessible.

Local Accounts and SSH Keys

SSH authorized keys take precedence over local accounts. For example, if an administrator imported Alice's SSH key into the admin class, then Alice can authenticate with ssh alice@10.0.0.1 whether or not a local account exists. Moreover, if a local account named alice exists in the user class but an SSH authorized-key exists in the admin class, Alice can still authenticate as an administrator because SSH keys take precedence over local accounts. Conversely, if Alice's SSH key were imported into the user class but a local account in the admin class were created for Alice, she would by default log in as an ordinary user and not as an administrator. This happens because SSH clients usually try public key authentication before attempting password-based authentication. To authenticate using password-based authentication when public key authentication is an option, use the -o option: ssh -o PubkeyAuthentication=no alice@10.0.0.1.

When deleting an account, it is important to remember to delete any unused SSH keys for that user or administrator.

Manage Local Accounts

Use the local-accounts command to create, delete, or modify individual accounts. Use the factory-accounts command to disable or re-enable the default user and admin accounts.

Create a Local Account

The syntax to add a local account:
local-accounts add <username> <class>
The two options for <class> are user and admin.
  1. Create an account.
    To create an account for a user named Jamie:
    ORACLE# local-accounts add jamie user
    To create an account for an administrator named Jamie:
    ORACLE# local-accounts add jamie admin

    Note:

    Usernames are case sensitive.
  2. Enter and confirm the password for the new account.
  3. Save and activate the configuration.

Modify the Password of a Local Account

Administrators may change their own password.

The syntax to change the password of a local administrator account:
local-accounts change-password <username>
  1. Log in to your local administrator account.
  2. Use the local-accounts command to change your password.
    local-accounts change-password jamie
  3. Enter your current password.
  4. Enter and confirm your new password.

The SBC saves and activates the configuration after a password change.

Delete a Local Account

The syntax to delete a local account:
local-accounts delete <username>
  1. Log in as an administrator.
  2. Delete the account.
    ORACLE# local-accounts delete jamie
  3. Confirm you want to delete the account.
  4. Save and activate the configuration.
  5. Delete any saved authorized keys for that user.
    ORACLE# ssh-key authorized-key delete jamie
  6. Use the show users command to display active sessions.
    ORACLE# show users
Index     remote-address    IdNum  duration  type         state        User
------------------------------------------------------------------------------
    2 10.0.0.1:59378        7849  00:01:46      ssh       priv *       admin
    1 10.0.0.1:59373        7842  00:01:57      ssh       user         jamie
    0 127.0.0.1             2701  04:17:39  console       user
  7. Kill any active sessions of the old user.
    ORACLE# kill ssh 1
Killing ssh session [1]
Successfully killed session [ssh-jamie@10.196.0.137] at index[1]

Viewing Local Accounts

To view the local accounts on the SBC, use the show configuration local-accounts command. 

ORACLE# show configuration local-accounts
local-accounts
        user-name                               jamie
        user-class                              user
        user-password                           ******
        last-modified-by                        admin@10.0.0.1
        last-modified-date                      2020-09-28 17:11:38
ORACLE#

Note:

The local-accounts argument to the show command must be written out in full.

Disable the Default Accounts

If you have created a second administrator account, you can disable the default user and admin accounts.

  1. Log in as an administrator.
  2. Run the factory-accounts command.
    ORACLE# factory-accounts disable
  3. Save and activate the configuration.

Re-enable the Default Accounts

If you have disabled the default user and admin accounts, you can re-enable them.

  1. Run the factory-accounts command.
    ORACLE# factory-accounts enable
  2. Save and activate the configuration.

RADIUS Authentication

A security feature that extends beyond the designation of ACLI User and Superuser privileges, the User Authentication and Access control feature supports authentication using your RADIUS server(s). In addition, you can set two levels of privilege, one for all privileges and more limited set that is read-only.

User authentication configuration also allows you to use local authentication, localizing security to the SBC ACLI log-in modes. These modes are User and Superuser, each requiring a separate password.

The components involved in the RADIUS-based user authentication architecture are the SBC and your RADIUS server(s). In these roles:

  • The SBC restricts access and requires authentication via the RADIUS server; the SBC communicates with the RADIUS server using either port 1812 or 1645, but does not know if the RADIUS server listens on these ports
  • Your RADIUS server provides an alternative method for defining SBC users and authenticating them via RADIUS; the RADIUS server supports the VSA called ACME_USER_CLASS, which specifies what kind of user is requesting authentication and what privileges should be granted. Supported values are admin or user, and must be lowercase.
The SBC also supports the use of the Cisco Systems Inc.™ Cisco-AVPair vendor specific attribute (VSA). This attribute allows for successful administrator login to servers that do not support the Oracle authorization VSA. While using RADIUS-based authentication, the SBC authorizes you to enter Superuser mode locally even when your RADIUS server does not return the ACME_USER_CLASS VSA or the Cisco-AVPair VSA. For this VSA, the Vendor-ID is 1 and the Vendor-Type is 9. The list below shows the values this attribute can return, and the result of each:
  • shell:priv-lvl=15—User automatically logged in as an administrator
  • shell:priv-lvl=1—User logged in at the user level, and not allowed to become an administrator
  • Any other value—User rejected

When RADIUS user authentication is enabled, the SBC communicates with one or more configured RADIUS servers that validates the user and specifies privileges. On the SBC, you configure:

  • What type of authentication you want to use on the SBC
  • If you are using RADIUS authentication, you set the port from which you want the SBC to send messages
  • If you are using RADIUS authentication, you also set the protocol type you want the SBC and RADIUS server to use for secure communication

Although most common set-ups use two RADIUS servers to support this feature, you are allowed to configure up to six. Among other settings for the server, there is a class parameter that specifies whether the SBC should consider a specific server as primary or secondary. As implied by these designation, the primary servers are used first for authentication, and the secondary servers are used as backups. If you configure more than one primary and one secondary server, the SBC will choose servers to which it sends traffic in a round-robin strategy. For example, if you specify three servers are primary, the SBC will round-robin to select a server until it finds an appropriate one; it will do the same for secondary servers.

The VSA attribute assists with enforcement of access levels by containing one of the three following classes:

  • None—All access denied
  • User—Monitoring privileges are granted; your user prompt will resemble ORACLE>
  • Admin—All privileges are granted (monitoring, configuration, etc.); your user prompt will resemble ORACLE#

After it selects a RADIUS server, the SBC initiates communication and proceeds with the authentication process. The authentication process between the SBC and the RADIUS server takes place using one of three methods, all of which are defined by RFCs:

Protocol RFC
PAP (Password Authentication Protocol) B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334, October 1992
CHAP (Challenge Handshake Authentication Protocol) B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334, October 1992

W. Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), RFC 1994, August 1996

MS-CHAP-V2 G. Zorn, Microsoft PPP CHAP Extensions, Version 2, RFC 2759, January 2000

Note:

MS-CHAP-V2 support includes authentication only; password exchange is not supported or allowed on the SBC.
Illustration of SBC and RADIUS server communications.

PAP Handshake

For PAP, user credentials are sent to the RADIUS server include the user name and password attribute. The value of the User-Password attribute is calculated as specified in RFC 2865.

PAP Client Request Example
Radius Protocol
Code: Access Request (1)
  Packet identifier: 0x4 (4)
  Length: 61
  Authenticator: 0x0000708D00002C5900002EB600003F37
  Attribute value pairs
    t:User Name(1) l:11, value:”TESTUSER1”
      User-Name: TESTUSER1
    t:User Password (2) l:18, value:739B3A0F25094E4B3CDA18AB69EB9E4
    t:NAS IP Address(4) l:6, value:168.192.68.8
      Nas IP Address: 168.192.68.8(168.192.68.8)
    t:NAS Port(5) l:6, value:118751232
PAP RADIUS Response
Radius Protocol
  Code: Access Accept (2)
  Packet identifier: 0x4 (4)
  Length: 20
  Authenticator: 0x36BD589C1577FD11E8C3B5BB223748

CHAP Handshake

When the authentication mode is CHAP, the user credentials sent to the RADIUS server include “username,” “CHAP-Password,” and “CHAP-Challenge.” The “CHAP-Password” credential uses MD-5 one way. This is calculated over this series of the following values, in this order: challenge-id (which for the Oracle Communications Session Border Controller is always 0), followed by the user password, and then the challenge (as specified in RFC 1994, section 4.1).

CHAP Client Request Example
Radius Protocol
  Code: Access Request (1)
  Packet identifier: 0x5 (5)
  Length: 80
  Authenticator: 0x0000396C000079860000312A00006558
  Attribute value pairs
    t:User Name(1) l:11, value:”TESTUSER1”
      User-Name: TESTUSER1
    t:CHAP Password (3) l:19, value:003D4B1645554E881231ED7A137DD54FBF
    t:CHAP Challenge (60) l:18, value: 000396C000079860000312A00006558
    t:NAS IP Address(4) l:6, value:168.192.68.8
      Nas IP Address: 168.192.68.8(168.192.68.8)
    t:NAS Port(5) l:6, value:118751232
CHAP RADIUS Response
Radius Protocol
  Code: Access Accept (2)
  Packet identifier: 0x4 (4)
  Length: 20
  Authenticator: 0x3BE89EED1B43D91D80EB2562E9D65392

MS-CHAP-v2 Handshake

When the authentication method is MS-CHAP-v2, the user credentials sent to the RADIUS server in the Access-Request packet are:

  • username
  • MS-CHAP2-Response—Specified in RFC 2548, Microsoft vendor-specific RADIUS attributes
  • MS-CHAP2-Challenge—Serves as a challenge to the RADIUS server

If the RADIUS authentication is successful, the Access-Accept packet from the RADIUS server must include an MS-CHAP2-Success attribute calculated using the MS-CHAP-Challenge attribute included in the Access-Request. The calculation of MS-CHAP2-Success must be carried out as specified in RFC 2759. The Oracle Communications Session Border Controller verifies that the MS-CHAP2-Success attribute matches with the calculated value. If the values do not match, the authentication is treated as a failure.

MS-CHAP-v2 Client Request Example

Some values have been abbreviated. 

Radius Protocol
  Code: Access Request (1)
  Packet identifier: 0x5 (5)
  Length: 80
  Authenticator: 0x0000024C000046B30000339F00000B78
  Attribute value pairs
    t:User Name(1) l:11, value:”TESTUSER1”
      User-Name: TESTUSER1
    t:Vendor Specific(26) l:24, vendor:Microsoft(311)
    t:MS CHAP Challenge(11) l:18, value:0000024C000046B30000339F00000B78
    t:Vendor Specific(26) l:58, vendor:Microsoft(311)
    t:MS CHAP2 Response(25) l:52, value:00000000024C000046B30000339F00000B78...
    t:NAS IP Address(4) l:6, value:168.192.68.8
      Nas IP Address: 168.192.68.8(168.192.68.8)
    t:NAS Port(5) l:6, value:118751232
MS-CHAP-v2 RADIUS Response
Radius Protocol
  Code: Access Accept (2)
  Packet identifier: 0x6 (6)
  Length: 179
  Authenticator: 0xECB4E59515AD64A2D21FC6D5F14D0CC0
  Attribute value pairs
    t:Vendor Specific(26) l:51, vendor:Microsoft(311)
      t:MS CHAP Success(11) l:45, value:003533s33d3845443532443135453846313...
    t:Vendor Specific(26) l:42, vendor:Microsoft(311)
      t:MS MPPE Recv Key(17) l:36, value:96C6325D22513CED178F770093F149CBBA...
    t:Vendor Specific(26) l:42, vendor:Microsoft(311)
      t:MS MPPE Send Key(16) l:36, value:9EC9316DBFA701FF0499D36A1032678143...
    t:Vendor Specific(26) l:12, vendor:Microsoft(311)
      t:MS MPPE Encryption Policy(7) l:6, value:00000001
    t:Vendor Specific(26) l:12, vendor:Microsoft(311)
      t:MS MPPE Encryption Type(8) l:6, value:00000006

Management Protocol Behavior

When you use local authentication, management protocols behave the same way that they do when you are not using RADIUS servers. When you are using RADIUS servers for authentication, management protocols behave as described in this section.

  • SSH in pass-through mode—The “user” or admin accounts are authenticated locally, not via the RADIUS server. For all other accounts, the configured RADIUS servers are used for authentication. If authentication is successful, the user is granted privileges depending on the ACME_USER_CLASS VSA attribute.
  • SSH in non-pass-through mode—When you create an SSH account on the Oracle Communications Session Border Controller, you are asked to supply a user name and password. Once local authentication succeeds, you are prompted for the ACLI user name and password. If your user ACLI name is user, then you are authenticated locally. Otherwise, you are authenticated using the RADIUS server. If RADIUS authentication is successful, the privileges you are granted depend on the ACME_USER_CLASS VSA attribute.
  • SFTP in pass-through mode—If you do not configure an SSH account on the Oracle Communications Session Border Controller, the RADIUS server is contacted for authentication for any user that does not have the user name user. The Oracle Communications Session Border Controller uses local authentication if the user name is user.
  • SFTP in non-pass-through mode—The “user” or admin accounts are authenticated locally, not via the RADIUS server. For all other accounts, the configured RADIUS servers are used for authentication.

RADIUS Authentication Configuration

To enable RADIUS authentication and user access on your Oracle Communications Session Border Controller, you need to configure global parameters for the feature and then configure the RADIUS servers that you want to use.

Global Authentication Settings

To configure the global authentication settings, which apply to your configured authentication type:

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
  2. Type security and press Enter. 
    ORACLE(configure)# security
  3. Type authentication and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters. 
    ORACLE(security)# authentication
ORACLE(authentication)#

    From here, you can view the entire menu for the authentication configuration by typing a ?. You can set global parameters for authentication. You can also configure individual RADIUS servers; instructions for configuring RADIUS server appear in the next section.

  4. type—Set the type of user authentication you want to use on this Oracle Communications Session Border Controller. The default value is local. The valid values are:

    • local | radius | tacacs

  5. protocol—If you are using RADIUS user authentication, set the protocol type to use with your RADIUS server(s). The default is pap. The valid values are:

    • pap | chap | mschapv2

  6. source-port—Set the number of the port you want to use from message sent from the Oracle Communications Session Border Controller to the RADIUS server. The default value is 1812. The valid values are:

    • 1645 | 1812 | 3799

  7. allow-local-authorization—Set this parameter to enabled if you want the Oracle Communications Session Border Controller to authorize users to enter Superuser (administrative) mode locally even when your RADIUS server does not return the ACME_USER_CLASS VSA or the Cisco-AVPair VSA. The default for this parameter is disabled.
    When enabled, the Oracle Communications Session Border Controller ignores RADIUS or TACACS restrictions and allows all users to locally enable Superuser (administrative) mode.
RADIUS Server Settings

The parameters you set for individual RADIUS servers identify the RADIUS server, establish a password common to the Oracle Communications Session Border Controller and the server, and establish trying times.

Setting the class and the authentication methods for the RADIUS servers can determine how and when they are used in the authentication process.

To configure a RADIUS server to use for authentication:

  1. Access the RADIUS server submenu from the main authentication configuration: 
    ORACLE(authentication)# radius-servers
ORACLE(radius-servers)#
  2. address—Set the remote IP address for the RADIUS server. There is no default value, and you are required to configure this address.
  3. port—Set the port at the remote IP address for the RADIUS server. The default port is set to 1812. The valid values are:

    • 1645 | 1812

  4. state—Set the state of the RADIUS server. Enable this parameter to use this RADIUS server to authenticate users. The default value is enabled. The valid values are:

    • enabled | disabled

  5. secret—Set the password that the RADIUS server and the Oracle Communications Session Border Controller share. This password is transmitted between the two when the request for authentication is initiated; this ensures that the RADIUS server is communicating with the correct client.
  6. nas-id—Set the NAS ID for the RADIUS server. There is no default for this parameter.
  7. retry-limit—Set the number of times that you want the Oracle Communications Session Border Controller to retry for authentication information from this RADIUS server. The default value is 3. The valid range is:

    • Minimum—1

    • Maximum—5

      If the RADIUS server does not respond within this number of tries, the Oracle Communications Session Border Controller marks is as dead.

  8. retry-time—Set the amount of time (in seconds) that you want theOracle Communications Session Border Controller to wait before retrying for authentication from this RADIUS server. The default value is 5. The valid range is:

    • Minimum—5

    • Maximum—10

  9. dead-time—Set the amount of time in seconds before the Oracle Communications Session Border Controller retries a RADIUS server that it has designated as dead because that server did not respond within the maximum number of retries. The default is 10. The valid range is:

    • Minimum—10

    • Maximum—10000

  10. maximum-sessions—Set the maximum number of outstanding sessions for this RADIUS server. The default value is 255. The valid range is:

    • Minimum—1

    • Maximum—255

  11. class—Set the class of this RADIUS server as either primary or secondary. A connection to the primary server is tried before a connection to the secondary server is tried. The default value is primary. Valid values are:

    • primary | secondary

      The Oracle Communications Session Border Controller tries to initiate contact with primary RADIUS servers first, and then tries the secondary servers if it cannot reach any of the primary ones.

      If you configure more than one RADIUS server as primary, the Oracle Communications Session Border Controller chooses the one with which it communicates using a round-robin strategy. The same strategy applies to the selection of secondary servers if there is more than one.

  12. authentication-methods—Set the authentication method you want the Oracle Communications Session Border Controller to use with this RADIUS server. The default value is pap. Valid values are:

    • all | pap | chap | mschapv2

      This parameter has a specific relationship to the global protocol parameter for the authentication configuration, and you should exercise care when setting it. If the authentication method that you set for the RADIUS server does not match the global authentication protocol, then the RADIUS server is not used. The Oracle Communications Session Border Controller simply overlooks it and does not send authentication requests to it. You can enable use of the server by changing the global authentication protocol so that it matches.

  13. Use the management-servers attribute to identify one or more RADIUS servers available to provide AAA services.

    Servers are identified by IP address, participate in the configured management-strategy, and must have been previously configured as described above.

    The following example identifies three available RADIUS servers. The list is delimited by left and right parentheses, and list items are separated by space characters. 

    ORACLE(authentication)# management-servers (172.30.0.6 172.30.1.8 172.30.2.10)
ORACLE(authentication)#

    The following example deletes the current list. 

    ORACLE(authentication)# management-servers ()
ORACLE(authentication)#
  14. Save your work and activate your configuration.

TACACS+

TACACS+ (Terminal Access Controller Access Control System Plus) is a protocol originally developed by Cisco Systems, and made available to the user community by a draft RFC, TACACS+ Protocol, Version 1.78 (draft-grant-tacacs-02.txt). TACACS+ provides AAA (Authentication, Authorization, and Accounting) services over a secure TCP connection using Port 49.

TACACS+ Overview

Like Diameter and Remote Authentication Dial-In User Service (RADIUS), SBC uses a client-server model in which a Network Access Server (NAS) acts in the client role and a TACACS+ equipped device (a daemon in TACACS+ nomenclature) assumes the server role. For purposes of the current implementation, the SBC functions as the TACACS+ client. Unlike RADIUS, which combines authentication and authorization, TACACS+ provides three distinct applications to provide finer grade access control.

Authentication is the process that confirms a user’s purported identity. Authentication is most often based on a simple username/password association, but other, and more secure methods, are becoming more common. The following authentication methods are support by the current implementation: simple password, PAP (Protocol Authentication Protocol), and CHAP (Challenge Handshake Authentication Protocol).

Authorization is the process that confirms user privileges. TACACS+ can provide extremely precise control over access to system resources. In the current implementation, TACACS+ controls access to system administrative functions.

TACACS+ provides secure communication between the client and daemon by encrypting all packets. Encryption is based on a shared-secret, a string value known only to the client and daemon. Packets are encrypted in their entirety, save for a common TACACS+ header.

The cleartext header contains, among other fields, a version number, a sequence number. and a session ID. Using a methodology described in Section 5 of the TACACS+ draft RFC, the sender encrypts outbound cleartext messages by repetitively running the MD5 hash algorithm over the concatenation of the session ID, shared-secret, version number, and sequence number values, eventually deriving a virtual one-time-pad of the same length as the message body. The sender encrypts the cleartext message with an XOR (Exclusive OR) operation, using the cleartext message and virtual one-time-pad as inputs.

The message recipient, who possesses the shared-secret, can readily obtain the version number, sequence number, session ID, and message length from the cleartext header. Consequently, the recipient employs the same methodology to derive a virtual one-time-pad identical to that derived by the sender. The recipient decrypts the encrypted message with an XOR operation, using the encrypted message and virtual one-time-pad as inputs.

Details on the TACACS+ functions and configuration can be found in the Oracle Communications Session Border Controller ACLI Configuration Guide..

The TACACS+ implementation is based upon the following internet draft.

draft-grant-tacacs-02.txt, The TACACS+ Protocol Version 1.78

Other relevant documents include

RFC 1321, The MD-5 Message Digest Algorithm

RFC 1334, PPP Authentication Protocols .

RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)

Note:

TACACs documentation in this guide excludes per-message definitions that duplicate IETF standards documentation.

TACACS+ Authentication

The Oracle Communications Session Border Controller (SBC) uses Terminal Access Controller Access-Control System Plus (TACACS+) authentication services solely for the authentication of user accounts. Administrative users must be authenticated locally by the SBC.

The current TACACS+ implementation supports three types of user authentication: simple password (referred to as ascii by TACACS+), PAP, and CHAP.

ASCII Log In

ASCII login is analogous to logging into a standard PC. The initiating peer is prompted for a username, and, after responding, is then prompted for a password.

PAP Log In

Password Authentication Protocol (PAP) is defined in RFC 1334, PPP Authentication Protocols. PAP offers minimal security because passwords are transmitted as unprotected clear text. PAP log in differs from ASCII log in because the username and password are transmitted to the authenticating peer in a single authentication packet, as opposed to the two-step prompting process used in ASCII log in.

CHAP Log In
Challenge Handshake Authentication Protocol (CHAP) is defined in RFC 1994, PPP Challenge Handshake Authentication Protocol . CHAP is a more secure than Password Authentication Protocol (PAP) because it is based on a shared-secret (known only to the communicating peers), and therefore avoids the transmission of clear text authentication credentials. CHAP operations occur as follows.
  1. After a login attempt, the authenticator tests the initiator by responding with a packet containing a challenge value — an octet stream with a recommended length of 16 octets or more.
  2. Receiving the challenge, the initiator concatenates an 8-bit identifier (carried within the challenge packet header), the shared-secret, and the challenge value, and uses the shared-secret to compute an MD-5 hash over the concatenated string.
  3. The initiator returns the hash value to the authenticator, who performs the same hash calculation, and compares results. If the hash values match, authentication succeeds. If hash values differ, authentication fails.
Authentication Message Exchange

All TACACS+ authentication packets consist of a common header and a message body. Authentication packets are of three types: START, CONTINUE, and REPLY.

START and CONTINUE packets are always sent by the Oracle Communications Session Border Controller, the TACACS+ client. START packets initiate an authentication session, while CONTINUE packets provide authentication data requested by the TACACS+ daemon. In response to every client-originated START or CONTINUE, the daemon must respond with a REPLY packet. The REPLY packet contains either a decision (pass or fail), which terminates the authentication session, or a request for additional information needed by the authenticator.

Restricting Logon to TACACS

For deployments that include TACACS authentication, the Oracle Communications Session Border Controller (SBC) allows the user to configure a restriction that prevents users from logging into the system using mechanisms other than TACACS. The function that manages this restriction evaluates the availability of TACACS infrastructure and allows alternate login mechanisms if TACACS servers are unavailable due to either network or server issues.

Users who wish to restrict SBC login authentication to TACACS enable the authentication element's tacacs-authentication-only parameter. If there are two or more TACACS+ servers configured and the SBC either fails to establish a connection or an exiting connection fails, it tries to connect to the next available server. If there are two or more TACACS+ servers configured, then the system shall try to connect to all of them for a single login attempt and determine that they are all unavailable before falling back to using local login authentication.

Note:

The tacacs-authentication-only parameter is not functional on systems that have the Admin Security feature enabled.

The SBC uses all of the following criteria to determine that a TACACS+ server is available for login authentication:

  • The system is able to establish a TCP connection to a TACACS+ server, AND
  • TACACS+ server is responsive (e.g., no timeouts), AND
  • TACACS+ server responds with an authentication PASS or FAIL status

The SBC uses any of the following criteria to determine that a TACACS+ server is unavailable for login authentication:

  • TACACS+ server is unreachable, OR
  • TACACS+ server response is not received (e.g., timeout), OR
  • TACACS+ server responds with an authentication ERROR status

For a login attempt that reach a TACACS server but subsequently fails, the SBC rejects the login attempt with a standard login failure and records the login attempt in the Audit log.

In addition to the above and when tacacs-authentication-only is enabled, the SBC responds to authentication attempts that fail to reach a TACACS server by generating an SNMP trap and an associated alarm. The system also applies both the clear-alarm and clear-trap logic when TACACS again becomes available.

Traps and Associated Alarms

Traps supporting this feature, in ap-smgmt.mib, include indications that local authentication was used, and that the condition that caused local authentication is cleared.

Table 2-1 Trap and Clear Trap for TACACS Authentication Failure

Trap Description
apSysMgmtTacacsDownLocalAuthUsedTrap

1.3.6.1.4.1.9148.3.2.6.0.88

This trap is generated when a user remotely logs into a system configured for TACACS+ authentication and is authenticated locally by the system because all of the configured and enabled TACACS+ servers have become unreachable or unresponsive
apSysMgmtTacacsDownLocalAuthUsedClearTrap

1.3.6.1.4.1.9148.3.2.6.0.89

This trap is generated when a user remotely logs into a system configured for TACACS+ authentication and is successfully authenticated (i.e., access accepted or denied) remotely by a configured and enabled TACACS+ server.

The alarm associated with this trap is APP_ALARM_TACACS_DOWN_LOCAL_AUTH_USED (327721), shown below. 

ID      Task    Severity       First Occurred        Last Occurred
327721  69      3         2017-10-31 07:17:37  2017-10-31 07:17:37
Count   Description
1       User Bob authenticated locally due to unavailability of TACACS+ server(s)

Process System and Audit Log Entries

This feature writes entries into the ACLI process log files (e.g., log.acliSSH) to record each occurrence of a user remotely logging into the system because the TACACS+ servers are unreachable or unresponsive. 

0ct 31 13:55:56.280 [AUTH] (0) authenticate_secure_user: user ‘user’ authenticated locally due to unavailability of TACACS+ server.

This feature also writes a syslog message to record each occurrence of a user remotely logging into the system because the TACACS+ servers are unreachable or unresponsive. 

Oct 31 13:55:56 172.41.3.90 acliSSH0@SBC1: AUTH[] authenticate_secure_user: user ‘admin’ authenticated locally due to unavailability of TACACS+ server.

In addition, the system creates an audit log for every login attempt. 

2017-10-31 13:55:56,ssh-user@172.41.3.90:34362,security,login,success,authentication,,.
2017-10-31 13:55:56,ssh-user@172.41.3.90:34362,security,login,failure,authentication,,.

TACACS+ Authorization

The Oracle Communications Session Border Controller uses Terminal Access Controller Access-Control System Plus (TACACS+) services to provide administrative authorization. With TACACS+ authorization enabled, each individual ACLI command issued by an admin user is authorized by the TACACS+ authorization service. The Oracle Communications Session Border Controller replicates each ACLI command in its entirety, sends the command string to the authorization service, and suspends command execution until it receives an authorization response. If TACACS+ grants authorization, the pending command is executed; if authorization is not granted, the Oracle Communications Session Border Controller does not execute the ACLI command, and displays an appropriate error message.

The daemon’s authorization decisions are based on a database lookup. Data base records use regular expressions to associate specific command string with specific users. The construction of such records is beyond the scope of this document.

TACACS+ Authorization Command & Arguments Boundary

When sending the Authorization query to the TACACS+ server, by default the SBC sends everything typed at the ACLI in the cmd parameter. For commands, this includes the command plus all of its arguments (for example, cmd=show interfaces brief). For configurations, this includes the full path of the configuration element plus its attributes and values (for example, cmd=configure terminal security authentication type tacacs). In the TACACS+ query, the cmd-arg parameter is set to <cr>.

The parameter tacacs-authorization-arg-mode changes this default behavior. When enabled:
  1. All show commands follow the pattern: cmd=show <required-word>, cmd-arg=<optional-word1>, cmd-arg=<optional-word2>, and so on. If no optional words are used, the cmd-arg parameter is set to <cr>.

    For example:

    cmd=show uptime, cmd-arg=<cr>
cmd=show tacacs, cmd-arg=stats
cmd=show running-config, cmd-arg=authentication, cmd-arg=to-file, cmd-arg=auth.conf
  2. All other commands follow the pattern: cmd=<first-word>, cmd-arg=<second-word>, cmd-arg=<third-word>, and so on. If the command is a single-word command, the cmd-arg parameter is set to <cr>.

    For example:

    cmd=verify-config, cmd-arg=<cr>
cmd=configure, cmd-arg=terminal
cmd=ssh-key, cmd-arg=authorized-key, cmd-arg=import, cmd-arg=admin, cmd-arg=admin
  3. All configurations follow one of two patterns:
    • For navigating the ACLI: cmd=<full-path>, cmd-arg=<cr>.
    • For setting an attribute to a value: cmd=<full-path> <attribute>, cmd-arg=<value>

    For example, the following ACLI interaction produces this sequence of TACACS+ queries.

    ORACLE# conf term
ORACLE(configure)# security 
ORACLE(security)# authentication
ORACLE(authentication)# select
ORACLE(authentication)# type tacacs
    cmd=configure, cmd-arg=terminal
cmd=configure terminal security, cmd-arg=<cr>
cmd=configure terminal security authentication, cmd-arg=<cr>
cmd=configure terminal security authentication select, cmd-arg=<cr>
cmd=configure terminal security authentication type, cmd-arg=tacacs
Authorization Message Exchange

All Terminal Access Controller Access-Control System Plus (TACACS+) authorization packets consist of a common header and a message body. Authorization packets are of two types: REQUEST and RESPONSE.

The REQUEST packet, which initiates an authorization session, is always sent by the Oracle Communications Session Border Controller. Upon receipt of every REQUEST, the daemon must answer with a RESPONSE packet. In the current TACACS+ implementation, the RESPONSE packet must contain an authorization decision (pass or fail). The exchange of a single REQUEST and the corresponding RESPONSE completes the authorization session.

TACACS+ Accounting

The Oracle Communications Session Border Controller uses Terminal Access Controller Access-Control System Plus (TACACS+) accounting to log administrative actions. With accounting enabled, each individual ACLI command executed by an admin user is logged by the accounting service.

Accounting Message Exchange

All Terminal Access Controller Access-Control System Plus (TACACS+) accounting packets consist of a common header and a message body. Accounting packets are of two types: REQUEST and REPLY.

The REQUEST packet has three variant forms. The START variant initiates an accounting session; the STOP variant terminates an accounting session; the WATCHDOG variant updates the current accounting session. REQUEST packets are always sent by the Oracle Communications Session Border Controller (SBC). Upon receipt of every REQUEST, the daemon must answer with a REPLY packet.

A TACACS+ accounting session proceeds as follows.

  1. Immediately following successful authorization of an admin user, the SBC sends an accounting REQUEST START packet.
  2. The daemon responds with an accounting REPLY packet, indicating that accounting has started.
  3. For each ACLI command executed by an admin user, the SBC sends an accounting REQUEST WATCHDOG packet requesting accounting of the ACLI command. As the SBC sends the WATCHDOG only after an admin user’s access to the ACLI command is authorized, the accounting function records only those commands executed by the user, not those commands for which authorization was not granted.
  4. The daemon responds with an accounting REPLY packet, indicating that the ACLI operation has been recorded by the accounting function.
  5. Steps 3 and 4 are repeated for each authorized ACLI operation.
  6. Immediately following logout (or timeout) of an admin user, the SBC sends an accounting REQUEST STOP packet.
  7. The daemon responds with an accounting REPLY packet, indicating that accounting stopped.

TACACS+ Configuration

Configuration of Terminal Access Controller Access-Control System Plus (TACACS+) consists of the following steps.

  1. Enable TACACS+ client services
  2. Specify one or more TACACS+ servers (daemons)
Enable TACACS+ Client Services

Use the following procedure to enable specific TACACS+ client AAA services.

  1. Access the authentication configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)#
  2. type — Configure this parameter to specify the authentication protocol. The default value is local. Specify tacacs to enable the TACACS+ AAA protocol.
    • diameter — DIAMETER authentication (not yet supported)
    • local — authentication determinations are referred to a local database (default)
    • radius — RADIUS authentication
    • tacacs — TACACS+ authentication
  3. tacacs-authentication-only— Enable this parameter to require remote authentication via TACACS+ unless the TACACS+ infrastructure is not available.
    • disabled (default)
    • enabled
  4. tacacs-authorization— Configure this parameter to enable or disable command-based user authorization. The default value is enabled when the value of type is tacacs.
    • disabled
    • enabled (default)
  5. tacacs-authorization-arg-mode — Configure this parameter to enable or disable sending TACACS+ authorization commands and their arguments separately to the TACACS+ server. The default value is disabled.
    • disabled (default)
    • enabled
  6. tacacs-accounting — Configure this parameter to enable or disable accounting of admin ACLI operations. The default value is enabled when the value of type is tacacs.
    • disabled
    • enabled (default)
  7. server-assigned-privilege — Configure this parameter to enable or disable a proprietary TACACS+ variant that, after successful user authentication, adds an additional TACACS+ request/reply exchange. During the exchange, the Security Gateway requests the privilege level of the newly authenticated user. In response, the TACACS+ daemon returns the assigned privilege level, either user or admin. Set this attribute to enabled to initiate the proprietary variant behavior. User accounts are denied access to the enabled command, thus barring them from configuration level commands. The default value is disabled (no privilege level information is exchanged).
    • disabled (default)
    • enabled
  8. management-strategy — Configure this parameter to identify the selection algorithm used to choose among multiple available TACACS+ daemons. Retain the default value of hunt when only a single daemon is available.
    • hunt (default) — for the first transaction the Security Gateway selects the initially configured TACACS+ daemon. When that daemon is online and operational, the Security Gateway directs all AAA transactions to it. Otherwise, the Security Gateway selects the second-configured daemon. If the first and second daemons are offline or non-operational, the next-configured daemon is selected, and so on through the group of available daemons.
    • roundrobin — for the first transaction the Security Gateway selects the initially configured TACACS+ daemon. After completing the first transaction, it selects each daemon in order of configuration — in theory, evenly distributing AAA transactions to each daemon over time.
  9. Type done to save your configuration.
Specify TACACS+ Servers

Use the following procedure to specify one or more TACACS+ servers (daemons).

  1. Access the tacacs-serversconfiguration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)# tacacs-servers
ORACLE(tacacs-servers)#
  2. Use the address attribute to specify the IP address of this TACACS+ daemon. 
    ORACLE(tacacs-servers)# address 172.30.0.6
ORACLE(tacacs-servers)#
  3. Use the port attribute to identify the daemon port that receives TACACS+ client requests.

    Provide a port number within the range 1025 through 65535, or retain the default value, 49, the well-known TACACS+ port. 

    ORACLE(tacacs-servers)# port 49
ORACLE(tacacs-servers)#
  4. Use the state attribute to specify the availability of this TACACS+ daemon.

    Select enabled (the default) or disabled.

    Only TACACS+ daemons that are in the enabled state are considered when running the server-selection algorithm. 

    ORACLE(tacacs-servers)# state enabled
ORACLE(tacacs-servers)#
  5. Use the realm-id attribute to identify the realm that provides access to this TACACS+ deamon. 
    ORACLE(tacacs-servers)# realm-id accounting
ORACLE(tacacs-servers)#
  6. Retain the default value for the authentication-methods attribute to specify support for all TACACS+ authentication methods (pap, chap, and ascii).
    • ascii — simple login, the Oracle Communications Session Border Controller (OCSBC) prompts user for username and password
    • pap — similar to ascii method, but username and password are encapsulated in a PAP header
    • chap — authentication based on a shared-secret, which is not passed during the authentication process 
    ORACLE(tacacs-servers)# authentication-methods all
ORACLE(tacacs-servers)#
  7. Use the secret attribute to provide the shared-secret used by the TACACS+ client and the daemon to encrypt and decrypt TACACS+ messages. The identical shared-secret must be configured on associated TACACS+ clients and daemons.

    Enter a 16-digit string, and ensure that the identical value is configured on the TACACS+ daemon. 

    ORACLE(tacacs-servers)# secret 1982100754609236
ORACLE(tacacs-servers)#
  8. Use the dead-time attribute to specify, in seconds, the quarantine period imposed upon TACACS+ daemons that become unreachable. Quarrantined servers are not eligible to participate in the server-selection algorithm.

    Supported values are integers within the range 10 through 10000 seconds, with a default value of 10 . 

    ORACLE(tacacs-servers)# dead-interval 120
ORACLE(tacacs-servers)#
  9. Type done to save your configuration.
  10. Repeat Steps 1 through 10 to configure additional TACACS+ daemons.

    Note:

    After configuring TACACS+ daemons, complete TACACS+ configuration by compiling a list of available deamons.
  11. From superuser mode, use the following command sequence to access authentication configuration mode. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)#
  12. Use the management-servers attribute to identify one or more TACACS+ servers available to provide AAA services.

    Servers are identified by IP address, participate in the configured management-strategy, and must have been previously configured as described above.

    The following example identifies three available TACACS+ servers. The list is delimited by left and right parentheses, and list items are separated by space characters. 

    ORACLE(authentication)# management-servers (172.30.0.6 172.30.1.8 172.30.2.10)
ORACLE(authentication)#

    The following example deletes the current list. 

    ORACLE(authentication)# management-servers ()
ORACLE(authentication)#
Managing TACACS+ Operations

Terminal Access Controller Access-Control System Plus (TACACS+) management is supported by the following utilities.

TACACS+ MIB

An Oracle proprietary MIB provides external access to Terminal Access Controller Access-Control System Plus (TACACS+) statistics.

MIB counters are contained in the apSecurityTacacsPlusStatsTable that is defined as follows. 

SEQUENCE { 
    apSecurityTacacsPlusCliCommands                Counter32 
    apSecurityTacacsPlusSuccess Authentications    Counter32 
    apSecurityTacacsPlusFailureAuthentications     Counter32 
    apSecurityTacacsPlusSuccess Authorizations     Counter32 
    apSecurityTacacsPlusFailureAuthorizations      Counter32 
}

apSecuritysTacacsPlusStats Table (1.3.6.1.4.1.9148.3.9.9.4)

Object Name Object OID Description
apSecurityTacacsCliCommands 1.3.6.1.4.1.9148.3.9.1.4.3 Global counter for ACLI commands sent to TACACS+ Accounting
apSecurityTacacsSuccess Authentications 1.3.6.1.4.1.9148.3.9.1.4.4 Global counter for the number of successful TACACS+ authentications
apSecurityTacacsFailureAuthentications 1.3.6.1.4.1.9148.3.9.1.4.5 Global counter for the number of unsuccessful TACACS+ authentications
apSecurityTacacsSuccess Authorizations 1.3.6.1.4.1.9148.3.9.1.4.6 Global counter for the number of successful TACACS+ authorizations
apSecurityTacacsFailure
Authorizations 1.3.6.1.4.1.9148.3.9.1.4.7 Global counter for the number of unsuccessful TACACS+ authorizations
SNMP Trap

SNMP traps are issued when

  • a Terminal Access Controller Access-Control System Plus (TACACS+) daemon becomes unreachable
  • an unreachable TACACS+ daemon becomes reachable
  • an authentication error occurs
  • an authorization error occurs
TACACS+ Faults

The Oracle Communications Session Border Controller (SBC) supports (TACACS+) traps to notify you of operational status. Traps from the apSysMgmt tree include:

  • apSysMgmtTacacsDownTrap (1.3.6.1.4.1.9148.3.2.6.0.78) - Generated when a TACACS+ server becomes unreachable.
  • apSysMgmtTacacsDownClearTrap (1.3.6.1.4.1.9148.3.2.6.0.79) - Generated when a TACACS+ server that was unreachable becomes reachable.

The SBC searches for a TACACS+ server until it finds an available one and then stops searching. However, in the TACACS+ SNMP implementation, SNMP expects the SBC to make connection attempts to all servers.

  • When there is only one TACACS+ server and that server goes down, the SBC behaves normally, sending a apSysMgmtTacacsDownTrap trap when the server goes down, and a apSysMgmtTacacsDownClearTrap trap when the server comes back up.
  • When there is more than one TACACS+ server and the active server goes down, an apSysMgmtTacacsDownTrap trap is sent, indicating that some servers are down and the next server is tried.
    • If all servers fail, an apSysMgmtTacacsDownTrap is sent indicating that all servers are down.
    • If one of the servers comes back up while the rest are still down, an apSysMgmtTacacsDownTrap is sent indicating that some servers are still down.

Traps from the apSecurity tree include:

  • apSecurityTacacsFailureNotification (1.3.6.1.4.1.9148.3.9.3.1.0.4) - Generated when the system detects TACACS daemon reachability changes as well as TACACS authentication and authorization errors.
  • apSecurityTacacsDownLocalAuthUsedTrap (1.3.6.1.4.1.9148.3.9.3.9.0.1) - Generated when a user remotely logs into a system configured for TACACS+ authentication and is authenticated locally by the system because all of the configured and enabled TACACS+ servers have become unreachable or unresponsive
  • apSecurityTacacsDownLocalAuthUsedClearTrap (1.3.6.1.4.1.9148.3.9.3.9.0.2) - Generated when a user remotely logs into a system configured for TACACS+ authentication and is successfully authenticated (i.e., access accepted or denied) remotely by a configured and enabled TACACS+ server.
ACLI show Command

The show tacacs stats command displays the following statistics.

  • number of ACLI commands sent for TACACS+ accounting
  • number of successful TACACS+ authentications
  • number of failed TACACS+ authentications
  • number of successful TACACS+ authorizations
  • number of failed TACACS+ authentications
  • the IP address of the TACACS+ daemon used for the last transaction
TACACS+ Logging

All messages between the Oracle Communications Session Border Controller and the Terminal Access Controller Access-Control System Plus (TACACS+) daemon are logged in a clear text format, allowing an admin user to view all data exchange, except for password information.

TACACS+ over IKEv2/IPsec

You can configure the SBC to connect to a TACACS server over an IKEv2/IPsec secured connection. This communication must occur over the management interface wancom0. The ikev2-ipsec-wancom0-params element enables this configuration.

Before configuring the ikev2-ipsec-wancom0-params element, make sure you have an IPsec license installed. Then create the default ike-config element.
ORACLE# configure terminal 
ORACLE(configure)# security 
ORACLE(security)# ike
ORACLE(ike)# ike-config 
ORACLE(ike-config)# select
ORACLE(ike-config)# done
This procedure ensures that IKEv2 is set globally on the SBC.

When booting up, the SBC reads the ikev2-ipsec-wancom0-params configuration element. If this element does not exist, no action is taken. If the element exists and auto is set to ondemand, an IKEv2/IPsec connection is set up between the SBC and the peer specified in the remoteip attribute. The SBC can also act as a responder.

The SBC can authenticate to its IKEv2 peer with an X.509 certificate or a pre-shared key (PSK). To use a PSK:
  1. Set the authby attribute to secret.
  2. Set the shared-password attribute to your PSK.
To use an X.509 certificate:
  1. Review the TLS chapter in the Configuration Guide.
  2. Create a certificate-record for the SBC.
  3. Under security, ike, configure an ike-certificate-profile for the SBC.

    Note:

    The identity attribute should match the Subject Alternative Name of the SBC's end-entity certificate.
  4. Under security, ikev2-ipsec-wancom0-params, set local-certificate-profile-identity to the identity attribute of your previously configured ike-certificate-profile for the local peer.
  5. Set authby to rsasig.
  6. Set remote-certificate-identity to the identity (email address, IP address, FQDN, DNS, or URI) of the remote peer.

    Note:

    The value should match the Subject Alternative Name of the remote peer's certificate.
Use the following commands to monitor the IKEv2/IPsec connections to the SBC's wancom0 port:
show security ipsec wancom0 <sad | spd | tunnels>
show security ike wancom0 <error-stats | sad>
Secure wancom0 with IKEv2/IPsec

You can secure TACACS or RADIUS authentication to the management wancom0 interface by tunneling your authentication protocol over IKEv2/IPsec.

  1. Navigate to the ikev2-ipsec-wancom0-params element.
    ORACLE# conf term 
ORACLE(configure)# security 
ORACLE(security)# ikev2-ipsec-wancom0-params 
ORACLE(ikev2-ipsec-wancom0-params)#
  2. name—Provide a name for this configuration element.
    For example:
    ORACLE(ikev2-ipsec-wancom0-params)# name SecureTacacs
  3. remoteip—Enter the IPv4 or IPv6 address of the remote peer.
  4. remotesubnet—Enter the IPv4 or IPv6 subnet of the remote peer.
    Omit the number of bits for an exact match. For example, 10.1.1.1 is the same thing as 10.1.1.1/32.
  5. remoteproto—Keep the default value of ALL or select the remote peer's transport protocol that will be protected within the IPsec tunnel.
    If running TACACS+ over IKEv2/IPsec, you can select TCP because TACACS+ uses TCP as its transport protocol.
  6. remoteport—Keep the default 0 to match any port or select the port which the remote peer will use to communicate within the IPsec tunnel.
    The default TACACS+ port is 49.
  7. localip—Confirm the IP address is the SBC's wancom0 IP address.
  8. localsubnet—Enter the subnet of the local peer.
    This value defaults to a /32 for IPv4 or a /128 for IPv6.
  9. localproto—Keep the default value of ALL or select the transport protocol of the local peer.
    This is the transport protocol you're going to protect within the tunnel. If running TACACS+ over IKEv2/IPsec, select TCP because TACACS+ uses TCP as its transport protocol. This should be the same value as remoteproto.
  10. localport—Keep the default 0 or select the port that the local peer will communicate on.
    Enter 0 to use ephemeral ports when the SBC acts as a TACACS+ client.
  11. auto—Keep the default ondemand to establish IKEv2/IPsec tunnels on demand.
  12. Confirm that the remote peer accepts the default algorithms specified in the ike-algorithms, ipsec-protocol, and ipsec-algorithms attributes.
  13. authby—Specify how the two peers should authenticate to each other.
    Use rsasig for X.509 certificates and use secret for a PSK.
  14. shared-password—If you set authby to secret, enter a passphrase.
  15. local-certificate-profile-identity—If you set authby to rsasig, specify the identity attribute of your previously configured ike-certificate-profile element for the local peer.
  16. remote-certificate-identity—If you set authby to rsasig, specify the email address, IP address, FQDN, DNS, or URI of the remote peer.

    Note:

    This value should match the Subject Alternate Name of the peer's certificate.