Connectivity Guide

• name inherit — Enter the name of the RADIUS or TACACS+ user role that inherits permissions from an
OS10 user role; 32 characters maximum.
• existing-role-name — Assign the permissions associated with an OS10 user role:
– sysadmin — Full access to all commands in the system, exclusive access to commands that manipulate
the le system, and access to the system shell. A system administrator can create user IDs and user roles.
– secadmin — Full access to conguration commands that set security policy and system access, such as
password strength, AAA authorization, and cryptographic keys. A security administrator can display security
information, such as cryptographic keys, login statistics, and log information.
– netadmin — Full access to conguration commands that manage trac owing through the switch,
such as routes, interfaces, and ACLs. A network administrator cannot access conguration commands for
security features or view security information.
– netoperator — Access only to EXEC mode to view the current conguration. A network operator
cannot modify any conguration setting on a switch.
Default OS10 assigns the netoperator role to a user authenticated by a RADIUS or TACACS+ server with a missing or
unknown role or privilege level.
Command Mode CONFIGURATION
Usage Information
• When a RADIUS or TACACS+ server authenticates a user and does not return a role or privilege level, or
returns an unknown role or privilege level, OS10 assigns the netoperator role to the user by default. Use
this command to recongure the default netoperator permissions.
• To assign OS10 user role permissions to an unknown user role, enter the RADIUS or TACACS+ name with the
inherit existing-role-name value. The no userrole default version of the command resets
the role to netoperator.
Example
OS10(config)# userrole default inherit sysadmin
Supported Releases 10.4.0E(R3P3) or later
X.509v3 certicates
OS10 supports X.509v3 certicates to secure communications between the switch and a host, such as a RADIUS server. Both the switch
and the server exchange a public key in a signed X.509v3 certicate issued by a certicate authority (CA) to authenticate each other. The
certicate authority uses its private key to sign the switch and host certicates.
The information in the certicate allows both devices to prove ownership and the validity of a public key. Assuming the CA is trusted, the
switch and authentication server validate each other's identity and set up a secure, encrypted communications channel.
User authentication with a public key certicate is usually preferred to password-based authentication, although you can use both at the
same time, to:
• Avoid the security risk of using low-strength passwords and provide greater resistance to brute-force attacks.
• Provide assurance of trusted, provable identities (when using certicates digitally signed by a trusted CA).
• Provide security and condentiality in switch-server communications in addition to user authentication.
For example, you can download and install a X.509v3 certicate to enable public-key authentication in RADIUS over TLS authentication,
also called as RadSec. OS10 supports a public key infrastructure (PKI), including:
• Generation of self-signed certicates and certicate signing requests (CSRs), and their corresponding private keys
• Installation and deletion of self-signed certicates and CA-signed certicates
• Secure deletion of corresponding private keys
• Installation and deletion of CA certicates in the system "trust store"
• Display of certicate information
Security
827