Administrator Overview

This section describes the administrator login methods and permission control mechanism.

Administrator Login Methods

The Table 1 shows administrator login methods.

**Table 1** Administrator login methods
Login Method		Application Scenario	Interface	Description
Web (HTTPS)		An administrator performs operations on a device through the web page, which is more intuitive than the CLI.	Any Ethernet port reachable to the login PC and device works. You are advised to select management interface (MEth 0/0/0 or GigabitEthernet 0/0/0) for login.	You must set an administrator and password upon first login to the device. For details, refer to Logging In to the Web UI Using HTTPS. The device enables the HTTPS service by default.
CLI	Console	Console is the basis of other CLI login methods. Only one administrator can operate at the same time. Console is used in the following scenarios: An administrator logs in to the CLI for the first time. If an administrator cannot log in to the device remotely, the administrator can log in locally through the console port. If a device cannot start normally, the administrator can access the BootLoader menu through the console port to load the system software.	Console port	You must set a login password upon first login to the device though the console port. For details, refer to Logging In to the CLI Through the Console Port.
	Telnet	This method applies to remote management and maintenance. Multiple administrators can operate at the same time.	Any Ethernet port reachable to the login PC and device works. You are advised to select management interface (MEth 0/0/0 or GigabitEthernet 0/0/0) for login.	Direct login is not enabled by default. You must configure the Telnet service. For details, refer to CLI: Example for Logging In to the CLI Using Telnet (Local Authentication) or CLI: Example for Logging In to the CLI Using Telnet (RADIUS Authentication). NOTICE: During Telnet login, data and passwords are transmitted in plaintext mode, causing security risks. To secure data transmission, use STelnet instead.
	STelnet	STelnet supports identity authentication and encrypted data transmission and is more secure than Telnet.		Direct login is not enabled by default. You must configure the SSH service and users. For details, refer to CLI: Example for Logging In to the CLI Using STelnet (Local Authentication) or CLI: Example for Logging In to the CLI Using STelnet (RSA Authentication).
API	The administrator can call the FW's northbound API through the NETCONF or RESTCONF client for communication between the client and FW.		-	By default, the NETCONF or RESTCONF client cannot directly call the FW's northbound API. To do so, certain configuration is required.

Administrator Permission Control

The FW controls administrator permissions based on administrator roles, including the configurable menus on the web UI for web administrators and the executable commands on the CLI for CLI administrators. By default, the FW provides the administrator roles listed in Table 2. Each role has corresponding permissions, and the permissions determine the operations that administrators are allowed to perform. When you create an administrator, you can grant the default role to the administrator or custom-make a role on the FW.

**Table 2** Default administrator roles
Default Role	Description
system-admin	Has all permissions except the audit function.
device-admin	Has service configuration and device monitoring permissions.
device-admin (monitor)	Has the device monitoring permission.
audit-admin	The audit administrator has the permission to obtain the antivirus and IPS attack evidence collection data package, configure audit policies, view audit logs, and view and export all logs (excluding sandbox detection logs). Only the audit administrator has the permission to obtain the antivirus and IPS attack evidence collection data package, configure audit policies, and view audit logs.

The FW classifies roles based on permissions on web configuration items. The FW assigns a role read-write permission, read-only permission, or none permission on a web configuration item.

The CLI structure differs from the web UI menu. Therefore, the CLI permission control of a role is not the same as the previous operations on the web UI.
On the administrator Web UI, the configuration rights are read-write, read-only, and none; on the CLI, the rights are read-write and none. The read-only right on the Web UI is treated as the none right on the CLI. If the configuration right of a user is read-only on the Web UI, the user can view configurations on the Web UI, but cannot view the configurations on the CLI.

Except the role, each administrator has a level. In common cases, levels are configured only for CLI administrators. The FW provides the following default level-role mappings for the administrators that have levels configured but not bound to any role:

1: Monitoring level corresponds to Configuration administrator (monitoring).
2: Configuration level corresponds to Configuration administrator.
3: Management level to the 15th level correspond to System administrator.

That is to say, level-2 administrators have the operation permission of configuration administrators.

On the FW, the role is the only factor that determines administrator permissions, especially for CLI administrators. The level alone cannot determine the commands that can be executed by a CLI administrator. For example, the default level of A feature commands is level-2, and the level-2 administrator corresponds to the configuration administrator role. If the configuration administrator does not have permission on feature A, the level-2 administrator cannot execute the commands of feature A.

Level-0 administrators do not have any default role. They can run related network diagnostic tool commands (such as ping) and commands used to access other devices (such as Telnet).

Note the following when you use roles to control administrator permissions:

If an administrator account is bound to a specific role, the level of the administrator role takes precedence over the server authorization.
For CLI administrators using passwords for authentication, their permissions are determined by the configurations on the administrator page.

Administrator Authentication Method

The FW authenticates an administrator account in one of the following modes before allowing the administrator to log in:

Local authentication

Both the administrator account and password are stored on the FW.
Server authentication:
- If the administrator does not use domain authentication, the administrator account must be created on the FW, and the password is saved on the authentication server. Currently, the FW supports server authentication modes: AD, LDAP, RADIUS, and HWTACACS.
- If the administrator uses domain authentication, the administrator account and password must be created and saved on the domain authentication server. No administrator information needs to be configured on the FW. Currently, the FW supports server authentication modes: AD, LDAP, RADIUS, and HWTACACS.
Server and local authentication

The FW performs server authentication first. The FW performs local authentication only if it fails to connect to the authentication server.

After the administrator account is created, the virtual system or authentication domain of a user name must be obtained to log in to the device. For example, user username on virtual system vsys with domain (domainname) authentication uses user name username@domainname@@vsys to log in to and manage the FW.

The FW determines the authentication and authorization modes based on the authentication scheme, authorization scheme, or third-party server template bound to the administrator account or authentication domain. The logins of the admin and admin@test accounts are used as examples to describe the FW processing:

Login using the admin account:

Check whether the FW has the admin account. If yes, use the authentication scheme, authorization scheme, and third-party server template bound to the admin account. If no, use the authentication scheme, authorization scheme, or third-party server template bound to the default authentication domain.

By default, the local administrator is bound to the default authentication scheme and default authorization scheme. The authentication domain (the default domain or a new authentication domain) is bound to the default authentication scheme and default authorization scheme.
Login using the admin@test account:

The FW directly uses the authentication scheme, authorization scheme, or third-party server template bound to the test authentication domain.

By default, the authentication domain (the default domain or a new authentication domain) is bound to the default authentication scheme and default authorization scheme.

Administrator Accounts

Table 3 shows the default administrators of the FW.

**Table 3** Default administrators
Account	Password	Role	Description
huawei	-	API administrator	API administrator predefined for cloud-based management mode.

To secure FW, you are advised to follow the minimum authorization principle and plan administrator accounts with different permissions to avoid administrator account sharing. If default roles cannot meet requirements, you can create new administrator roles.

You are advised to change the password immediately after the login.