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 enabled, the following security policies and restrictions are implemented:

  • history log access is denied
  • strict password policies are enabled

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

  • strict password policies are disabled
  • default password policies are enabled

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 you create a local account, you must specify the username and user class, and you can optionally specify the authentication type. The username must be unique and must meet these requirements:

  • For accounts that use the passwd authentication type, usernames must:
    • Start with a lowercase letter or an underscore.
    • Use only lowercase letters, digits, underscores, and hyphens after the first character.
    • Contain no more than 31 characters.
  • Accounts that use the MFFE authentication type are not subject to standard username restrictions because the username must match the CN-derived username from the client certificate. Enclose MFFE usernames containing spaces or special characters in double quotation marks ("<username>") when using the local-accounts command.

You cannot use user or admin as a username.

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.

There are two options for authentication type: passwd and MFFE. The MFFE type applies to accounts that are authenticated with client certificates. These accounts do not require a password. The passwd type is the default, and applies to all other accounts.

After you create a second administrator account, you can disable the factory user and admin accounts. The SBC requires at least one administrator account. Only administrators can delete accounts, and administrators cannot delete their own accounts. Use the factory-accounts command 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'

Delete Local Accounts with Invalid Usernames

If an existing local account username does not meet the username requirements, the CLI rejects the delete command because the username is invalid. To delete the account, correct the username in a backup configuration, restore the updated configuration, and then delete the account by using the updated username.

Note:

This procedure applies only to legacy or non-MFFE accounts whose usernames do not meet the standard passwd username rules. You can delete MFFE accounts (with CN-derived usernames) as normal, by using local-accounts delete "<username>".
  1. Back up the current SBC configuration.
  2. Extract the configuration XML from the backup.
  3. In <localAccounts>, change both the UserName value and the matching <key> value to a username that meets the requirements. For example, change JohnSmith to johnsmith.
  4. Restore the modified configuration.
  5. Run the delete command with the updated username.
local-accounts delete johnsmith

Local Accounts and TACACS+

When the tacacs-authentication-only attribute is enabled in the security configuration element or when the Admin Security entitlement 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 Certificate-based Authentication

When the SBC is configured for certificate-based authentication, local accounts with the MFFE authentication type can authenticate using client certificates. A password is not used for these accounts.

After two-factor authentication and OCSP certificate authentication completes successfully, the common name (CN) extracted from the client certificate is matched to a local account username. If the matching account has the MFFE authentication type, the user can successfully authenticate using the certificate. If the matching account does not have the MFFE authentication type, authentication fails.

See Certificate-based Authentication in the Authentication and Authorization topic of the Admin Security Guide for more information about how certificate-based authentication works.