NTP can use network peers, local external clocks (such as GPS devices), or a local clock with no external source.

A local clock with no external source is usually a last-resort clock when no better clock is available. It is typically configured on a site's intermediate NTP server so that when a WAN network outage occurs, hosts within the site can continue to synchronize amongst themselves.

You can configure this in ntpd or on many commercially available NTP devices. This local clock should always have a high stratum number (8+) so that under normal conditions (when real sources are available) this local clock will not be used.

The NTP daemon and protocol assume that each configured server is running NTP. If a NTP client is configured to synchronize to a load balancer that relays and distributes packets to a set of real NTP servers, the load balancer may distribute those packets dynamically and confuse the NTP client. NTP packets are latency and jitter sensitive. Relaying them through a load balancer can confuse the NTP client and is not a supported practice.

Verify the NTP configuration is correct. Enter the following command at the Exec mode prompt:

show ntp associations

The output displays information about all NTP servers. See the output below for an example deploying two NTP servers.

+----Peer Selection: ( ) - Rejected / No Response 
|                    (x) - False Tick
|                    (.) - Excess
|                    (-) - Outlyer
|                    (+) - Candidate
|                    (#) - Selected
|                    (*) - System Peer
|                    (o) - PPS Peer
v
     remote            refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.81.254.202   .GPS.            1 u  160 1024  377   21.516    0.019   0.009

The following table describes the parameters output by the show ntp associations command.

User names can only contain alphanumeric characters (a-z, A-Z, 0-9), hyphen, underscore, and period. The hyphen character cannot be the first character. This applies to AAA user names as well as local user names.

If you attempt to create a user name that does not adhere to these standards, you will receive the following message: "Invalid character; legal characters are "0123456789.-_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

The local user type supports ANSI T1.276-2003 password security protection. Local-user account information, such as passwords, password history, and lockout states, is maintained in /flash. This information is saved immediately in a separate local user database subject to AAA based authentication and is not used by the rest of the system. As such, configured local-user accounts are not visible with the rest of the system configuration.

Use the example below to configure local-user administrative users:

configure
   local-user username name
   end

For additional information on the local-user database, see Updating and Downgrading the local-user Database.

By default an admin user who has FTP/SFTP access can access and modify any files under the /mnt/user/ directory. Access is granted on an "all-or-nothing" basis to the following directories: /flash, /cdrom, /hd-raid, /records, /usb1 and /usb2.

An administrator or configuration administrator can create a list of SFTP subsystems with a file directory and access privilege. When a local user is created, the administrator assigns an SFTP subsystem. If the user's authorization level is not security admin or admin, the user can only access the subsystem with read-only privilege. This directory is used as the user's root directory. The information is set as environmental variables passed to the openssh sftp-server.

You must create the SFTP root directory before associating it with local users, administrators and config administrators. You can create multiple SFTP directories; each directory can be assigned to one or more users.

TACACS+ is a secure, encrypted protocol. By remotely accessing TACACS+ servers that are provisioned with the administrative user account database, the UGP system can provide TACACS+ AAA services for system administrative users. TACACS+ is an enhanced version of the TACACS protocol that uses TCP instead of UDP.

The system serves as the TACACS+ Network Access Server (NAS). As the NAS the system requests TACACS+ AAA services on behalf of authorized system administrative users. For the authentication to succeed, the TACACS+ server must be in the same local context and network accessed by the system.

The system supports TACACS+ multiple-connection mode. In multiple-connection mode, a separate and private TCP connection to the TACACS+ server is opened and maintained for each session. When the TACACS+ session ends, the connection to the server is terminated.

TACACS+ is a system-wide function on the UGP. TACACS+ AAA service configuration is performed in TACACS Configuration Mode. Enabling the TACACS+ function is performed in the Global Configuration Mode. The system supports the configuration of up to three TACACS+ servers.

Once configured and enabled on the system, TACACS+ authentication is attempted first. By default, if TACACS+ authentication fails, the system then attempts to authenticate the user using non-TACACS+ AAA services, such as RADIUS.

It is possible to configure the maximum number of simulations CLI sessions on a per account or per authentication method basis. It will protect certain accounts that may have the ability to impact security configurations and attributes or could adversely affect the services, stability and performance of the system. The maximum number of simultaneous CLI sessions is configurable when attempting a new TACACS+ user login. The recommendation is to use the max-sessions feature is through the TACACS+ server attribute option maxsess. The second way is though the StarOS CLI configuration mode TACACS+ mode using the maxsess keyword in the user-id command. If the maximum number of sessions is set to 0, then the user is authenticated regardless of the login type. When the CLI task starts, a check is complete to identify the count. In this case, the CLI determines that the sessions for that user is 1 which is greater than 0 and it will display an error message in the output, it generate starCLIActiveCount and starCLIMaxCount SNMP MIB Objects and starGlobalCLISessionsLimit and starUserCLISessionsLimit SNMP MIB Alarms.

The max-sessions TACACS+ Configuration Mode command configures the maximum number of sessions available for TACACS+. Also the default option for the user-id TACACS+ Configuration Mode command configures the default attributes for a specific TACACS+ user identifier. Refer to the Command Line Interface Reference for detailed information about these commands.

Before configuring TACACS+ AAA services, note the following TACACS+ server and StarOS user account provisioning requirements.

This section provides an example of how to configure TACACS+ AAA services for administrative users on the system.

Caution

When configuring TACACS+ AAA services for the first time, the administrative user must use non-TACACS+ services to log into the StarOS. Failure to do so will result in the TACACS+ user being denied access to the system.

Log in to the system using non-TACACS+ services.

Use the example below to configure TACACS+ AAA services on the system:

configure
   tacacs mode
      server priority priority_number ip-address tacacs+srvr_ip_address
      end

Enable TACACS+ on the StarOS:

configure
   aaa tacacs+
   end

For additional information, see Disable TACACS+ Authentication for Console.

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

By default TACACS+ authentication is associated with login to the local context. TACACS+ authentication can also be configured for non-local context VPN logins. TACACS+ must configured and enabled with the option described below.

A stop keyword option is available for the TACACS+ Configuration mode on-unknown-user command. If TACACS+ is enabled with the command-keyword option, the VPN context name into which the user is attempting a login must match the VPN name specified in the username string. If the context name does not match, the login fails and exits out.

Without this option the login sequence will attempt to authenticate in another context via an alternative login method. For example, without the on-unknown-user stop configuration, an admin account could log into the local context via the non-local VPN context. However, with the on-unknown-user stop configuration, the local context login would not be attempted and the admin account login authentication would fail.

configure
   tacacs mode
      on-unkown-user stop ?
      end

This section describes how to verify the TACACS+ configuration.

Log out of the system CLI, then log back in using TACACS+ services.

show tacacs [ client | priv-lvl | session | summary ]

The output of the show tacacs commands provides summary information for each active TACACS+ session such as username, login time, login status, current session state and privilege level. Optional filter keywords provide additional information.

An example of this command's output is provided below. In this example, a system administrative user named asradmin has successfully logged in to the system via TACACS+ AAA services.

active session #1:
   login username               : asradmin 
   login tty                    : /dev/pts/1 
   time of login                : Fri Oct 22 13:19:11 2011 
   login server priority        : 1
   current login status         : pass
   current session state        : user login complete 
   current privilege level      : 15
   remote client application    : ssh
   remote client ip address     : 111.11.11.11 
   last server reply status     : -1
total TACACS+ sessions          : 1 

A noconsole keyword for the Global Configuration mode aaa tacacs+ command disables TACACS+ authentication on the Console line.

configure
  aaa tacacs+ noconsole
  exit

By default, TACACS+ server authentication is performed for login from a Console or vty line. With noconsole enabled, TACACS+ authentication is bypassed in favor of local database authentication for a console line; on vty lines, TACACS+ remains enabled.

A noconsole keyword for the Global Configuration mode local-user allow-aaa-authentication command disables AAA-based authentication on the Console line.

configure
  local-user allow-aaa-authentication noconsole
  exit

Since local-user authentication is always performed before AAA-based authentication and local-user allow-aaa-authentication noconsole is enabled, the behavior is the same as if no local-user allow-aaa-authentication is configured. There is no impact on vty lines.

When you enable aaa tacacs+ in the Global Configuration mode, TACACS+ authentication is automatically applied to all contexts (local and non-local). In some network deployments you may wish to disable TACACS+ services for a specific context(s).

You can use the no aaa tacacs+ Context Configuration command to disable TACACS+ services within a context.

configure
  context ctx_name
    no aaa tacacs+

Use the aaa tacacs+ Context Configuration command to enable TACACS+ services within a context where it has been previously disabled.

As a security administrator when you create a StarOS user you can specify whether that user can login through the Console or vty line. The [ noconsole | novty ] keywords for the Global Configuration mode local-user username command support these options.

configure
  local-user username <username> [ noconsole | novty ]
  exit

The noconsole keyword prevents the user from logging into the Console port. The novty keyword prevents the user from logging in via an SSH or telnet session. If neither keyword is specified access to both Console and vty lines is allowed.

AAA-based users normally login through on a vty line. However, you may want to limit a few users to accessing just the Console line. If you do not use the local-user database (or you are running a Trusted build), this needs to be done by limiting access to the Console line for other AAA-based users. Enable the noconsole keyword for all levels of admin users that will not have access to the Console line.

The noconsole keyword is available for the Context Configuration mode commands shown below.

configure
  context <ctx_name>
    administrator <username> { encrypted | nopassword | password } noconsole
    config-administrator <username> { encrypted | nopassword | password } noconsole
    inspector <username> { encrypted | nopassword | password } noconsole
    operator <username> { encrypted | nopassword | password } noconsole
    exit

The noconsole keyword disables user access to the Console line. By default noconsole is not enabled, thus all AAA-based users can access the Console line.

You can verify changes made related to the separation of authentication methods via the Exec mode show configuration command. After saving the configuration changes, run show configuration |grep noconsole and show configuration |grep novty. The output of these commands will indicate any changes you have made.

The chassis key is used to encrypt and decrypt encrypted passwords in the configuration file. If two or more chassis are configured with the same chassis key value, the encrypted passwords can be decrypted by any of the chassis sharing the same chassis key value. As a corollary to this, a given chassis key value will not be able to decrypt passwords that were encrypted with a different chassis key value.

The chassis key is used to generate the chassis ID which is stored in a file and used as the master key for protecting sensitive data (such as passwords and secrets) in configuration files

For release 15.0 and higher, the chassis ID is an SHA256 hash of the chassis key. The chassis key can be set by users through a CLI command or via the Quick Setup Wizard. If the chassis ID does not exist, a local MAC address is used to generate the chassis ID.

For release 19.2 and higher, the user must explicitly set the chassis key through the Quick Setup Wizard or CLI command. If it is not set, a default chassis ID using the local MAC address will not be generated. In the absence of a chassis key (and hence the chassis ID), sensitive data will not appear in a saved configuration file. The chassis ID is the SHA256 hash (encoded in base36 format) of the user entered chassis key plus a 32-byte secure random number. This assures that the chassis key and chassis ID have 32-byte entropy for key security.

If a chassis ID is not available encryption and decryption for sensitive data in configuration files will not work.

By default if an excessive number of discarded fabric egress packets occurred in the switch fabric, a manual reset of the Fabric Storage Card(s) is required for fabric recovery.

You can optionally enable automatic resets of FSCs if an excessive number of discarded fabric egress packets is detected.

A Global Configuration mode fabric fsc-auto-recover command enables or disables automatic FSC resets upon detection of an excessive number of discarded fabric egress packets.

The following command sequence enables this feature:

configure
   fabric fsc-auto-recovery { disable | enable } [ max-attempts [ number_attempts | unlimited ] ]
   end

max-attempts [ number_attempts | unlimited ] specifies how many times StarOS will attempt to reset each FSC as an integer from 1 to 99 or unlimited (will not stop until FSC is reset). The default setting is 1.