Authentication and Authorization
Authentication is the process of confirming the alleged identity of a service requester. Authorization, a process performed after authentication, determines the access or privilege level granted to an authenticated requester.
Local Authentication and Authorization
This section describes user authentication and authorization performed locally by a Oracle SBC that has either the Admin Security or JITC feature set provisioned.
The SBC provides two default factory accounts:
- user
- admin
Each of the two factory accounts is associated with an eponymous authorization class which defines the access level for all local accounts within that class.
- provides read-only access to non-security configurations
- provides read access to visible files
- login to user mode
- cannot switch to admin mode
- provides read-write access to all configuration
- provides read/write access to a sub-set of file system elements
- login to admin mode
- cannot switch to user mode
When local accounts are created, you specify the authorization class using the syntax:
local-accounts add <username> [ user | admin ]
Console Login
The following table summarizes the authorization classes for local accounts.
User Name | Login prompt | Authorization class |
---|---|---|
user | user mode
> |
user |
admin | admin mode
# |
admin |
Serial Port Control
With the addition of the Admin Security feature, you may enable or disable access to the serial (console) port. In the absence of this feature, access to the serial is generally available. The ACLI command console-io functions as a switch that you set to enabled to allow serial port access and to disabled to keep the serial port from being used.
If you remove the administrative management feature after disabling the serial port, the SBC reverts to its default behavior by providing serial port access.
To turn off access to the serial port:
Initial Login
Upon initial login, user and admin are required to change the respective password. Initial login is completed only after password change and acknowledgment of the login banner.
Note:
With each release, the default ciphers of the SBC may be upgraded to their latest secure versions. If a verbose connection log of an SSH or SFTP client shows that it cannot agree on a cipher with the OCSBC, upgrade your client.The following figure shows the initial login screen for the default admin account.
To complete initial login:
Remote SSH Login with Password
The following shows logging in as the factory default admin account.
[bob@linuxbox ~]$ ssh admin@10.1.1.2
Password:
--------------------------------------------------------------------------------
Last login : 2020-11-09 14:10:03
System last accessed by "admin", 2020-11-09 14:10:03
WARNING: Unsuccessful login attempts were made for 'admin' on
2020-09-14 15:14:08
2020-11-03 16:53:57
2020-11-06 14:15:53
2020-11-06 14:16:09
2020-11-06 14:16:21
--------------------------------------------------------------------------------
Confirm reading the above message [y/n]?: y
ADMINSEC#
Remote SSH Login with Public Key
As an alternative to password-based authentication, you can authenticate using SSH public keys. To set up public-key authentication, import a copy of the public key of each user who will authenticate using this method. The public key identifies the user as a trusted entity when the Oracle SBC performs authentication.
During the SSH login, the user presents its public key to the SBC, which validates the offered public key against the previously obtained trusted copy of the key to identify and authenticate the user.
Two-Factor Authentication
Two-factor authentication (2FA) adds an extra layer of security when authenticating to the SBC by requiring a key, such as an SSH public key or X.509 certificate, as well as a username and password. 2FA can be enabled on either the web interface, the SSH interface, or both.
Pre-Requisites
The Admin Security entitlement must be installed.
Two-factor Authentication for the Web GUI
- The client certificate key length is at least 1024 bytes (2048 bytes if the FIPS entitlement is also installed).
- The client certificate was signed by a previously installed root CA certificate.
- The client certificate is not revoked.
- The Common Name in the certificate is found in the list
configured in the common-name-list attribute.
Note:
2FA will fail if the Common Name associated with the client certificate that the web browser sends to the SBC is not found in the common-name-list attribute.
To use 2FA on the web interface, the client browser must be configured to send the appropriate certificate to the SBC. Check your browser's documentation for how to add a client certificate to your browser's certificate manager.
Two-factor Authentication for the SSH Interface
2FA on the SSH interface can use either local authentication (to login as the local admin account or the local user account) or RADIUS/TACACS+ authentication. In either case, at least one of the following is required:
- Import the authorized-key of an SSH client; or
- Import the ca-key that will sign the public keys of SSH clients.
ssh-key authorized-key import admin admin
Alternatively,
if the type attribute in the
authentication element is set to
tacacs or radius, you can import
the public key of a RADIUS or TACACS+ user who will administer the SBC.ssh-key authorized-key import alice admin
Note:
For instructions on signing certificates, see "Add a Certificate Authority Key" in the ACLI Configuration Guide.After certificates are configured, set the two-factor-auth-access-method-list to SSH. When enabled, the SBC requires a user to authenticate with both a pubic key and a password.
2FA Lockout
To prevent getting locked out of an SBC with 2FA enabled, never delete the last authorized-key or the last ca-key.
Caution:
Removing the last authorized-key or the last ca-key will make it impossible to SSH to the management port if 2FA is enabled on the SSH interface.RADIUS Authentication and Authorization
As an alternative to local authentication, users may use a RADIUS server to authenticate.
For information on configuring between RADIUS servers and the SBC refer to RADIUS Authentication section in the ACLI Configuration Guide.
A RADIUS users file (shown below), stored on the RADIUS server, provides the basis for server authentication and authorization decisions.
user1 Cleartext-Password := "user1"
Acme-User-Class = user,
Acme-User-Privilege = sftpForAll
user2 Cleartext-Password := "user2"
Acme-User-Class = user,
Acme-User-Privilege = sftpForAll
admin1 Cleartext-Password := "admin1"
Acme-User-Class = admin,
Acme-User-Privilege = sftpForAll
admin2 Cleartext-Password := "admin2"
Acme-User-Class = admin,
Acme-User-Privilege = sftpForAll
Upon receiving a login request, the SBC sends a RADIUS Access Request message to the RADIUS server. The request message contains, among other things, the username:password requesting access to SBC resources. Upon receiving the request, the RADIUS server checks its user file for the username:password pair. If its finds a congruent match, the requestor is authenticated.
Successful authentication generates a Access Accept message to the SBC; the message also contains the contents of two Oracle Vendor Specific Attributes (VSAs). Acme-User-Class specifies the configuration privileges accorded the authenticated user. Acme-User-Privilege specifies the log file access accorded to the authenticated user. Together these two VSAs provide the authorization function. Consequently, the RADIUS server functions as an authentication and authorization decision point, while the SBC functions as an enforcement point.
RADIUS Authorization Classes
The RADIUS authorization classes, as specified by the Acme-User-Class VSA, coincides with the two default admin and user authorization classes.
Note:
The value of Acme-User-Class must be lowercase.user
- provides read-only for all system configuration
- The login prompt for this user is ORACLE>
Acme-User-Class = user
admin
- provides read-write access for all system configuration
- The login prompt for this user is ORACLE#
Acme-User-Class = admin
RADIUS and SSH
When the SBC uses a RADIUS server for authentication, you cannot log in over SSH using the two factory defined accounts (user and admin). Attempts to login via SSH are rejected.
[user@host ~]$ ssh user@10.1.1.2
Password:
% Error: Cannot login as local user when AAA Server is enabled
Use console to login as local user
RADIUS and Password Policies
With RADIUS enabled, passwords are stored and controlled on the remote RADIUS server or servers. Consequently, none of the length/strength, re-use, history, or expiration requirements mandated by the local password policy are applicable to RADIUS passwords. Most RADIUS servers, however, do enforce password policies of their own.
TACACS+ Support
Note:
For SFTP, only TACACS+ users with admin privileges have permission to login.When TACACS+ is configured and a Public Key Infrastructure (PKI) user logs into the SBC, the SBC performs the authentication locally against the locally stored public RSA key, but performs authorization and accounting with TACACS+. This means that, instead of adhering to the permissions configured when importing the public key, the SBC queries the TACACS+ server and generates start/stop accounting records using TACACS+ settings.
TACACS+ over IPSec
To run TACACS+ over IPsec on an SBC with the Admin Security entitlement set, you must complete the following steps:
- Configure a phy-interface for wancom0.
For example:
ADMINSEC# conf term ADMINSEC(configure)# system phy-interface ADMINSEC(phy-interface)# name wancom0 ADMINSEC(phy-interface)# operation-type Control ADMINSEC(phy-interface)# done
- Configure a network-interface for wancom0.
For example:
ADMINSEC# conf term ADMINSEC(configure)# system network-interface ADMINSEC(network-interface)# name wancom0 ADMINSEC(network-interface)# ip-address 10.1.1.5 ADMINSEC(network-interface)# netmask 255.255.255.0 ADMINSEC(network-interface)# gateway 10.1.1.1 ADMINSEC(network-interface)# done
- Configure a security-policy for wancom0.
For example:
ADMINSEC# conf term ADMINSEC(configure)# security ipsec security-policy ADMINSEC(security-policy)# name secureTacacs ADMINSEC(security-policy)# network-interface wancom0:0 ADMINSEC(security-policy)# remote-ip-addr-match 10.1.1.42 ADMINSEC(security-policy)# remote-ip-mask 255.255.255.0 ADMINSEC(security-policy)# done
- Configure the ikev2-ipsec-wancom0-params
configuration element.
For example:
ADMINSEC# conf term ADMINSEC(configure)# security ikev2-ipsec-wancom0-params ADMINSEC(ikev2-ipsec-wancom0-params)# name TacPlusIPsec ADMINSEC(ikev2-ipsec-wancom0-params)# remoteip 10.1.1.42 ADMINSEC(ikev2-ipsec-wancom0-params)# remotesubnet 10.1.1.42/32 ADMINSEC(ikev2-ipsec-wancom0-params)# localip 10.1.1.5 ADMINSEC(ikev2-ipsec-wancom0-params)# localsubnet 10.1.1.5/32 ADMINSEC(ikev2-ipsec-wancom0-params)# authby secret ADMINSEC(ikev2-ipsec-wancom0-params)# shared-password Enter password: Retype password: Password updated ADMINSEC(ikev2-ipsec-wancom0-params)# done
- Save and activate your configuration.
WARNING: Admin-security enabled. 10.1.1.42 tacacs server does not match any of the configured security-policy's remote-ip-addr-match/remote-ip-mask subnet. So communication from SBC to this server over media ports will not be secured by IPsec.
System Access Based on Server Availability
When delegated authentication methods like RADIUS and TACACS+ are used with the Admin Security entitlement, the SBC behaves differently depending on whether it can access the authentication server.
When the RADIUS or TACACS+ server is available, password-based SSH authentication using the factory account or a local account is blocked. When the RADIUS or TACACS+ server is unavailable, password-based SSH authentication using either the factory account or a local account is allowed.
Server is accessible | Server is not accessible | |
---|---|---|
Factory accounts | No SSH or SFTP access | SSH and SFTP access |
Local accounts | No SSH or SFTP access | SSH and SFTP access |
Console access is always permitted using either the factory accounts or a local account.
To understand how key-based SSH authentication interacts with other accounts (local accounts, RADIUS, TACACS+), see the User Accounts section in the Configuration Guide.