1. Admin Security Guide
  2. Access
  3. Administrative Security Feature Set

Administrative Security Feature Set

This section describes implications of adding and removing the Admin Security feature set on an Oracle Communications Session Border Controller (SBC).

This feature enables various security enhancements described in this document. In the absence of an Admin Security feature set, these enhancements are not available.

Note:

The Admin Security feature set is not intended for all customer use. Consult your Oracle representative to understand the ramifications of enabling these features.
If the Admin Security feature is removed, protected areas of the system remain unavailable. This ensures that a system cannot be compromised by removing features. Once the Admin Security feature is provisioned, it cannot be removed, and the SBC may retain sensitive information. To remove all sensitive data, you must perform a complete factory reset (zeroization). On supported Acme Packet platforms, zeroization is done using the Oracle Rescue Account. To perform zeroization on a virtual SBC, you must perform a complete image reinstallation. For more information on the performing a factory reset, see "Factory Reset for the Oracle Communications Session Border Controller" in this guide.

Note:

The Government Security Certification SKU is equivalent to the Admin Security feature.
When enabling the Admin Security via the setup entitlements command, the SBC warns the user with the following message: 
********************************************************************************
CAUTION: Enabling this feature activates enhanced security functions.
Once saved, security cannot be reverted without resetting the system
back to factory default state.
********************************************************************************
Note: The 'factory default' process via the 'oracle rescue account' menu can be used for support to guide the
removal of these features in the field by resetting the system back to the as-shipped state.

When the Admin Security feature set is present and enabled, the following security policies and restrictions are implemented:

  • shell access is denied
  • history log access is denied
  • password policy features are enabled in addition to some additional Admin Security specific password requirements

When the Admin Security feature set is disabled and deleted, the following security policies and restrictions are implemented:

  • shell access is denied
  • SSH keys are denied
  • password policy features are disabled

Enabling the Admin Security Feature

Provision the Admin Security feature by enabling Admin Security via the setup entitlements command. For more information on installing the Admin Security feature set, see the Oracle Enterprise Session Border Controller Release Notes. For instructions on provisioning this feature set, see the Oracle Enterprise Session Border Controller ACLI Configuration Guide.

Supported Platforms

The following platforms support Admin Security:
  • Acme Packet 1100
  • Acme Packet 3900
  • Acme Packet 3950
  • Acme Packet 4600
  • Acme Packet 4900
  • Acme Packet 6300
  • Acme Packet 6350
  • VMWare
  • KVM

JITC Support

The SBC supports Joint Interoperability Testing Command (JITC). To enable JITC, use the setup entitlements command to enable both the Admin Security entitlement and the FIPS entitlement.

Note:

The JITC feature set is supported only on Enterprise releases.

For more information on installing the Admin Security feature set, see the Oracle Enterprise Session Border Controller Release Notes. For instructions on provisioning this feature set, see the Oracle Enterprise Session Border Controller Configuration Guide.

Note:

JITC features supersede Admin Security features.

Supported Platforms

The following platforms support JITC mode:

  • Acme Packet 1100
  • Acme Packet 3900
  • Acme Packet 3950
  • Acme Packet 4600
  • Acme Packet 4900
  • Acme Packet 6300
  • VME

Login Banner

Upon successful user authentication and authorization, the Oracle SBC displays the login banner.

  • Last login: displays the date and time that the current user last successfully logged-in
  • System last accessed: displays the date and time and user name of the last user who successfully logged-in
  • Unsuccessful login attempts: displays the date and time of the last five unsuccessful login attempts by the current user
  • Confirm reading: requires user acknowledgement of the display banner.

    A positive response (y) successfully completes login, and starts audit-log activity for this user session. A negative response (n) generates an audit-log entry and logs the user out of the SBC.

The login banner also provides notification of impending password or SSH public key expiration as described in Password Policy Configuration.

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.