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.
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
local-accounts add <username> <class><class> are user and
admin.
- Create an account.
To create an account for a user named Jamie:
ORACLE# local-accounts add jamie userTo create an account for an administrator named Jamie:ORACLE# local-accounts add jamie adminNote:
Usernames are case sensitive. - Enter and confirm the password for the new account.
- Save and activate the configuration.
Modify the Password of a Local Account
Administrators may change their own password.
local-accounts change-password <username>- Log in to your local administrator account.
- Use the
local-accountscommand to change your password.local-accounts change-password jamie - Enter your current password.
- Enter and confirm your new password.
The SBC saves and activates the configuration after a password change.
Delete a Local Account
local-accounts delete <username>- Log in as an administrator.
- Delete the
account.
ORACLE# local-accounts delete jamie - Confirm you want to delete the account.
- Save and activate the configuration.
- Delete any saved authorized keys for that
user.
ORACLE# ssh-key authorized-key delete jamie - Use the
show userscommand 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 - 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:
Thelocal-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.
- Log in as an administrator.
- Run the
factory-accountscommand.ORACLE# factory-accounts disable - 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.
- Run the
factory-accountscommand.ORACLE# factory-accounts enable - 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
adminoruser, and must be lowercase.
- 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.
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:118751232CHAP 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:118751232MS-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:118751232MS-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:00000006Management 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.
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:
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
- 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.
- 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.
- 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
Each TACACS+ authorization entry on an ACLI command line comprises the command and its arguments. Currently everything typed as a TACACS+ authorization command by an authenticated admin user, including the arguments, is sent to the TACACS+ server in the command field of the TACACS+ message; the argument field in the TACACS+ message contains no arguments and is set to “cmd-arg=<CR>”. This feature adds the new parameter tacacs-authorization-arg-mode to the authentication configuration element, which enables the TACACS+ authorization command and its arguments to be sent to the TACACS+ server separately.
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.
- Immediately following successful authorization of an admin user, the SBC sends an accounting REQUEST START packet.
- The daemon responds with an accounting REPLY packet, indicating that accounting has started.
- 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.
- The daemon responds with an accounting REPLY packet, indicating that the ACLI operation has been recorded by the accounting function.
- Steps 3 and 4 are repeated for each authorized ACLI operation.
- Immediately following logout (or timeout) of an admin user, the SBC sends an accounting REQUEST STOP packet.
- 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.
- Enable TACACS+ client services
- Specify one or more TACACS+ servers (daemons)
Enable TACACS+ Client Services
Use the following procedure to enable specific TACACS+ client AAA services.
Specify TACACS+ Servers
Use the following procedure to specify one or more TACACS+ servers (daemons).
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 two Terminal Access Controller Access-Control System Plus (TACACS+) traps, apSysMgmtTacacsDownTrap and apSysMgmtTacacsDownClearTrap.
The apSysMgmtTacacsDownTrap is generated when a TACACS+ server becomes unreachable.
The apSysMgmtTacacsDownClearTrap is 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.
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