CloudCampus Solution V100R020C00 Design and Deployment Guide for Large- and Medium-Sized Campus Networks (Non-virtualization Scenario)
Admission Configuration
- Authentication and Authorization Management
- Configuration Guide in Typical Scenarios
- Configuring User Access Without Authentication
- Password Authentication
- Portal Authentication
- Configuration Task Overview
- (Optional) Configuring an Account for an End User
- (Optional) Connecting to Third-Party Platforms
- (Optional) Enabling the HTTP Port
- (Optional) Enabling the Port for Outdated Device Certificates
- (Optional) Customizing a Portal Page Pushed to End Users
- Configuring a Portal Page Pushing Policy
- (Optional) Configuring an Online User Control Policy
- (Optional) Configuring a Portal Server Template
- (Optional) Configuring a RADIUS Server Template
- Configuring an Authentication Point
- Configuring an Authentication Rule
- Configuring an Authorization Result
- Configuring an Authorization Rule
- Multi-Network Portal Authentication
- 802.1X Authentication
- Configuring a User Group and User
- (Optional) Attaching a Role to an Account
- Setting Basic Parameters
- (Optional) Configuring an Online User Control Policy
- (Optional) Configuring a Policy Element
- Configuring a RADIUS Template
- Configuring an Authentication Point
- Configuring an Authentication Rule
- Configuring an Authorization Result
- Configuring an Authorization Rule
- MAC Address Authentication
- PSK+MAC Address Authentication
- Two-Factor Authentication
- iMaster NCE-Campus as a Relay Agent
- Interconnection with a Third-Party Authentication Server
- HWTACACS Authentication
- Device Administrator Authentication
- Secure Access for IoT Access Control Terminals
- Configuring Secure Access for Cellular Network Terminals (IoT)
- Guest Management
- Configuring a Guest Administrator
- Configuring Guest Access Through Self-Registered Accounts
- Configuring Guest Access Through One-Click Authentication by Account, Email Address, or Mobile Number
- Configuring Guest Access Using a Public QR Code
- Configuring Guest Access Using Accounts Created by Administrators
- Configuring Guest Access Using a Facebook Account
- Configuring Guest Access Using a Twitter Account
- Configuring Guest Access Through One-Click WeChat Portal Authentication
- Configuring Guests to Obtain an Authentication URL by Following a WeChat Official Account (Editing Mode)
- Configuring Guests to Obtain an Authentication URL by Following a WeChat Official Account (in Developer Mode)
- Overview
- Setting Up a WeChat Official Accounts Platform Server Using the PHP Application
- Binding a WeChat Official Account to the Enterprise WeChat Official Accounts Platform Server
- Setting Parameters for Connecting the Enterprise WeChat Official Accounts Platform Server to iMaster NCE-Campus
- Configuring iMaster NCE-Campus
- Appendix - Secondary Development of the WeChat Official Accounts Platform
- Configuring Guest Access Through QR Code Scanning Using the WeChat APP via Wi-Fi
- Account Blacklist Management
- CA Management
- Boarding Configuration
- AD/LDAP Synchronization
- Overview
- Synchronization by OU for the AD/LDAP Server
- Synchronization by Group for the AD Server (Organization Structure Is Described by OU)
- Synchronization by Group for the AD Server (Organization Structure Is Described by Group)
- Synchronization by Group for the LDAP Server
- Synchronization by Plane Structure or User-defined Synchronization
- Synchronization by Conditions
- Configuring Non-Synchronization
- Authentication Using a RADIUS Token Server
- Authentication Using a Third-Party HTTP Server
- Authentication Using a Third-Party Database
- SSO Through Interconnection with AD FS
- Configuring Online Behavior Management
- Configuring a RADIUS Accounting Device
- Managing Admission Devices
- Region Management
- Terminal Management
- MDM Interconnection
- Appendix
Authentication and Authorization Management
Configuration Guide in Typical Scenarios
Context
The admission configuration process and operations vary according to the networking type, access point, and authentication mode. Access points in different networking types may vary. You can select a suitable authentication mode and access points based on the actual networking type.
Networking Type |
Access Point |
Authentication Mode |
|---|---|---|
Single AP Routers and APs Firewalls, routers, and APs Firewalls, central APs, and RUs |
AP |
iMaster NCE-Campus as a portal server iMaster NCE-Campus as a RADIUS server iMaster NCE-Campus as a relay agent Interconnection with a third-party portal server Interconnection with a third-party RADIUS server |
Switches, ARs, and firewalls |
Switch |
|
Single firewall |
Firewall |
|
Single router |
Router |
|
Switches and WACs |
WAC |
Configuring User Access Without Authentication
Context
If you do not want to authenticate access terminals, do not configure functions related to access control when configuring devices at a site.
Configuration Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Open network and Push pages to OFF.
AR
- Choose from the navigation pane, click Create, and configure the basic information about an SSID.
- On the Security authentication page, set Authentication mode to OPEN and Push pages (Portal authentication) to OFF.
Firewall
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security authentication page, set Authentication mode to OPEN.
Switch or WAC
N/A
Password Authentication
Configuring PSK-based User Access
Context
If you do not want to deploy an authentication server but want to secure your network, you can choose PSK authentication. All users accessing the Internet use the same preconfigured password. Therefore, administrators are advised to change their passwords periodically.
Configuration Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Semi-open network, select PSK/PPSK, and set Key type to PSK. Then, set Encryption mode, Encryption algorithm and an Key (SSID access password). The options of Encryption algorithm are as follows:
- AES: Configures AES encryption.
- AES-TKIP: Configures AES-TKIP encryption. After passing the authentication, user terminals can use the AES or TKIP algorithm for data encryption.
- TKIP: Configures TKIP encryption.
AR
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security authentication page, set Authentication mode to PSK, select Encryption mode, and click Set to set an access password for the SSID.
- On the Policy control page, configure traffic rate limiting policies as required.
Firewall
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security authentication page, set Authentication mode to PSK, select Encryption mode, and click Set to set an access password for the SSID.
Switch or WAC
NA
Configuring PPSK-based User Access
Context
If you do not want to deploy an authentication server but want to secure your network, you can choose PPSK authentication. Different from PSK accounts, PPSKs accounts with the same SSID can be configured with different Wi-Fi passwords.
Authentication Mode |
Account Type |
Description |
|---|---|---|
Password authentication |
PPSK |
An account and the Wi-Fi password are required for authentication, need to be preconfigured by tenant administrators on iMaster NCE-Campus. Users need to obtain accounts and Wi-Fi passwords from tenant administrators. |
Configuration Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Semi-open network, select PSK/PPSK/SAE/SAE-PSK, and set Key type to PPSK. Then, set Encryption mode, Encryption algorithm and Escape policy. If automatic MAC address binding is enabled, when a device accesses the SSID for the first time, the device's MAC address and PPSK account will be automatically bound.
When a terminal accesses an SSID, if the PPSK account used by the terminal is bound to the MAC address of another terminal, the terminal cannot access the SSID.
AR, Firewall, Switch, WAC
NA
- Choose from the main menu.
- Click Create to create a PPSK account.
![]()
- Click Import to import PPSK accounts in batches using an Excel template.
- Click Create to create a PPSK account.
Parameter Description
Parameter |
Description |
|---|---|
Account |
Name of a PPSK user account. |
Wi-Fi key |
Password used by a PPSK user account to connect to a cloud-managed device. |
Confirm the Wi-Fi key |
|
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. |
MAC Addresses |
Terminal's MAC address bound to the PPSK user account if the account allows only one terminal to access the network. You can bind the terminal MAC address to the PPSK user account when creating the account, or enable automatic MAC address binding when configuring an AP SSID. When a terminal accesses an SSID using a PPSK user account used which is bound to the MAC address of another terminal, the terminal cannot access the SSID. |
VLAN |
ID of the VLAN to which the PPSK user account belongs. |
SSID |
Name of an AP SSID. |
Portal Authentication
Configuration Task Overview
Context
Portal authentication supports multiple authentication modes, and different authentication modes require different configurations. You need to choose an appropriate network authentication mode based on actual requirements. The following table lists the configuration tasks for each authentication mode.
If you want to authenticate access users but not to restrict their access permissions, you do not need to configure an authorization result or an authorization rule.
(Optional) Configuring an Account for an End User
Configuring a User and User Group
Context
In the enterprise employee access scenario, user name, and password authentication can be used to implement end user access. During portal authentication or 802.1X authentication, end users need to enter the following account information.
Authentication Mode |
Account Type |
Description |
|---|---|---|
User name and password authentication |
User |
A user name and the password are required for authentication, and need to be preconfigured by tenant administrators on iMaster NCE-Campus. Users need to obtain user names and passwords from tenant administrators. NOTE:
iMaster NCE-Campus predefines the ~anonymous account (without a password) for anonymous authentication. This account cannot be deleted or modified. |
In the guest access scenario, the following methods are recommended to implement portal authentication for end users.
Authentication Mode |
Account Type |
Description |
|---|---|---|
User name and password authentication |
Common guest |
A user name and the password are required for authentication, need to be preconfigured by tenant administrators on iMaster NCE-Campus, or registered by end users on the pushed portal page. |
Passcode authentication |
Passcode |
An access code, a string of 6 to 12 characters that can contain letters, digits, or both, is required for authentication, need to be preconfigured by tenant administrators on iMaster NCE-Campus. Users need to obtain access codes from tenant administrators. |
Procedure
- Choose from the main menu.
- Click
![]()
to create a user. You can create users one by one.![]()
- Select a user group and click Create to create a user. You can create users one by one.
![]()
When creating a user, you are advised to bind an email address or phone number to the user to facilitate password change.
![]()
- Click
![]()
to import users and user groups. You can use an Excel template to import users and user groups in batches. - Click
![]()
to export users and user groups. After the export task is created, click OK and choose to view and download the task.
- Click
- (Optional) Choose from the main menu.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
![]()
- After the parameters are set, click
![]()
to apply the created user control policy to a specific user group or user.![]()
![]()
- When creating a user, you can also set the maximum number of access terminals. The maximum number of access terminals configured on different pages takes effect in the following sequence in descending order: Maximum number of access terminals when a user is created > Number of access terminals allocated to the user > Number of access terminals allocated to the user group. If the Maximum number of terminals parameter is disabled when a user is created, the maximum number of access terminals is subject to the configuration in the user control policy. If the Maximum number of terminals parameter is enabled and no restrictions is selected, there will be no limit on the number of access terminals. Users passing MAC address authentication are not restricted by this configuration. If a user group is configured, each user in the user group supports the maximum number of access terminals.
- When an authentication component is remotely deployed, the maximum number of access terminals supported on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
to create a user. You can create users one by one.
to import users and user groups. You can use an Excel template to import users and user groups in batches.
to export users and user groups. After the export task is created, click OK and choose 
to apply the created user control policy to a specific user group or user.
Related Operations
- Advanced Search
You can perform advanced search for user information. The following search items are available. You can select one or more matching items for advanced search.
- Username
- Login type: 802.1X, Portal, HWTACACS
- User status: Effective, Expired, Disable
- Login time
- Used only for mobile certificate authentication
- User-defined field
Click
![]()
, and then click Create to customize the user information required for registration when the administrator creates a user.![]()
- Resetting a user password
Select the user whose password needs to be changed and click
![]()
to reset the user password.![]()
, and then click 
to reset the user password.
Parameter Description
Parameter |
Description |
|
|---|---|---|
User name |
Username and password used by an end user during authentication to connect to a cloud-managed device. |
|
Password |
||
Confirm password |
||
Role |
Role attached to the user. |
|
Email address and phone number of a user. When resetting passwords, a user receives a verification code via an email or an SMS message and sets a new password based on the verification code. |
||
Phone number |
||
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. This parameter does not take effect for HWTACACS authentication access users. |
|
Expiration time |
Time when the user account expires. If this parameter is left empty, the account is valid permanently. |
|
Change password upon next login |
Whether to change the account password upon next login. If this parameter is enabled, users need to change the initial passwords upon next login. This parameter is valid only for portal authentication. This parameter does not take effect for HWTACACS authentication access users. |
|
Login mode |
Portal |
End users are allowed to access networks only through portal authentication. |
802.1X |
End users are allowed to access networks only through 802.1X authentication. |
|
HWTACACS |
End users are allowed to access networks only through HWTACACS authentication. Device administrators can use usernames and passwords configured during the creation to remotely log in to devices for management. |
|
Only mobile certificate authentication is allowed |
After this function is enabled, users can be authenticated only through the EAP-TLS protocol. If the authentication type does not match, the authentication fails. This function can be enabled only when the login mode is set to 802.1X. |
|
RADIUS attribute |
IP address of the access terminal/Subnet Mask |
IP address and mask allocated to a terminal after the terminal is authenticated by the RADIUS server. |
IP address segment of the access terminal |
IP address segment allocated to terminals after successful RADIUS authentication. This parameter applies to the scenario where a gateway functions as a terminal. The gateway allocates IP addresses to connected terminals from this IP address segment through DHCP. |
|
User-defined authorization parameters |
User-defined RADIUS attributes can be configured for terminals. A maximum of 20 user-defined RADIUS attributes can be configured. |
|
Access binding information |
IP address of the bound terminal |
Terminal IP address bound to the user account. |
MAC address of the bound terminal |
Terminal MAC address bound to the user account. The value must be in the format **-**-**-**-**-**, such as 11-11-11-11-11-11. |
|
Bind the ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
IMSI bound to the SIM or USIM card |
International mobile subscriber identity (IMSI) or SIM card number bound to the user account. The value is a string of 1 to 15 digits. IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Binding an Access Device |
IP address of the access device |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
Parameter |
Description |
|---|---|
User group name |
Name of a user group. A user group contains multiple users. When configuring an access control policy, you can specify the user group to which the policy applies. |
Parameter |
Description |
|---|---|
Account |
Name of a PPSK user account. |
Wi-Fi key |
Password used by a PPSK user account to connect to a cloud-managed device. |
Confirm the Wi-Fi key |
|
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. |
MAC Addresses |
Terminal's MAC address bound to the PPSK user account if the account allows only one terminal to access the network. You can bind the terminal MAC address to the PPSK user account when creating the account, or enable automatic MAC address binding when configuring an AP SSID. When a terminal accesses an SSID using a PPSK user account used which is bound to the MAC address of another terminal, the terminal cannot access the SSID. |
VLAN |
ID of the VLAN to which the PPSK user account belongs. |
SSID |
Name of an AP SSID. |
Parameter |
Description |
|
|---|---|---|
MAC Account Name |
MAC account name. |
|
MAC address list |
List of MAC addresses that can be accessed by end users. |
|
User Group |
User group to which the MAC account belongs. |
|
Role |
Role attached to the MAC account. |
|
Email address and phone number associated with the MAC account. |
||
Contact number |
||
Expiration time |
Expiration time of the MAC account. |
|
Terminals Bound to an Access Device |
Terminal IP address |
Terminal IP address bound to the user account. |
Bound terminal ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
SIM/USIM's IMSI |
SIM card or IMSI bound to an account. The value is a string of 1 to 15 characters consisting of digits (0-9). IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Bind an access device |
Access device IP address |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
(Optional) Attaching a Role to an Account
Context
In addition to user groups, accounts can be managed based on account roles. An account can belong to only one user group but can be attached to multiple roles. Accounts and roles are mapped in a one-to-many manner. Roles can be created manually by an administrator or created automatically during AD/LDAP account synchronization. Roles can be used for authentication, authorization, and security policy allocation.
Procedure
- Choose from the main menu.
- Click Create to create a role.
![]()
- After the role is created, click
![]()
next to the role, and click Add to attach the role to a user account, guest account, or MAC account.![]()
- Click Import to import roles in batches using an Excel template.
- Click Export All to export information about all roles.
- Click Create to create a role.
next to the role, and click 
Setting Basic Parameters
Context
You can specify validity periods for user accounts, as well as retention periods for expired user accounts. As such, expired user accounts can be cleaned up automatically after the specified retention period elapses.
You can also configure a password policy for user accounts.
Procedure
- Choose from the main menu.
- Click the User Password Policy Configuration tab and modify the password policy for user accounts.
The password policy allows you to properly set the complexity of your account password, password updating period, and character limitations to prevent your password from being stolen. iMaster NCE-Campus provides a default password policy which you can modify as required.
![]()
- Click the SMS Verification Code tab, and set SMS verification code length and SMS verification template.
![]()
- Click the Advanced Parameter tab, and set advanced parameters. The following figure only shows some parameters. For details about other parameters, see Parameter Description at the end of this section.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Complexity rule |
Password complexity and password length of a user account. The password complexity requirements are as follows:
|
Length range |
|
Validity period |
Password validity period of a user account.
|
Days of notifications before password expiration |
|
Previous passwords disallowed |
Number of recent historical passwords that a user is not allowed to reuse. When changing the password, users cannot reuse previous passwords specified by Password repetition not allowed. |
User lockout |
Whether to lock user accounts for a specific period. With this function enabled, if a terminal uses an account and password to connect to a cloud-managed device, but the number of consecutive login failures reaches the value of Login failure count in specified times within the period specified by Specified time period, the terminal's account is locked for a period, which is specified by Lockout duration. |
Specified time period |
|
Login failure count in specified times |
|
Lockout duration |
|
Enable bound account IP/MAC address |
Whether to bind an IP address or a MAC address to a user account. |
Parameter |
Description |
|---|---|
SMS Verification Code Generation Policy |
Character types in an SMS verification code sent to users. The options are as follows:
|
SMS verification code length |
Length of an SMS verification code sent to a user. |
SMS verification template |
Template of an SMS verification code sent to a user. After the configuration, the system sends an SMS message based on the settings. All languages supported by the system share a configuration result. |
Parameter |
Description |
|
|---|---|---|
Account Validity Allocation |
Support the validity of login postponed account |
Whether to extend the validity period of an account. With this function enabled, after portal authentication-free is configured to implement MAC address-prioritized authentication, if a self-registered user logs in to iMaster NCE-Campus within the account validity period, the validity period of the user account will be extended for a further period from the user login time. For example, if the validity period of a self-registered user account is set to 1 day, when the user logs in to iMaster NCE-Campus at 8:00 a.m. on 1st September, the account is valid till 8:00 a.m. on 2nd September. If the user logs in to the system again at 12:00 p.m. on 1st September, the account is valid till 12:00 p.m. on 2nd September. |
Portal authentication-free NOTE:
If this function is enabled on the current page, you need to enable the portal authentication-free function in SSID settings of APs or routers, and authentication settings of switches. |
Cross-site Portal authentication-free |
After a terminal connects to an SSID of a site, the terminal can preferentially use the MAC address for authentication. If this function is enabled, the terminal is allowed to connect to the same SSID of other sites and preferentially use the MAC address for authentication. |
Mac account Portal authentication-free |
Whether to enable MAC address-prioritized portal authentication. If a user uses a MAC account that has passed portal authentication to log in to the controller within the authentication-free validity period, or uses a MAC address that has been recorded on the user management page of the controller, the user can log in to the controller successfully without authentication. NOTE:
When authentication components are deployed remotely, each authentication component performs MAC address authentication-free for users only after they pass portal authentication. MAC address authentication-free data cannot be synchronized between the authentication components and the headquarters. |
|
Support login delay Portal certification-free validity period |
After a user passes MAC address authentication and logs in to iMaster NCE-Campus within the validity period, the validity period of the user account will be extended for a further period from the user login time. |
|
Configuration for Expired Accounts |
Automatically clear expired users |
The Automatically clear expired users parameter indicates whether to automatically delete expired accounts. After this function is enabled, accounts that have expired for more than the specified number of days will be automatically deleted based on the configured clearance period. |
Clearance period (hours) |
||
Retaining expired users |
||
After the account is disabled, the validity period is recalculated |
After this function is enabled, the validity period of an account is not calculated after the account is disabled, and the remaining validity period is counted after the account is enabled again. The retention period of a disabled user specifies the time period for storing a disabled user. |
|
Disable user retention period (days) |
||
Maximum validity period |
Maximum validity period of an account. The account validity period set when you create a user or guest account or configure a guest account policy cannot exceed the maximum validity period set here. If the maximum validity period is not set, the account validity period for a user or guest account or in a guest account policy cannot exceed 9999. |
|
Timeout Interval of an Offline Device |
Timeout interval |
Device offline duration. When the device offline time exceeds the value of this parameter, the system logs out the online users on the device. This setting takes effect only for HACA portal authentication. |
Sensitive data |
IMSI data plaintext export |
Whether to export IMSIs in clear text. |
Enable the RADIUS user name identification policy |
To enable the RADIUS user name identification rule, run the following command |
Whether to enable RADIUS username identification. If this function is enabled, specified parameters will be carried in RADIUS usernames based on user identification rules. In such cases, the controller can learn the parameter values from RADIUS usernames automatically when RADIUS users go online. Currently, only an IMSI or an ESN can be carried in a RADIUS username. Therefore, if IMSIs or ESNs are specified in authentication rules, you need to enable this function. Currently, the following user identification rules are supported: ACCOUNT IMSI@ACCOUNT IMSI@ESN@ACCOUNT ESN@ACCOUNT |
RADIUS Authentication Transmission Protocol Configuration |
RADIUS authentication transmission protocol SSL configuration |
SSL for RADIUS authentication. TLSv1.2 is used by default. To set the RADIUS authentication transmission protocol to TLSv1 or TLSv1.1, perform the following operations:
TLSv1 and TLSv1.1 may pose data leakage risks. For security purposes, TLSv1.2 is recommended because it is more secure than TLSv1 and TLSv1.1. |
Default Self-Registration User Policy |
Subscriber validity period |
If third-party devices function as authentication devices, this policy takes effect only when no guest account policy is bound to the portal page specified in the desired portal page push policy. If cloud-managed devices function as authentication devices, this policy takes effect only when no guest account policy is bound to the portal page specified in the desired portal page push policy and the user self-registration function is disabled in the site configuration. |
Password validity period |
||
User group |
||
Anonymous authentication |
Enable anonymous authentication |
Whether to enable anonymous authentication. If this function is enabled, you need to set network areas where anonymous authentication is allowed. |
Account expiration notification configuration |
Alert account type |
After this function is enabled, the system can remind users that their accounts are about to expire in advance. This function is applicable only to common and guest accounts. You can set an SMS notification template or email notification template. |
Account expiration reminder time (day) |
||
Template for Notification of Expiry Messages |
||
Email notification template for expiration |
||
Configuring Portal Authentication for Multiple Networks |
Network type |
Network type for multi-network portal authentication. |
Network suffix |
Suffix of the account used by a user to access the network. |
|
Network role |
Role of the user who accesses the network. This parameter is configured on the page. |
|
Enabling SAVI |
Expiration Time (s) |
When iMaster NCE-Campus functions as a relay server to connect to a third-party authentication server and the SAVI function is configured on devices, devices will check whether packets are valid based on whether the source IP addresses of the packets match bindings between the IP addresses and interfaces. After this function is enabled, iMaster NCE-Campus checks the consistency of the MAC address, IP address, and user name to verify user validity. If a spoofing user exists, the system records the user in the blacklist and reports the blacklist to the configured blacklist server. The third-party authentication server forces the blacklisted users offline. The expiration time is the SAVI detection expiration time. When a device goes offline for a period longer than the configured expiration time, iMaster NCE-Campus does not perform MAC spoofing detection on the device when it goes online again. |
Access protocol |
||
Protocol version |
||
Certificate verification |
||
Address of the blacklist server |
||
(Optional) Connecting to Third-Party Platforms
Configuring an Email Server
Context
If iMaster NCE-Campus needs to send emails to users, you need to configure an email server first.
iMaster NCE-Campus needs to send emails in the following scenarios:
- The MSP administrator or tenant administrator forgets the password: iMaster NCE-Campus sends a reset password to the administrator through an email.
- The tenant administrator performs alarm settings on iMaster NCE-Campus: iMaster NCE-Campus sends emails to notify users of reported alarms.
- The tenant administrator wants to use the email-based deployment function: iMaster NCE-Campus needs to send deployment emails to related personnel.
- Tenants want to register accounts by themselves: iMaster NCE-Campus sends an email containing an activation link to the tenants.
- The MSP administrator inspects tenant devices: iMaster NCE-Campus sends the inspection report to the administrator's mailbox, if needed.
- The MSP administrator deletes ESNs or devices: iMaster NCE-Campus sends a notification email to the tenant administrator, if needed.
- A tenant license is about to expire: iMaster NCE-Campus sends a notification email to a tenant.
- When portal authentication is configured for guest access, you need to set the approver notification mode or guest notification mode to email notification.
The system administrator has configured an email server for sending emails. If the MSP administrator wants to use another email server, the MSP administrator needs to configure an email server separately.
If both the system administrator and MSP administrator have configured an email server, the email server configured by the MSP administrator is used preferentially. If the email server configured by the MSP administrator is not found, the email server configured by the system administrator is used.
Procedure
- Upload an email server certificate.
- Contact the SMS server provider to obtain a certificate file.
- Choose from the main menu.
- Choose Service Certificate Management from the navigation pane. On the Services page, click CampusBaseServiceServerConfigMoudle.
- Click the Trust Certificate tab and click Import. On the displayed page, enter the certificate information, select the desired email server certificate, and click Submit to upload the certificate to iMaster NCE-Campus.
![]()
- Choose from the main menu.
- Set parameters for connecting to the email server.
![]()
![]()
If the email server uses a third-party CA certificate, you are advised to disable Validate server certificate.
- Click Test to verify the email sending function.
- If the message "The test succeeds" is displayed and the mailbox receives the test email, the configuration is successful. Click Save.
- If the message "The test succeeds" is displayed but the mailbox does not receive the test email, check whether the email function of the SMTP server is normal.
- If the message "Failed to connect to the email server" is displayed, check whether the above parameters are correctly configured.
![]()
- Affected by the network quality and performance of the SMTP server, the time of receiving emails will be delayed within two minutes.
- Some SMTP providers set the right control for third-party application access. If the test fails, check whether the function of controlling third-party application access is enabled on the SMTP server and set password to the authentication password of the SMTP server.
- Limited by security policies of email service providers, administrators may fail to receive emails in some scenarios. If no email is received, log in to the email service website or contact the email service provider to check whether the email is returned or other exceptions occur. Alternatively, replace the email server and try again.
Parameter Description
Parameter |
Description |
|---|---|
SMTP address |
SMTP address of the mailbox from which emails are sent. The address must be an IP address or in the smtp.mail.com format. NOTE:
SMTP is short for Simple Mail Transfer Protocol. SMTP is mainly used to transfer system emails and provide email notifications. |
Port |
Port number of the SMTP service provided by the email server. You can obtain the port number from the email service provider. By default, the port number is 25. |
Secure connection |
Whether secure connection is enabled. |
Encryption connection type |
Protocol for establishing an encrypted communication link between iMaster NCE-Campus and the SMTP server. This parameter is available only when Secure connection is selected. NOTE:
Secure protocol TLSv1.2 is recommended. TLSv1.0 and TLSv1.1 are insecure protocols; therefore, exercise caution when using them. |
Validate server certificate |
For security purposes, select Secure connection and Validate server certificate. Select certificate. |
Certificate File |
Certificate file of the email server. This certificate ensures communication security between iMaster NCE-Campus and the email server. |
Authentication |
Whether to enable the email account and password authentication. |
Account |
The two parameters are valid only when Authentication is selected. User name and password for logging in to the SMTP server. |
Password |
|
Sender Email |
Sender email address, which must have been registered on the email server. During the email test, this address is used as a recipient email address. After the connectivity test is successfully performed and the configurations are saved, this address is used as the sender email address. |
Customized email subject |
Email subject. An administrator can customize the prefix and suffix of the email subject. When an email is sent, the prefix and suffix are automatically added before and after the email subject. |
Customized email signature |
Email signature. An administrator can customize the email signature, and the signature is automatically attached to emails. |
Configuring an SMS Server
Context
You need to configure the SMS service if SMS authentication is required. iMaster NCE-Campus needs to send SMS messages in the following scenarios:
- Two-factor authentication is performed when the system administrator, an MSP administrator, or a tenant administrator logs in to iMaster NCE-Campus
- An end user attempts to access the network using a verification code received in an SMS message.
- When a guest attempts to access the network using SMS authentication, iMaster NCE-Campus needs to send an SMS message to notify administrators of guest access. After the guest passes authentication, iMaster NCE-Campus needs to send another SMS message to notify the administrators of the guest authentication result.
Before configuring the SMS service, you need to configure an SMS platform to specify the SMS gateway and configure an account based on the SMS platform to send SMS messages.
- SMS platform: You need to set parameters about a third-party SMS platform on iMaster NCE-Campus according to the information provided by the SMS platform. For details, see the interface document of the third-party SMS platform.
- SMS server: You need to set parameters for interconnection between iMaster NCE-Campus and a third-party SMS platform. After the interconnection is successful, iMaster NCE-Campus can send SMS messages.
By default, the system is pre-configured with the following SMS server connection parameters:
- fungo: http://qxt.fungo.cn/Recv_center. This is the SMS platform of fungo.cn (Beijing, China).
- twilio: https://api.twilio.com:8443/2010-04-01/Accounts/{USERNAME}/Messages.json. To use this SMS server, access www.twilio.com and apply for an account.
- If the system administrator has configured an SMS server and enabled Tenant heritable, tenant administrators can use the SMS server configured by the system administrator. Otherwise, they cannot use the SMS server configured by the system administrator and need to configure an SMS server on their own. For details about how a system administrator configures an SMS server, see Configuring an SMS Server.
![]()
After this function is enabled, sub-tenants can use the SMS server. This function applies only to SMS authentication for controller login.
If you do not want to use the SMS server configured by the system administrator, you can configure an SMS server as needed.
Prerequisites
If a tenant administrator wants to configure an SMS server, the tenant administrator needs to contact the system administrator to configure the SMS platform information. Only the system administrator can configure the SMS platform information.
Procedure
- Import an SMS server certificate.
- Contact the SMS server provider to obtain a certificate file.
- Log in to iMaster NCE-Campus as a system administrator and choose from the main menu.
- Choose Service Certificate Management from the navigation pane. On the Services page, click CampusBaseServiceServerConfigMoudle.
- Click the Trust Certificate tab and click Import. On the displayed page, enter the certificate information, select the desired SMS server certificate, and click Submit to upload the certificate to iMaster NCE-Campus.
![]()
- Choose from the main menu and click the SMS Server tab.
- Select an SMS platform, and set required parameters.
![]()
HTTPS is recommended because it is more secure than HTTP.
- Set SMS service type to HTTP SMS Service and select fungo from the SMS platform drop-down list box.
![]()
- Set SMS service type to HTTP SMS Service and select twilio from the SMS platform drop-down list box.
![]()
- Set SMS service type to SMPP SMS Service and select the created SMS platform template from the SMS platform drop-down list box.
![]()
- Set SMS service type to HTTP SMS Service and select fungo from the SMS platform drop-down list box.
- Click Test to verify validity of the SMS message sending function.
- If the test succeeds, the message "The test succeeds" is displayed, and you can receive the test SMS from iMaster NCE-Campus.
- If the test fails, the message "Failed to test the SMS server" is displayed. Perform operations according to the scenarios:
- If an error code is displayed in the dialog box, check the product documentation of the SMS service provider for the cause of the error, and obtain the troubleshooting method.
- If no error code is displayed in the dialog box, contact the system administrator to check whether the SMS server template is correctly configured.
- After the test is successful, click Save.
Parameter Description
Parameter |
Description |
|---|---|
SMS platform |
SMS template. Administrators can configure an SMS server template to specify an SMS server. By default, the following SMS server connection parameters are pre-configured in the system:
To use the SMS service provided by another carrier, you can create an SMS template. |
Account |
Account obtained during SMS service application. |
Token |
Password obtained during SMS service application. NOTE:
For system and user security purposes, it is recommended that the password provided by a third party meet the complexity requirements. |
SMS message signature |
Signature of SMS messages. |
Send number |
Number obtained from the SMS service provider, used to check whether the SMS message sending number is correct. This parameter is available only in the twilio template. Number obtained from the SMS service provider, which is used to check whether the SMS message sending number is correct. |
Inheritance |
If neither the MSP administrator nor the tenant administrator configures an SMS server, the SMS server configured by the system administrator is used when this function is enabled. If this function is disabled, MSPs and tenants cannot use the SMS server configured by the system administrator. |
Test number |
Number for sending a test SMS message. The value can be any available mobile number. |
Test SMS message |
Content of a test SMS message. |
Parameter |
Description |
|---|---|
SMS platform |
SMS template. Administrators can configure an SMS server template to specify an SMS server. |
System id |
SMS server ID obtained during SMS service application. |
Password |
Password obtained during SMS service application. |
Source number |
Number obtained from the SMS service provider, used to check whether the SMS message sending number is correct. |
Inheritance |
If neither the MSP administrator nor the tenant administrator configures an SMS server, the SMS server configured by the system administrator is used when this function is enabled. If this function is disabled, MSPs and tenants cannot use the SMS server configured by the system administrator. |
Test number |
Number for sending a test SMS message. The value can be any available mobile number. |
Test SMS message |
Content in a test SMS message. |
(Optional) Enabling the HTTP Port
Context
By default, iMaster NCE-Campus supports only the HTTPS protocol. The HTTP protocol may pose security risks and is disabled by default. If you need to configure HTTP for pushing portal pages to end users, enable HTTP ports on the management plane.
Procedure
- Log in to the management plane.
- Choose from the main menu, click , set ENABLE_8445(enable ACANginx 8445 Virtual Server or not) to true, and click OK.
![]()
- Click
![]()
in the upper right corner to check whether the configuration is successful.![]()
- Wait for about 10 minutes, choose from the main menu, click the Service tab, and search for CampusAccesscfgService and SouthboundService. Check whether CampusAccesscfgService and SouthboundService are successfully restarted. If the services are running properly, configure other parameters for pushing portal pages to end users.
in the upper right corner to check whether the configuration is successful.
(Optional) Enabling the Port for Outdated Device Certificates
Context
An HTTP/2 channel needs to be established for Portal authentication based on HACA. When establishing an HTTP/2 channel with a device, iMaster NCE-Campus will check whether the actual device certificate is the same as that on itself. If a switch running V200R008C00 or an earlier version is managed, ensure that the port for legacy device certificates is enabled on the management plane.
Procedure
- Log in to the management plane.
- Choose Product > Software Management > Deploy Product Software from the main menu, click More > Modify Configurations, set DEVICE_OLD_CERT_ENABLE(enable device old cert or not) to true, and click OK.
![]()
- Click
![]()
in the upper right corner to check whether the configuration is successful.![]()
- Wait for about 10 minutes, choose from the main menu, click the Service tab, and search for PortalServerService . Check whether PortalServerService is successfully restarted. If the service is running properly, configure other parameters for pushing portal pages to end users.
in the upper right corner to check whether the configuration is successful.
(Optional) Customizing a Portal Page Pushed to End Users
Context
If iMaster NCE-Campus is used as a portal server and you do not want to use the default push pages, you can customize a portal page. iMaster NCE-Campus provides a set of default portal pages for each authentication mode.
When a tenant administrator creates an SSID, the administrator can decide whether to push an authentication page to end users, set the page push mode, and set the end user login mode. In addition, a tenant administrator can configure a portal page pushing policy to determine which portal page is pushed to end users when the users log in via different modes.
The privacy statement for end users is displayed on the user notice page pushed to end users. Customize portal pages based on actual usage and purpose.
If default portal pages do not satisfy your requirements, you can customize a push page in either of the following ways as a tenant administrator:
- Customization based on a built-in template:
In this mode, you need to download a built-in template, customize a portal page, and upload the page. For example, you can modify the content displayed on the pages, supported languages, push protocols, and background images.
The language of a portal page customized based on a built-in template can be Chinese or English. If you want to support more languages, customize portal pages based on a user-defined template.
- Customization based on a user-defined template:
By this way, you can have more space to play. For example, you can customize portal pages in more languages, design the page layout, and configure the content and text layout.
The language that a push page uses can be Chinese, English, German, or Spanish. On the Language Template tab page, you can choose to configure a portal page in one language, and then configure the content to be displayed on different pages.
Importing a Customized Page Using a Template
Procedure
- Choose from the main menu.
- Click
![]()
on the left of the page. In the displayed window, download the template set.![]()
- Select the template of the target type from the template set, customize a page using the selected template, and upload the new page.
When customizing the page content, select a proper template according to Preferred page type and Language. When you upload a template, ensure that the values of Preferred page type and Language are the same as those of the selected template. The built-in template supports only the .zip package, and the package size cannot exceed 4 MB. The file content is UTF-8. The .zip package supports the following file formats: png, css, js, and html. Before uploading a template, ensure that virus scanning has been performed on the compressed package and verify that all files in the package are valid, for example, verify the file name, format extension, and file size, and check whether the files contain XSS attacks.
For details about the files in the template set, functions of the files, and customization methods, see the Help information in the downloaded .zip package.
on the left of the page. In the displayed window, download the template set.
Customizing a Portal Page
Context
After a custom portal page template is created, you can add, modify, or delete a control to customize the page style.
There are many limitations when you customize a portal page based on a built-in template, for example, the portal page layout cannot be modified. Therefore, if the page layout needs to be customized or a large number of multimedia elements and images need to be used, portal pages customized based on a built-in template cannot meet users' requirements.
However, on custom portal pages, you can configure such elements using multiple page controls embedded in iMaster NCE-Campus and customize the content and style of the page controls. If some controls cannot meet requirements, you can edit the controls through the HTML customized editing function provided by iMaster NCE-Campus.
Procedure
- Choose from the main menu.
- On the Page Customization tab page, click
![]()
to create a custom portal page template.![]()
- When customizing a portal page, you can add or delete controls, and drag controls vertically to change the positions of the controls on the page. The height of a control can be modified.
![]()
- Configure the control style. For each control, you can set the background image, background color, text alignment mode, border thickness, border radius, border color, and margins (padding and margin).
![]()
- You can customize controls in HTML customized editing mode. The <script></script> tag is not supported in HTML customized editing.
![]()
- After a page is customized, click Save and Release.
to create a custom portal page template.
Common Control
After a user-defined portal page template is created, you can adjust the controls displayed on portal pages, for example, add, modify, or delete a control, to adjust the page style.
iMaster NCE-Campus provides common controls and page controls based on application scenarios. Common controls can be used on all portal pages, and there is no limit on the number of common controls used on each page. Page controls can only be used on the page to which each page control belongs.
Generally, each time you select a control in Component area, the control is automatically displayed in the page preview, locating at the bottom of the previously configured controls. The control will not display in the page preview only if the page does not support the selected control, or a control of the same type as the selected control has been added on the page (for example, the page background control).
- Title control
Generally, a page title is located at the top of the page, and describes the page function. It is defined by a title control. The text content, font, font size, font weight, italic or not, background, and alignment mode can be customized. A title can contain a maximum of 65535 characters.
- Image control
An image control is used to add images to pages. You can upload new images and use the images that have been uploaded. A maximum of 20 images can be uploaded on a single portal page. The size of an image cannot exceed 1 MB and the size of all images cannot exceed 4 MB. Images in JPG, PNG, JPEG, BMP, and GIF formats can be uploaded. You can set image links, set the width and height of an image in percentage, and delete an image that has been uploaded.
- Text control
A text control is used to provide information that guide users to perform operations. This control can be edited in a similar way as a title control.
- Carousel control
A carousel control is used to add scrolling images to pages. A maximum of five images can be added. You can set the play time of each image and play multiple images in cyclic mode. In addition, you can configure a link on each image, which helps redirect to the corresponding page.
- Dial-up control
A dial-up control is used to add phone numbers to pages. Customized prompt information, icons, and phone numbers are supported. A phone number can be a string of 10 to 24 characters, including digits, plus signs (+), minus signs (-), and spaces.
- Video control
A video control is used to add videos to pages by specifying URLs.
![]()
If the certificate trusted by the browser is not loaded to the video playback source, the video may fail to be played. You are advised to use the playback source whose security certificate has been loaded.
- Background control
A background control is used to set the background of a portal page. You can set a background color or background image. If both a background image and color are configured, the background image applies. The background style cannot be customized through a background control.
- Language control
A language control is used to change the language in which a portal page is displayed. Using this control, you can customize the language link text, and the portal page to be redirected. You can set a maximum of five language links using one language control.
![]()
The language links specified in a language control must be the portal pages that have been launched. For details about how to customize and launch a portal page, see Example for Portal Page Customization.
- Boarding control
A boarding control is used to customize the boarding function on a pushed portal page. It allows users to click the link available on the page to download the boarding client.
Page Control
Eight types of portal pages are supported on iMaster NCE-Campus: user authentication page, authentication success page, user notice page, user registration page, registration success page, password change page, user name verification page, and password reset page. The pages have different controls because they provide different functions. The following controls are supported on these portal pages:
- Controls on a user authentication page
A user enters information on the authentication page and sends an authentication request to the authentication server. iMaster NCE-Campus provides twelve types of authentication controls based on the supported authentication modes:
- User name and password authentication control: You can customize whether to add the links for user notice, user registration and password retrieval on the user authentication page. The button labels, control styles, and placeholders of text boxes can be customized as well.
- SMS authentication control: You can customize whether to add the link for user notice and verification code on the user authentication page. The button labels and placeholders of text boxes can be customized as well.
- WeChat authentication control: You can customize whether to add the link for user notice on the user authentication page. The text, style, and image of the authentication button can be customized.
- Anonymous authentication control: You can customize whether to add the link for user notice on the user authentication page. The text, style, and image of the authentication button can be customized.
- Social media authentication control: The default authentication mode is configurable. You can customize whether to display the user notice portlet on the authentication page and which social media accounts can be used for authentication, such as QQ and Twitter.
- Passcode authentication control: You can customize whether to display the user notice on the passcode authentication page. The text, style, and image of the authentication button can be customized as well.
- Multi-mode authentication control: You can configure multiple authentication methods together using this control. For example, the user name and password authentication, SMS authentication, passcode authentication, and Facebook authentication can be used together.
Facebook authentication supports only the HTTPS protocol. When configuring multi-mode authentication, check whether the protocol of the portal page can be supported by Facebook. The placeholders of text boxes and button style can be customized.
- The Username and SMS authentication control: You can determine whether to display user notice and registration portlets on the authentication page. The button labels, control styles, and placeholders of text boxes can be customized as well.
- 2FA authentication control: You can determine whether to display user notice and registration portlets on the authentication page. The button labels, placeholders of text boxes, and the style of the login button can be customized as well.
- The 2FA (AD + RSA) authentication control: You can determine whether to display user notice, registration, and forget password portlets on the authentication page. The button labels, placeholders of text boxes, and the style of the login button can be customized as well.
- Public QR code: You can edit the button text and theme.
- Controls on an authentication success page
Users will be redirected to an authentication success page after successful authentication. The page displays the authentication result and allows users to log out or change their passwords. There are two controls available on this page: authentication success information and authentication success message.
- Authentication success information: On an authentication success page, information including the username, remaining traffic, remaining time, expiration time mobile number binding, change password, logout button, and self-service can be customized.
- Authentication success message: This control defines a message indicating that user authentication succeeds.
- Portal list 1: This control provides the function of editing the portal page.
- Portal list 2: This control provides the function of editing the portal page.
- Portal list 3: This control provides the function of editing the portal page.
- Portal in a single line: This control provides the function of editing the portal page.
- Portal double column: This control provides the function of editing the portal page.
![]()
Users are allowed to upload customized HTML pages. After a user is successfully authenticated, the user can go to the customized portal page from the authentication success page. The administrator needs to choose , click Upload, upload the portal page, and add the portal control of the specified style as required.
- Full screen advertisement page
Only the banner countdown or video countdown can be set on the full-screen advertisement page. For banner countdown, you can specify the countdown time, countdown prompt information, merchant prompt information, and play time of a single image. A maximum of five images can be selected. For video countdown, you can set the countdown time and the video URL.
![]()
If the certificate trusted by the browser is not loaded to the video playback source, the video may fail to be played. You are advised to use the playback source whose security certificate has been loaded.
- Controls on a user notice page
On the user notice page, rules and information that users need to be aware of when they attempt to connect to the Wi-Fi network are displayed.
- User notice control: This control allows you to edit a user notice.
- Agree control: After a user clicks the agree button, the login page is displayed.
- MDM register control: This control redirects users to the MDM server to register terminals.
- Control on a user registration page
On a user registration page, a user can register an account for authentication. User registration is supported only in username and password authentication and universal self-registration authentication.
- User registration control: The button labels, control styles, and placeholders of text boxes can be customized.
- Control on a registration success page
- Registration success control: You can customize the style of the buttons and controls that are used to redirect users to the user authentication page.
- Control on a password change page
- Password change control: The button labels, control styles, and placeholders of text boxes can be customized.
- Control on a user name verification page
- User name verification control: The button labels, control styles, and placeholders of text boxes can be customized.
- Control on a password reset page
- Password reset control: The button labels, control styles, and placeholders of text boxes can be customized.
Configuring a Language Template
Context
You can customize the title, button labels, and text boxes on a portal page using a language template, and customize portal pages in different languages using different language templates. By default, iMaster NCE-Campus provides four language templates: Chinese, English, German, and Spanish. If the default language templates do not satisfy your requirements, you can create a language template as needed.
Procedure
- Choose from the main menu.
- Click the Language Template tab, and click Create. When creating a language template, you can either manually create one or import one.
- Manual creation: On the web UI of iMaster NCE-Campus, customize the content displayed in all areas on each page.
- Import: Download a sample Excel template from iMaster NCE-Campus. Then, edit the template, and upload the edited template to iMaster NCE-Campus.
![]()
The following figure uses an authentication page as an example. It shows the mapping between controls on the authentication page and fields specified in a language template.
![]()
Example for Portal Page Customization
This section describes how to customize a portal page for user name and password authentication.
Procedure
- Choose from the main menu.
- On the Page Customization tab page, click
![]()
to customize a portal page for user name and password authentication. - Set the page name, language template, access protocol, and system template.
For example, set the page name to username, System template to User Name and Password Template, Language template to English default template, and Access protocol to HTTPS.
- A default template for authentication page customization is provided for each authentication mode. Currently, 10 default templates are available, including the templates for username and password authentication, generic authentication, anonymous authentication, SMS authentication, social media authentication, one-click WeChat portal authentication, passcode authentication, one-click authentication, URL-based WeChat authentication, and public QR code authentication.
- The language template defines the default language of the portal page. For example, if you select an English template, the texts of all controls are displayed in English.
- Access the editing page of the created portal page.
![]()
- Select a page, for example, a user authentication page, and edit controls one by one.
- During the editing, you can click Save to save the settings temporarily.
The settings will be saved to the server. In this step, the page is still a draft and cannot be used as an official user authentication page.
- After customizing the portal page for mobile phones, click Customize PC Page on the upper part of the page to customize a portal page for PCs.
You can customize different portal pages for PCs and mobile phones on iMaster NCE-Campus.
![]()
![]()
The authentication modes configured on portal pages for PCs and for mobile phones must be the same. Otherwise, the authentication on one page will fail.
- After customizing portal pages for PCs and for mobile phones, click Release in the upper right corner.
After the pages are successfully launched, the portal page list is displayed.
![]()
![]()
After the configuration is complete, you can only modify the style of this page, but cannot modify the authentication mode which has been specified for the page.
- Select a page from the portal page list to preview the selected page. Both the portal pages for PCs and for mobile phones can be previewed.
The following figure is the preview of a portal page for mobile phones.
![]()
The following figure is the preview of a portal page for PCs.
![]()
If the pages meet your requirements, you can then set the pages as user authentication pages, configure portal page push policies, and bind an SSID and a portal page push policy to each page.
to customize a portal page for user name and password authentication.
Configuring a Portal Page Pushing Policy
If iMaster NCE-Campus is used as a portal server, you need to configure portal page pushing policies. iMaster NCE-Campus pushes a specified portal page to end users based on portal page pushing policies.
Context
iMaster NCE-Campus provides default pages of various authentication modes, such as the authentication page and authentication success page. Tenant administrators can configure portal page pushing rules to determine the portal pages to be pushed to end users. If the default pages do not meet the requirements, you can customize pages as needed.
If multiple portal page pushing rules are configured, the portal page pushing policy with the smallest priority value has the highest priority. If the high-priority portal page pushing rule is matched, other policies are not matched.
Procedure
- Choose from the main menu.
- Click Create to create a portal page pushing policy.
Parameter Description
Parameter |
Description |
|---|---|
Push Rule |
Push condition. A specified page is pushed for the portal authentication request that meets the pushing condition. If all the pushing conditions are not set, a portal page is pushed to all devices at the selected site. If multiple conditions are set, portal authentication requests match portal page pushing rules when they met all the conditions. |
Authentication mode |
Authentication mode. The portal page to be pushed is selected based on the authentication mode. During page customization, different login modes require different page elements. |
Push page |
Portal page to be pushed. The portal page to be pushed is selected based on the authentication mode. When the default pushed page of the system cannot meet the requirement, you can customize a portal page as prompted. Each set of portal pages to be pushed contains an authentication page, user notice page, and registration page. A tenant administrator can specify one of them as the first page to be pushed. |
First page to push |
Portal page to be pushed to users upon first login. The options are as follows:
|
Page displayed after successful authentication |
Page displayed after a user is authenticated.
NOTE:
In the UC browser of the HD type, the redirected URL can only be an HTTP URL. If Push mode is set to Fast for the desired portal page when you configure an authentication point, end users cannot be redirected to a specified URL.
|
(Optional) Configuring an Online User Control Policy
You can configure a policy to limit the online duration or traffic usage of end users. In this case, end users will be forced offline when they reach the online duration or traffic limit. Such policies are required if end users need to be charged.
Context
In some public areas, the online duration or traffic usage of guests needs to be limited. For example, each user can be online for at most one hour a day or is allowed to consume a maximum of 500 MB data. If any of the limits is reached, the user is forced offline.
The policies for limiting the online duration or traffic usage take effect only when iMaster NCE-Campus functions as a portal server or RADIUS server. These policies take effect in HACA authentication, Portal 2.0 authentication, 802.1X authentication, and MAC address authentication. However, such policies do not take effect in the following scenarios: without authentication, username and password authentication, third-party portal server authentication, or third-party RADIUS server authentication.
This configuration is not required if firewalls function as authentication points.
End users who go online using auto-identified terminals and auto-admitted terminals are not added to any user group. Therefore, such policies cannot be configured for these users based on user groups.
Procedure
- Choose from the main menu.
- Click the Traffic and Duration Policy tab. Then, click Create and configure an online user control policy for limiting the online duration and traffic usage of users.
![]()
- (Optional) Choose from the main menu.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
![]()
- After the parameters are set, click
![]()
to apply the created user control policy to a specific user group or user.![]()
![]()
- When creating a user, you can also set the maximum number of access terminals. The maximum number of access terminals configured on different pages takes effect in the following sequence in descending order: Maximum number of access terminals when a user is created > Number of access terminals allocated to the user > Number of access terminals allocated to the user group. If the Maximum number of terminals parameter is disabled when a user is created, the maximum number of access terminals is subject to the configuration in the user control policy. If the Maximum number of terminals parameter is enabled and no restrictions is selected, there will be no limit on the number of access terminals. Users passing MAC address authentication are not restricted by this configuration. If a user group is configured, each user in the user group supports the maximum number of access terminals.
- When an authentication component is remotely deployed, the maximum number of access terminals supported on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
Follow-up Procedure
- Choose from the main menu to view online users. You can forcibly log out users and update Change-of-Authorization (CoA), as well as export online user data. Click
![]()
to set the type of the attribute value displayed for an online user. You can select Force users offline or Force users offline and disable the port to forcibly log out users, and select Re-authentication or Intermittent port disconnection to update user authorization through CoA packets. If re-authentication is triggered, the user who has been forced offline will go online again after being re-authenticated. If you alternate the port to which the user connects between Up and Down, the user will go offline when the port is Down and will be re-authenticated and go online again after the port is Up.![]()
When you click Log Out, selected users are forced offline. If you click Log Out And Disable The Port, selected users are forced offline and the authentication ports to which the users are connected are disabled. When performing this operation, ensure that only one user is connected to each port. Otherwise, other irrelevant users will be forced offline as well.
Port flapping and port disabling are not supported when wireless authentication, HACA Portal authentication, policy association, or an Eth-Trunk is configured. In Portal 2.0 authentication scenarios, you can alternate the port to which a user connects between Up and Down. However, in this case, users cannot go online again after being forced offline.
Re-authentication is not supported in portal authentication scenarios.
CoA update is not supported by access users passing device administrator authentication.
- Choose from the main menu to view the online duration or traffic usage limits of users or terminals. You can reset the limits as needed. By default, the username, terminal IP address, and terminal MAC address are masked. If you need to view the information, disable terminal data masking on the Configuring a Terminal Privacy Policy page.
![]()
When an authentication component is remotely deployed, the online duration statistics on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
to set the type of the attribute value displayed for an online user. You can select Force users offline or Force users offline and disable the port to forcibly log out users, and select Re-authentication or Intermittent port disconnection to update user authorization through CoA packets. If re-authentication is triggered, the user who has been forced offline will go online again after being re-authenticated. If you alternate the port to which the user connects between Up and Down, the user will go offline when the port is Down and will be re-authenticated and go online again after the port is Up.Parameter Description
Parameter |
Description |
|---|---|
Max. Number Of Terminals |
|
Allocate to User Groups/Users |
Apply the created user control policy to a specific user groups or users. |
Parameter |
Description |
|---|---|
site |
Site where the online user control policy takes effect. If Site Information Matching is disabled in an online user control policy, this policy takes effect at all sites under the tenant. In such cases, user's traffic usage or online duration is controlled on a per-site basis. |
User Level/Terminal Level |
Whether to configure an online user control policy on a per-user basis or on a per-terminal basis. The following two types of policies are available on each basis.
NOTE:
The amount of available user traffic and online duration are restricted based on the accounting request packets sent by devices. Since devices send accounting request packets periodically, there may be differences between the configured amount of available user traffic or online duration and that in actual situations. Assume that: 1. The interval for sending accounting request packets is set to 5 minutes in SSID configuration whereas the interval is set to 10 minutes in online duration control policy configuration. 2. A user or terminal initiates portal authentication at the beginning of the fourth minute in an accounting period. In this scenario, when a device sends accounting request packets for the first time and the second time, the available online duration of the user is not used up. Therefore, the user or terminal can continue to access the network. When the device sends an accounting request packet for the third time, the system determines that the online duration of the user or terminal exceeds the upper limit, and then restricts the network access of the user or terminal. In this case, the actual online duration of the user or terminal is 12 minutes, rather than 10 minutes specified in the online control policy. If both traffic-based control and duration-based control are enabled, re-authentication is triggered when either of the conditions is met. Reset traffic and duration:
|
Allocate User Group |
Click |
and select a user group. The traffic- or duration-based control policies take effect only for users in this user group.(Optional) Configuring a Portal Server Template
Context
To simplify configuration and facilitate unified management, iMaster NCE-Campus encapsulates authentication parameters into a template. When configuring related services, you can use configure a template as needed and deliver the parameter values in this template to the target objects.
When Portal 2.0 is configured on authentication devices, you need to configure a Portal server template and enable the built-in Portal server in this template.
Procedure
- Choose from the main menu, and select Portal Server.
- Click Create, set parameters, and click OK.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Name |
Unique identifier of the portal server template. |
Using Built-in Server |
Specify iMaster NCE-Campus as the portal server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the authentication component. The SM is the controller deployed at the headquarters. The default protocol for pushing portal pages is HTTPS. To use HTTP, enable the HTTP port. |
IP address |
IP address of a third-party portal server. Use commas (,) to separate multiple IP addresses. |
Port |
Port of a third-party portal server. |
URL |
Interface URL of a third-party portal server. |
Portal user synchronization |
Whether to synchronize user information between devices and iMaster NCE-Campus. You can enable this function when Portal 2.0 authentication is configured. The synchronization interval and maximum allowable number of synchronization failures can be set. The synchronization interval is in the range from 30 to 65535, in seconds, and its default value is 300. The maximum allowable number of synchronization failures is in the range from 2 to 255 and its default value is 3. The synchronization interval multiplied by the maximum allowable number of synchronization failures must be greater than the interval at which the portal server sends synchronization packets to devices. Otherwise, devices will log out users if they do not receive any synchronization packet from the portal server after the maximum allowable number of synchronization failures is reached. The built-in portal server of iMaster NCE-Campus sends synchronization packets at an interval of 3600 seconds. |
Key |
Shared key of a portal server. |
URL parameter profile |
URL template (with related parameters specified) associated with a portal server. If an SSID is associated with a Portal server template, the SSID is also associated with this URL template. |
(Optional) Configuring a RADIUS Server Template
Context
To simplify configuration and facilitate unified management, iMaster NCE-Campus encapsulates authentication parameters into a template. When configuring related services, you can use configure a template as needed and deliver the parameter values in this template to the target objects.
When Portal 2.0 is configured on authentication devices, you need to configure a RADIUS server template and enable the built-in RADIUS server in this template.
Procedure
- Choose from the main menu, and select RADIUS Server.
- Click Create, set parameters, and click OK.
![]()
- When configuring an SSID for authentication based on a RADIUS server, you can select this template to specify the RADIUS server associated with the SSID. For details, see Configuring an SSID.
- Only APs running V200R008C10 and later versions support the Disable RADIUS attributes parameter. The RADIUS attributes supported vary with the AP model. If this parameter is configured in the selected RADIUS template, ensure that the model and version of the target AP meet requirements. Otherwise, the SSID-related service configuration will fail to be delivered. To view RADIUS attributes supported by a device, run the display radius-attribute command in the system view of the device.
- Only APs running V200R009C00 and later versions support the Set called-station-id attribute value parameter.
- Only APs running V200R008C00 and later versions support the Real-time accounting parameter.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS server template. |
|
Using Built-in Server |
Whether to configure iMaster NCE-Campus as a RADIUS server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
|
Authentication server |
Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight authentication servers can be added. |
|
Accounting server |
Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight accounting servers can be added. |
|
Authentication component |
This parameter needs to be set only when Using Built-in Server is enabled. The authentication component can be the Service Manager (SM) or a remote server. The SM is the headquarters controller. |
|
Server selection policy |
|
|
Server selection algorithm |
|
|
Real-time accounting |
Whether to enable real-time accounting. After this function is enabled, you can configure a real-time accounting interval. By default, this function is disabled. |
|
Billing reporting cycle |
Real-time accounting interval. |
|
Key |
Shared key of the RADIUS server. You are advised to periodically change the shared key. |
|
Disable RADIUS attributes |
Whether to filter specific attributes in the packets exchanged between the device and the RADIUS server. The default value is OFF, indicating that specific attributes are not filtered. |
|
Disable attributes |
- |
Click Create and configure a filtering policy. |
Attribute name |
Click ... and select the names of attributes to be filtered in the displayed dialog box. |
|
Prohibit Sending |
The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server. |
|
Prohibit Receiving |
The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server. |
|
Service-Type |
- |
The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server. |
Attribute value |
Specifies the value of service-type attribute to be modified. |
|
Option |
Sets the user authentication mode to MAC address authentication. |
|
called-station-id |
- |
After this function is enabled, you can set the called-station-id attribute value, which specifies content encapsulated in the called-station-id attribute of RADIUS packets. Currently, only APs support this function. By default, this function is disabled. |
Attribute value |
Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location. |
|
Carry SSID attributes |
After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled. |
|
Attribute separator |
Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains the SSID. The value is of enumerated type, and can be \, /, :, <, >, |, @, ', %, *, +, -, &, !, #, ^, and ~. The default value is :. |
|
Mac address format setting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
Server status auto-detection |
Username |
Username for automatic RADIUS server detection. |
Password |
Password for automatic RADIUS server detection. |
|
Retransmit authentication requests |
Retransmission count |
Number of retransmission times if an authentication request times out. |
Timeout interval |
Timeout interval of an authentication request. |
|
Server down duration |
Period during which the authentication server remains Down. |
|
Configuring an Authentication Point
Context
After authentication and authorization rules are configured, you need to configure an authentication mode on authentication points. For example, when configuring an SSID on an AP, you need to specify an authentication mode to implement access control on wireless access users. Only one authentication mode can be specified for each SSID. Therefore, the authentication mode for an access user is determined by the SSID selected when the user accesses the Internet. However, multiple SSIDs can be deployed on one AP. Employees and guests access the Internet using different SSIDs and different authentication modes.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Open network, Push pages to ON, Page pusher to Built-in authentication by cloud platform, and Push mode to Advanced. Set Login mode to the actual login mode configured on the network. Currently, iMaster NCE-Campus supports the following authentication modes: anonymous authentication, username and password authentication, SMS authentication, URL-based WeChat authentication, one-click WeChat portal authentication, Facebook authentication, Twitter authentication, Sina Weibo authentication, QQ authentication, passcode authentication, one-click authentication, and public QR code authentication.
- Set the portal protocol. Currently, HACA and Portal 2.0 are supported. If you set the protocol to Portal 2.0, enable the built-in portal server and RADIUS server in the portal template and RADIUS template, respectively. The Portal 2.0 protocol is a Huawei proprietary protocol. Currently, only CHAP is supported in Portal 2.0. Portal 2.0 is not supported in Huawei public cloud scenarios.
- (Optional) If HACA is used, configure the protocol for pushing portal pages to end users. By default, HTTPS is used. If HTTP is required, enable the HTTP port. For details, see (Optional) Enabling the HTTP Port.
- (Optional) If users need to access an authentication server through its domain name, add the IP address of the DNS server to the default permit rule.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
AR
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security authentication page, set Authentication mode to OPEN, Push pages (Portal authentication) to ON, Push mode to Advanced. Set Login mode to the actual login mode configured on the network. Currently, iMaster NCE-Campus supports the following authentication modes: username and password authentication, SMS authentication, anonymous authentication, URL-based WeChat authentication, one-click WeChat portal authentication, Facebook authentication, passcode authentication, one-click authentication, and public QR code authentication.
- (Optional) If HACA is used, configure the protocol for pushing portal pages to end users. By default, HTTPS is used. If HTTP is required, enable the HTTP port. For details, see (Optional) Enabling the HTTP Port.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
Firewall
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- Set the Page pusher to Authentication built in controller, and select the actual login mode configured on the network. Currently, iMaster NCE-Campus supports the following authentication modes: anonymous authentication, username and password authentication, SMS authentication, Facebook authentication, Twitter authentication, Sina Weibo authentication, QQ authentication, passcode authentication, one-click authentication, and public QR code authentication.
If Push page based on source IP address is configured, iMaster NCE-Campus pushes portal pages to the terminals whose IP addresses are in the source IP address list, but not other terminals.
- Set the portal protocol. Currently, HACA and Portal 2.0 are supported. If you set the protocol to Portal 2.0, enable the built-in portal server and RADIUS server in the portal template and RADIUS template, respectively. The Portal 2.0 protocol is a Huawei proprietary protocol. Currently, only CHAP is supported in Portal 2.0. Portal 2.0 is not supported in Huawei public cloud scenarios.
- (Optional) If HACA is used, configure the protocol for pushing portal pages to end users. By default, HTTPS is used. If HTTP is required, enable the HTTP port. For details, see (Optional) Enabling the HTTP Port.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
NOTE:A firewall also supports built-in portal anonymous authentication. To use this function, set Page pusher to Authentication built in firewall, and set Redirection page after successful authentication and Idle timeout period.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- Set Authentication mode to Open network, Page pusher to Built-in authentication by cloud platform, Push mode to Advanced, and Authentication Policy to the actual login mode configured on the network. Currently, iMaster NCE-Campus supports the following authentication modes: anonymous authentication, username and password authentication, SMS authentication, URL-based WeChat authentication, one-click WeChat portal authentication, Facebook authentication, Twitter authentication, Sina Weibo authentication, QQ authentication, passcode authentication, one-click authentication, and public QR code authentication.
- Set the portal protocol. Currently, HACA and Portal 2.0 are supported. If you set the protocol to Portal 2.0, enable the built-in portal server and RADIUS server in the portal template and RADIUS template, respectively. The Portal 2.0 protocol is a Huawei proprietary protocol. Currently, only CHAP is supported in Portal 2.0. Portal 2.0 is not supported in Huawei public cloud scenarios.
- (Optional) If HACA is used, configure the protocol for pushing portal pages to end users. By default, HTTPS is used. If HTTP is required, enable the HTTP port. For details, see (Optional) Enabling the HTTP Port.
- (Optional) If the terminal to be authenticated uses the IPv6 protocol, enable IPv6 terminal authentication and set an IPv6 URL for the page pushed by the portal server. In such cases, IPv4 URLs are not supported.
- (Optional) If users need to access an authentication server through its domain name, add the IP address of the DNS server to the default permit rule.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
- (Optional) In a wired authentication scenario of a switch, click the Authentication Device Global Configuration tab, and enable MAC address migration and Detection before MAC address migration.
After a user is authenticated and accesses the network from one port on a switch, the user removes the network cable from the port and inserts in another port on the switch. In this case, the user cannot immediately initiate authentication and access the network. The user can initiate authentication on the current port only after the user offline detection interval expires or the authentication port is manually enabled and shut down to clear user online entries. To improve user experience, MAC address migration can be enabled so that the user can immediately initiate authentication and access the network after being switched to another access port.
MAC address migration allows online NAC authentication users to immediately initiate authentication and access the network after connecting to other access ports. If the user is authenticated successfully on the new port, the online user entry on the original port is deleted immediately to ensure that the online user entry is recorded on only one port. To prevent unauthorized users from spoofing online users to attack a device, you can set Detection before MAC address migration.
NOTE:Wireless authentication needs to be configured in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
WAC
- Choose from the navigation pane. Click add and configure authentication.
- Set Authentication mode to Open network, Page pusher to Built-in authentication by cloud platform, Push mode to Advanced, and Authentication Policy to the actual login mode configured on the network. Currently, iMaster NCE-Campus supports the following authentication modes: anonymous authentication, username and password authentication, SMS authentication, URL-based WeChat authentication, One-click WeChat portal authentication, Facebook authentication, Twitter authentication, Sina Weibo authentication, QQ authentication, passcode authentication, one-click authentication, and public QR code authentication.
- Set the portal protocol. Currently, HACA and Portal 2.0 are supported. If you set the protocol to Portal 2.0, enable the built-in portal server and RADIUS server in the portal template and RADIUS template, respectively. The Portal 2.0 protocol is a Huawei proprietary protocol. Currently, only CHAP is supported in Portal 2.0. Portal 2.0 is not supported in Huawei public cloud scenarios.
- (Optional) If HACA is used, configure the protocol for pushing portal pages to end users. By default, HTTPS is used. If HTTP is required, enable the HTTP port. For details, see (Optional) Enabling the HTTP Port.
NOTE:Configurations of WACs need to be performed in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
![]()
When iMaster NCE-Campus functions as a portal server, you can select an existing portal page and set parameters based on the authentication mode on the page if Push mode is set to Fast.
Configuring an Authentication Rule
Context
Currently, iMaster NCE-Campus supports two portal protocols: HACA and Portal 2.0. The Portal 2.0 protocol is a Huawei proprietary protocol and is supported only in non-NAT private cloud scenarios.
Currently, only Challenge-Handshake Authentication Protocol (CHAP) is supported in the Portal 2.0 protocol. If CHAP is used, passwords are stored in the Chap-Password attribute, and an index value instead of a password is transmitted over the network, which improves security. However, the RADIUS server must know user passwords so that it can calculate password index values and compare them with those carried in authentication requests. The algorithm for password encryption in the Chap-Password attribute is MD5 (chapId + password + chapChallenge).
If the HACA protocol is used, set the authentication mode to User Access Authentication and enable the Portal-HACA protocol. If the Portal 2.0 protocol is used, set the authentication mode to User Access Authentication.
iMaster NCE-Campus provides a default authentication rule default that uses a local data source for authentication. The default template can be modified to use a third-party data source for authentication.
Procedure
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to user access authentication. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authentication rule if the authentication rule defines user authentication based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authentication rule
The priority value of the first authentication rule is 1 and the priority values of subsequent authentication rules increase by 1. The smaller the priority value, the higher the priority. The default authentication rule has the lowest priority. You can set the priority of an authentication rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time information |
User authentication based on time ranges. |
|
Authentication Information |
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
|
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, firewall, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. Currently, two methods are available: two-factor authentication using accounts and SMS verification code or RADIUS tokens, and two-factor authentication using SSL VPN-enabled firewalls. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. The RADIUS token factor is supported only when the two-factor authentication method is used. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
PAP must be enabled when LDAP accounts are used for Portal 2.0 authentication, FW SSL VPN authentication, and MAC address authentication. In addition, CHAP must be enabled for Portal 2.0 authentication. If iMaster NCE-Campus functions as an authentication server in other services, enable the required protocol. One of the EAP-MD5, EAP-PEAP-MSCHAPv2, EAP-TLS, EAP-PEAP-GTC, and EAP-TTLS-PAP protocols can be specified as the preferential protocol used for authentication. This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
User authentication based on user groups to which MAC accounts are mapped. |
MAC account |
User authentication based on MAC accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows: PAP protocol (local account, AD, LDAP, RADIUS Token, Third-party HTTP server, Third-party Database) CHAP protocol(Local account, Third-party Database) |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Admission device group |
User authentication based on access device groups. |
|
Terminal IP range |
User authentication based on terminal IP addresses. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Device IP address, access VLAN, access port, user MAC address, user IP address, user IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Configuring an Authorization Result
Context
When you configure portal authentication, 802.1X authentication, and MAC address authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
When you configure device administrator authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
iMaster NCE-Campus provides two default authorization results: Permit Access and Deny Access. The two results are bound to all sites to form default templates, which cannot be modified or deleted.
The rights assigned to an authenticated end user are specified by an authorization result. The permissions involve the destination IP address, protocol, and port defined by an ACL, URL permitted or rejected, and uplink or downlink bandwidth of terminals.
SSID-based policy control indicates that the STA connected to an SSID has the corresponding rights. The set of rights specified in an authorization result is dynamically authorized according to the matching policy after an end user is authenticated. The rights assigned to an end user include those specified both in an SSID and an authorization result.
Procedure
- Choose from the main menu.
- Click Create to create an authorization result. Parameters in an authorization result vary with the device type. For details about the parameters, see Parameter Description at the end of this section.
![]()
- Click OK to bind the authorization result to sites. You can also select an authorization result, click
![]()
, and select desired sites to bind them to the result.![]()
, and select desired sites to bind them to the result.
Parameter Description
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring an Authorization Rule
When iMaster NCE-Campus authorizes authenticated users, it grants specific permissions only to the users who hit the specified authorization rules.
iMaster NCE-Campus provides a default authorization rule default with the authorization result Deny Access. You can modify the authorization result in this default template as required.
Context
Authorization results define the rights assigned to authenticated end users. Each authentication rule corresponds to an authentication result. If an authenticated end user matches an authentication rule, the corresponding authorization result applies to the user. If no authorization rule is set, an authorization result is applicable to all authenticated terminals.
Procedure
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to user access authentication. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authorization rule if the authorization rule defines user authorization based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authorization rule
The priority value of the first authorization rule is 1 and the priority values of subsequent authorization rules increase by 1. The smaller the priority value, the higher the priority. The default authorization rule has the lowest priority. You can set the priority of an authorization rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server belongs to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on accounts. |
||
Role Information |
Authenticated users are authorized based on roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. |
||
Region |
Authenticated users are authorized based on regions. |
||
Protocol Information |
Enable protocol matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported:
|
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, and FW. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on regions. |
||
Region |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Protocol Information |
Enable protocol information matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported: EEAP-MD5 protocol (Local account) EAP-PEAP-MSCHAPv2 protocol (Local account, AD, and LDAP) EAP-TLS protocol (Local account, AD, LDAP) EAP-PEAP-GTC protocol (Local account, AD, LDAP, and RADIUS Token) EAP-TTLS-PAP protocol (Local account, AD, and LDAP) |
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
The Authentication Terminal Has Been Added to the AD Domain |
Whether authenticated users using terminals that have been added to AD domains have been authorized. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, and WAC. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Region |
Authenticated users are authorized based on regions. |
||
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
Admission Device Group |
Authenticated users are authorized based on access device groups. |
|
Region |
Authenticated users are authorized based on regions. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Multi-Network Portal Authentication
Context
Multiple networks on a campus are isolated from each other. Most users can access only one network, and a few users can access multiple networks at the same time. In this case, you can configure multi-network portal authentication to allow authenticated end users to access multiple networks without re-authentication. This function is supported only when switches functions as authentication points in wired authentication scenarios.
Procedure
- Choose from the main menu. Click Create to create a role. Alternatively, click Import to import multiple roles in batches using an Excel template.
![]()
- Choose from the main menu, click the Advanced Parameter tab, and click Create in the Configuring Portal Authentication for Multiple Networks area.
![]()
- Customize a portal page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a user-defined template. In this example, select User Name and Password Template as the system template.![]()
- In the page editing area, select the authentication page, select the user name and password control, select Multiple networks, and specify the network type. After the configuration is complete, click Save and then Release. If accounts used to access different networks need to be distinguished, enable Network suffix is used as the account part so that the controller will add network suffixes to account names.
![]()
- Configure an authorization result for each of the network types. For example, if network 1 and network 2 are defined and users need to be granted with different permissions when they access the networks, configure authorization result 1 for users who access network 1 and authorization result 2 for users who access network 2. Configure Portal server redirection or Redirect URL in an authorization result. Portal server redirection redirects users to the authentication success page when they connect to another network using the same account. For details about other parameter settings, see Configuring an Authorization Result.
- Configure an authentication rule and an authorization rule for each of the authorization results. Enable Match roles so that iMaster NCE-Campus matches user roles bound to users in different networks. For details about other authentication and authorization rule parameters, see Configuring an Authentication Rule and Configuring an Authorization Rule.
- Configure an authentication point.
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Choose from the navigation pane. Click the Wired Authentication tab. Click Create and configure wired authentication.
- Set Authentication mode to Open network, Page pusher to Built-in authentication by cloud platform, Push mode to Advanced, and Authentication Policy according to the actual situation.
- Set the portal protocol. Currently, HACA and Portal 2.0 are supported. If you set the protocol to Portal 2.0, enable the built-in portal server and RADIUS server in the portal template and RADIUS template, respectively. The Portal 2.0 protocol is a Huawei proprietary protocol. Currently, only CHAP is supported in Portal 2.0. Portal 2.0 is not supported in Huawei public cloud scenarios.
- When Portal 2.0 is selected, enable Carry URL parameters for redirection after authorization.
- Select a site.
to create a user-defined template. In this example, select User Name and Password Template as the system template.
802.1X Authentication
Configuring a User Group and User
Context
In the enterprise employee access scenario, user name, and password authentication can be used to implement end user access. During portal authentication or 802.1X authentication, end users need to enter the following account information.
Authentication Mode |
Account Type |
Description |
|---|---|---|
User name and password authentication |
User |
A user name and the password are required for authentication, and need to be preconfigured by tenant administrators on iMaster NCE-Campus. Users need to obtain user names and passwords from tenant administrators. NOTE:
iMaster NCE-Campus predefines the ~anonymous account (without a password) for anonymous authentication. This account cannot be deleted or modified. |
Procedure
- Choose from the main menu.
- Click
![]()
to create a user. You can create users one by one.![]()
- Select a user group and click Create to create a user. You can create users one by one.
![]()
When creating a user, you are advised to bind an email address or phone number to the user to facilitate password change.
![]()
- Click
![]()
to import users and user groups. You can use an Excel template to import users and user groups in batches. - Click
![]()
to export users and user groups. After the export task is created, click OK and choose to view and download the task.
- Click
Related Operations
- Advanced Search
You can perform advanced search for user information. The following search items are available. You can select one or more matching items for advanced search.
- Username
- Login type: 802.1X, Portal, HWTACACS
- User status: Effective, Expired, Disable
- Login time
- Used only for mobile certificate authentication
- User-defined field
Click
![]()
, and then click Create to customize the user information required for registration when the administrator creates a user.![]()
- Resetting a user password
Select the user whose password needs to be changed and click
![]()
to reset the user password.![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
User name |
Username and password used by an end user during authentication to connect to a cloud-managed device. |
|
Password |
||
Confirm password |
||
Role |
Role attached to the user. |
|
Email address and phone number of a user. When resetting passwords, a user receives a verification code via an email or an SMS message and sets a new password based on the verification code. |
||
Phone number |
||
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. This parameter does not take effect for HWTACACS authentication access users. |
|
Expiration time |
Time when the user account expires. If this parameter is left empty, the account is valid permanently. |
|
Change password upon next login |
Whether to change the account password upon next login. If this parameter is enabled, users need to change the initial passwords upon next login. This parameter is valid only for portal authentication. This parameter does not take effect for HWTACACS authentication access users. |
|
Login mode |
Portal |
End users are allowed to access networks only through portal authentication. |
802.1X |
End users are allowed to access networks only through 802.1X authentication. |
|
HWTACACS |
End users are allowed to access networks only through HWTACACS authentication. Device administrators can use usernames and passwords configured during the creation to remotely log in to devices for management. |
|
Only mobile certificate authentication is allowed |
After this function is enabled, users can be authenticated only through the EAP-TLS protocol. If the authentication type does not match, the authentication fails. This function can be enabled only when the login mode is set to 802.1X. |
|
RADIUS attribute |
IP address of the access terminal/Subnet Mask |
IP address and mask allocated to a terminal after the terminal is authenticated by the RADIUS server. |
IP address segment of the access terminal |
IP address segment allocated to terminals after successful RADIUS authentication. This parameter applies to the scenario where a gateway functions as a terminal. The gateway allocates IP addresses to connected terminals from this IP address segment through DHCP. |
|
User-defined authorization parameters |
User-defined RADIUS attributes can be configured for terminals. A maximum of 20 user-defined RADIUS attributes can be configured. |
|
Access binding information |
IP address of the bound terminal |
Terminal IP address bound to the user account. |
MAC address of the bound terminal |
Terminal MAC address bound to the user account. The value must be in the format **-**-**-**-**-**, such as 11-11-11-11-11-11. |
|
Bind the ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
IMSI bound to the SIM or USIM card |
International mobile subscriber identity (IMSI) or SIM card number bound to the user account. The value is a string of 1 to 15 digits. IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Binding an Access Device |
IP address of the access device |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
Parameter |
Description |
|---|---|
User group name |
Name of a user group. A user group contains multiple users. When configuring an access control policy, you can specify the user group to which the policy applies. |
(Optional) Attaching a Role to an Account
Context
In addition to user groups, accounts can be managed based on account roles. An account can belong to only one user group but can be attached to multiple roles. Accounts and roles are mapped in a one-to-many manner. Roles can be created manually by an administrator or created automatically during AD/LDAP account synchronization. Roles can be used for authentication, authorization, and security policy allocation.
Procedure
- Choose from the main menu.
- Click Create to create a role.
![]()
- After the role is created, click
![]()
next to the role, and click Add to attach the role to a user account, guest account, or MAC account.![]()
- Click Import to import roles in batches using an Excel template.
- Click Export All to export information about all roles.
- Click Create to create a role.
Setting Basic Parameters
Context
You can specify validity periods for user accounts, as well as retention periods for expired user accounts. As such, expired user accounts can be cleaned up automatically after the specified retention period elapses.
You can also configure a password policy for user accounts.
Procedure
- Choose from the main menu.
- Click the User Password Policy Configuration tab and modify the password policy for user accounts.
The password policy allows you to properly set the complexity of your account password, password updating period, and character limitations to prevent your password from being stolen. iMaster NCE-Campus provides a default password policy which you can modify as required.
![]()
- Click the SMS Verification Code tab, and set SMS verification code length and SMS verification template.
![]()
- Click the Advanced Parameter tab, and set advanced parameters. The following figure only shows some parameters. For details about other parameters, see Parameter Description at the end of this section.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Complexity rule |
Password complexity and password length of a user account. The password complexity requirements are as follows:
|
Length range |
|
Validity period |
Password validity period of a user account.
|
Days of notifications before password expiration |
|
Previous passwords disallowed |
Number of recent historical passwords that a user is not allowed to reuse. When changing the password, users cannot reuse previous passwords specified by Password repetition not allowed. |
User lockout |
Whether to lock user accounts for a specific period. With this function enabled, if a terminal uses an account and password to connect to a cloud-managed device, but the number of consecutive login failures reaches the value of Login failure count in specified times within the period specified by Specified time period, the terminal's account is locked for a period, which is specified by Lockout duration. |
Specified time period |
|
Login failure count in specified times |
|
Lockout duration |
|
Enable bound account IP/MAC address |
Whether to bind an IP address or a MAC address to a user account. |
Parameter |
Description |
|---|---|
SMS Verification Code Generation Policy |
Character types in an SMS verification code sent to users. The options are as follows:
|
SMS verification code length |
Length of an SMS verification code sent to a user. |
SMS verification template |
Template of an SMS verification code sent to a user. After the configuration, the system sends an SMS message based on the settings. All languages supported by the system share a configuration result. |
Parameter |
Description |
|
|---|---|---|
Account Validity Allocation |
Support the validity of login postponed account |
Whether to extend the validity period of an account. With this function enabled, after portal authentication-free is configured to implement MAC address-prioritized authentication, if a self-registered user logs in to iMaster NCE-Campus within the account validity period, the validity period of the user account will be extended for a further period from the user login time. For example, if the validity period of a self-registered user account is set to 1 day, when the user logs in to iMaster NCE-Campus at 8:00 a.m. on 1st September, the account is valid till 8:00 a.m. on 2nd September. If the user logs in to the system again at 12:00 p.m. on 1st September, the account is valid till 12:00 p.m. on 2nd September. |
Portal authentication-free NOTE:
If this function is enabled on the current page, you need to enable the portal authentication-free function in SSID settings of APs or routers, and authentication settings of switches. |
Cross-site Portal authentication-free |
After a terminal connects to an SSID of a site, the terminal can preferentially use the MAC address for authentication. If this function is enabled, the terminal is allowed to connect to the same SSID of other sites and preferentially use the MAC address for authentication. |
Mac account Portal authentication-free |
Whether to enable MAC address-prioritized portal authentication. If a user uses a MAC account that has passed portal authentication to log in to the controller within the authentication-free validity period, or uses a MAC address that has been recorded on the user management page of the controller, the user can log in to the controller successfully without authentication. NOTE:
When authentication components are deployed remotely, each authentication component performs MAC address authentication-free for users only after they pass portal authentication. MAC address authentication-free data cannot be synchronized between the authentication components and the headquarters. |
|
Support login delay Portal certification-free validity period |
After a user passes MAC address authentication and logs in to iMaster NCE-Campus within the validity period, the validity period of the user account will be extended for a further period from the user login time. |
|
Configuration for Expired Accounts |
Automatically clear expired users |
The Automatically clear expired users parameter indicates whether to automatically delete expired accounts. After this function is enabled, accounts that have expired for more than the specified number of days will be automatically deleted based on the configured clearance period. |
Clearance period (hours) |
||
Retaining expired users |
||
After the account is disabled, the validity period is recalculated |
After this function is enabled, the validity period of an account is not calculated after the account is disabled, and the remaining validity period is counted after the account is enabled again. The retention period of a disabled user specifies the time period for storing a disabled user. |
|
Disable user retention period (days) |
||
Maximum validity period |
Maximum validity period of an account. The account validity period set when you create a user or guest account or configure a guest account policy cannot exceed the maximum validity period set here. If the maximum validity period is not set, the account validity period for a user or guest account or in a guest account policy cannot exceed 9999. |
|
Timeout Interval of an Offline Device |
Timeout interval |
Device offline duration. When the device offline time exceeds the value of this parameter, the system logs out the online users on the device. This setting takes effect only for HACA portal authentication. |
Sensitive data |
IMSI data plaintext export |
Whether to export IMSIs in clear text. |
Enable the RADIUS user name identification policy |
To enable the RADIUS user name identification rule, run the following command |
Whether to enable RADIUS username identification. If this function is enabled, specified parameters will be carried in RADIUS usernames based on user identification rules. In such cases, the controller can learn the parameter values from RADIUS usernames automatically when RADIUS users go online. Currently, only an IMSI or an ESN can be carried in a RADIUS username. Therefore, if IMSIs or ESNs are specified in authentication rules, you need to enable this function. Currently, the following user identification rules are supported: ACCOUNT IMSI@ACCOUNT IMSI@ESN@ACCOUNT ESN@ACCOUNT |
RADIUS Authentication Transmission Protocol Configuration |
RADIUS authentication transmission protocol SSL configuration |
SSL for RADIUS authentication. TLSv1.2 is used by default. To set the RADIUS authentication transmission protocol to TLSv1 or TLSv1.1, perform the following operations:
TLSv1 and TLSv1.1 may pose data leakage risks. For security purposes, TLSv1.2 is recommended because it is more secure than TLSv1 and TLSv1.1. |
Default Self-Registration User Policy |
Subscriber validity period |
If third-party devices function as authentication devices, this policy takes effect only when no guest account policy is bound to the portal page specified in the desired portal page push policy. If cloud-managed devices function as authentication devices, this policy takes effect only when no guest account policy is bound to the portal page specified in the desired portal page push policy and the user self-registration function is disabled in the site configuration. |
Password validity period |
||
User group |
||
Anonymous authentication |
Enable anonymous authentication |
Whether to enable anonymous authentication. If this function is enabled, you need to set network areas where anonymous authentication is allowed. |
Account expiration notification configuration |
Alert account type |
After this function is enabled, the system can remind users that their accounts are about to expire in advance. This function is applicable only to common and guest accounts. You can set an SMS notification template or email notification template. |
Account expiration reminder time (day) |
||
Template for Notification of Expiry Messages |
||
Email notification template for expiration |
||
Configuring Portal Authentication for Multiple Networks |
Network type |
Network type for multi-network portal authentication. |
Network suffix |
Suffix of the account used by a user to access the network. |
|
Network role |
Role of the user who accesses the network. This parameter is configured on the page. |
|
Enabling SAVI |
Expiration Time (s) |
When iMaster NCE-Campus functions as a relay server to connect to a third-party authentication server and the SAVI function is configured on devices, devices will check whether packets are valid based on whether the source IP addresses of the packets match bindings between the IP addresses and interfaces. After this function is enabled, iMaster NCE-Campus checks the consistency of the MAC address, IP address, and user name to verify user validity. If a spoofing user exists, the system records the user in the blacklist and reports the blacklist to the configured blacklist server. The third-party authentication server forces the blacklisted users offline. The expiration time is the SAVI detection expiration time. When a device goes offline for a period longer than the configured expiration time, iMaster NCE-Campus does not perform MAC spoofing detection on the device when it goes online again. |
Access protocol |
||
Protocol version |
||
Certificate verification |
||
Address of the blacklist server |
||
(Optional) Configuring an Online User Control Policy
You can configure a policy to limit the online duration or traffic usage of end users. In this case, end users will be forced offline when they reach the online duration or traffic limit. Such policies are required if end users need to be charged.
Context
In some public areas, the online duration or traffic usage of guests needs to be limited. For example, each user can be online for at most one hour a day or is allowed to consume a maximum of 500 MB data. If any of the limits is reached, the user is forced offline.
The policies for limiting the online duration or traffic usage take effect only when iMaster NCE-Campus functions as a portal server or RADIUS server. These policies take effect in HACA authentication, Portal 2.0 authentication, 802.1X authentication, and MAC address authentication. However, such policies do not take effect in the following scenarios: without authentication, username and password authentication, third-party portal server authentication, or third-party RADIUS server authentication.
This configuration is not required if firewalls function as authentication points.
End users who go online using auto-identified terminals and auto-admitted terminals are not added to any user group. Therefore, such policies cannot be configured for these users based on user groups.
Procedure
- Choose from the main menu.
- Click the Traffic and Duration Policy tab. Then, click Create and configure an online user control policy for limiting the online duration and traffic usage of users.
![]()
- (Optional) Choose from the main menu.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
![]()
- After the parameters are set, click
![]()
to apply the created user control policy to a specific user group or user.![]()
![]()
- When creating a user, you can also set the maximum number of access terminals. The maximum number of access terminals configured on different pages takes effect in the following sequence in descending order: Maximum number of access terminals when a user is created > Number of access terminals allocated to the user > Number of access terminals allocated to the user group. If the Maximum number of terminals parameter is disabled when a user is created, the maximum number of access terminals is subject to the configuration in the user control policy. If the Maximum number of terminals parameter is enabled and no restrictions is selected, there will be no limit on the number of access terminals. Users passing MAC address authentication are not restricted by this configuration. If a user group is configured, each user in the user group supports the maximum number of access terminals.
- When an authentication component is remotely deployed, the maximum number of access terminals supported on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
Follow-up Procedure
- Choose from the main menu to view online users. You can forcibly log out users and update Change-of-Authorization (CoA), as well as export online user data. Click
![]()
to set the type of the attribute value displayed for an online user. You can select Force users offline or Force users offline and disable the port to forcibly log out users, and select Re-authentication or Intermittent port disconnection to update user authorization through CoA packets. If re-authentication is triggered, the user who has been forced offline will go online again after being re-authenticated. If you alternate the port to which the user connects between Up and Down, the user will go offline when the port is Down and will be re-authenticated and go online again after the port is Up.![]()
When you click Log Out, selected users are forced offline. If you click Log Out And Disable The Port, selected users are forced offline and the authentication ports to which the users are connected are disabled. When performing this operation, ensure that only one user is connected to each port. Otherwise, other irrelevant users will be forced offline as well.
Port flapping and port disabling are not supported when wireless authentication, HACA Portal authentication, policy association, or an Eth-Trunk is configured. In Portal 2.0 authentication scenarios, you can alternate the port to which a user connects between Up and Down. However, in this case, users cannot go online again after being forced offline.
Re-authentication is not supported in portal authentication scenarios.
CoA update is not supported by access users passing device administrator authentication.
- Choose from the main menu to view the online duration or traffic usage limits of users or terminals. You can reset the limits as needed. By default, the username, terminal IP address, and terminal MAC address are masked. If you need to view the information, disable terminal data masking on the Configuring a Terminal Privacy Policy page.
![]()
When an authentication component is remotely deployed, the online duration statistics on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
Parameter Description
Parameter |
Description |
|---|---|
Max. Number Of Terminals |
|
Allocate to User Groups/Users |
Apply the created user control policy to a specific user groups or users. |
Parameter |
Description |
|---|---|
site |
Site where the online user control policy takes effect. If Site Information Matching is disabled in an online user control policy, this policy takes effect at all sites under the tenant. In such cases, user's traffic usage or online duration is controlled on a per-site basis. |
User Level/Terminal Level |
Whether to configure an online user control policy on a per-user basis or on a per-terminal basis. The following two types of policies are available on each basis.
NOTE:
The amount of available user traffic and online duration are restricted based on the accounting request packets sent by devices. Since devices send accounting request packets periodically, there may be differences between the configured amount of available user traffic or online duration and that in actual situations. Assume that: 1. The interval for sending accounting request packets is set to 5 minutes in SSID configuration whereas the interval is set to 10 minutes in online duration control policy configuration. 2. A user or terminal initiates portal authentication at the beginning of the fourth minute in an accounting period. In this scenario, when a device sends accounting request packets for the first time and the second time, the available online duration of the user is not used up. Therefore, the user or terminal can continue to access the network. When the device sends an accounting request packet for the third time, the system determines that the online duration of the user or terminal exceeds the upper limit, and then restricts the network access of the user or terminal. In this case, the actual online duration of the user or terminal is 12 minutes, rather than 10 minutes specified in the online control policy. If both traffic-based control and duration-based control are enabled, re-authentication is triggered when either of the conditions is met. Reset traffic and duration:
|
Allocate User Group |
Click |
(Optional) Configuring a Policy Element
Context
RADIUS attributes, that is the Attribute field in RADIUS packets carry authentication, authorization, and accounting information. iMaster NCE-Campus supports Huawei, Cisco, and IETF standard RADIUS attributes and also custom RADIUS attributes. You can define the logical relations among multiple custom attributes and use them as customization conditions in authentication and authorization rules.
The MDM system can check the security status of registered mobile devices based on the compliance, jailbreaking, and data encryption information. After iMaster NCE-Campus interconnects with the MDM system, it obtains the device status from the MDM system and authorizes mobile devices accordingly. This prevents insecure mobile devices from connecting to networks. MDM conditions need to be configured when iMaster NCE-Campus authorizes mobile devices based on their status queried from the MDM system.
Procedure
- Choose from the main menu.
- (Optional) To use custom RADIUS attributes, click the RADIUS Attribute tab and click Create.
![]()
- Click the Custom Condition tab and create a customization condition.
![]()
- Click the MDM Condition tab and configure an MDM condition.
![]()
Follow-Up Procedure
After a customization condition is configured, you can reference it in an authentication or authorization rule.
After a MDM condition is configured, you can reference it in an authorization rule.
Parameter Description
Parameter |
Description |
|---|---|
Vendor ID |
ID of the RADIUS attribute. |
Vendor |
Vendor of the RADIUS attribute. |
Attribute ID |
ID of the RADIUS attribute. |
Attribute Nam |
Name of the RADIUS attribute. |
Attribute Type |
Type of the RADIUS attribute. The options are as follows:
|
Parameter |
Description |
|---|---|
Name |
Name of a customization condition. |
Logical relation |
Logical relationships among multiple attributes. The options are as follows:
|
Attribute List |
Meaning: Attributes in the condition. The following parameters need to be defined for each attribute:
|
Parameter Name |
Description |
|---|---|
Name |
Name of an MDM condition. |
MDM vendor |
Currently, the MDM vendors that support interconnection with iMaster NCE-Campus include Qi An Xin, Ivanti, and MDM GENERAL. |
Logical relation |
Logical relation between attributes in an MDM condition. The options are as follows:
|
Property |
Property in an MDM condition. The following parameters are included:
For example, if an MDM condition that matches compliant terminals is configured and applied and the MDM check is enabled in an authorization rule, only terminals in compliant state can match the authorization rule. |
Configuring a RADIUS Template
Procedure
- Choose from the main menu, and select RADIUS Server.
- Click Create, set parameters, and click OK.
![]()
- When configuring an SSID for authentication based on a RADIUS server, you can select this template to specify the RADIUS server associated with the SSID. For details, see Configuring an SSID.
- Only APs running V200R008C10 and later versions support the Disable RADIUS attributes parameter. The RADIUS attributes supported vary with the AP model. If this parameter is configured in the selected RADIUS template, ensure that the model and version of the target AP meet requirements. Otherwise, the SSID-related service configuration will fail to be delivered. To view RADIUS attributes supported by a device, run the display radius-attribute command in the system view of the device.
- Only APs running V200R009C00 and later versions support the Set called-station-id attribute value parameter.
- Only APs running V200R008C00 and later versions support the Real-time accounting parameter.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS server template. |
|
Using Built-in Server |
Whether to configure iMaster NCE-Campus as a RADIUS server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
|
Authentication server |
Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight authentication servers can be added. |
|
Accounting server |
Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight accounting servers can be added. |
|
Authentication component |
This parameter needs to be set only when Using Built-in Server is enabled. The authentication component can be the Service Manager (SM) or a remote server. The SM is the headquarters controller. |
|
Server selection policy |
|
|
Server selection algorithm |
|
|
Real-time accounting |
Whether to enable real-time accounting. After this function is enabled, you can configure a real-time accounting interval. By default, this function is disabled. |
|
Billing reporting cycle |
Real-time accounting interval. |
|
Key |
Shared key of the RADIUS server. You are advised to periodically change the shared key. |
|
Disable RADIUS attributes |
Whether to filter specific attributes in the packets exchanged between the device and the RADIUS server. The default value is OFF, indicating that specific attributes are not filtered. |
|
Disable attributes |
- |
Click Create and configure a filtering policy. |
Attribute name |
Click ... and select the names of attributes to be filtered in the displayed dialog box. |
|
Prohibit Sending |
The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server. |
|
Prohibit Receiving |
The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server. |
|
Service-Type |
- |
The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server. |
Attribute value |
Specifies the value of service-type attribute to be modified. |
|
Option |
Sets the user authentication mode to MAC address authentication. |
|
called-station-id |
- |
After this function is enabled, you can set the called-station-id attribute value, which specifies content encapsulated in the called-station-id attribute of RADIUS packets. Currently, only APs support this function. By default, this function is disabled. |
Attribute value |
Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location. |
|
Carry SSID attributes |
After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled. |
|
Attribute separator |
Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains the SSID. The value is of enumerated type, and can be \, /, :, <, >, |, @, ', %, *, +, -, &, !, #, ^, and ~. The default value is :. |
|
Mac address format setting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
Server status auto-detection |
Username |
Username for automatic RADIUS server detection. |
Password |
Password for automatic RADIUS server detection. |
|
Retransmit authentication requests |
Retransmission count |
Number of retransmission times if an authentication request times out. |
Timeout interval |
Timeout interval of an authentication request. |
|
Server down duration |
Period during which the authentication server remains Down. |
|
Configuring an Authentication Point
Context
After authentication and authorization rules are configured, you need to configure the authentication mode on authentication points. For example, when configuring an SSID on an AP, you need to specify an authentication mode to implement access control on wireless access users. Only one authentication mode can be specified for each SSID. Therefore, the authentication mode for an access user is determined by the SSID selected when the user accesses the Internet. However, multiple SSIDs can be deployed on one AP. Employees and guests access the Internet using different SSIDs and different authentication modes.
When iMaster NCE-Campus is used as a RADIUS server, the value-added RADIUS service must be installed.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Secure network, select an encryption mode, and specify a RADIUS server using a RADIUS template.
- If MAC address bypass authentication is configured, a bypass policy can be configured to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- Set Authentication mode to Secure network and specify a RADIUS server using a template.
- Set Interface access mode and Terminal access mode. Currently, the following access modes are supported:
- Allow multi-terminal access under interface and Multi-terminal authenticated access: An interface allows multiple users to go online. In this mode, the device authenticates each user. If the authentication succeeds, the device grants independent network access rights to the user. That is, if a user goes offline, other users are not affected.
Allow multi-terminal access under interface and Only the first terminal needs authentication access: An interface allows multiple users to go online. In this mode, the device authenticates only the first go-online user. If the authentication succeeds, subsequent users share the network access permission of the first user. If the first user goes offline, other users go offline accordingly.
- Allow single-terminal access under interface and Single-terminal access: An interface allows only one user to go online.
Allow single-terminal access under interface and Single common terminal accesses through voice terminal: An interface allows only one data user and one voice user to go online. This mode applies to the scenario where a data user accesses the network through a voice terminal.
- Allow multi-terminal access under interface and Multi-terminal authenticated access: An interface allows multiple users to go online. In this mode, the device authenticates each user. If the authentication succeeds, the device grants independent network access rights to the user. That is, if a user goes offline, other users are not affected.
- (Optional) Configure MAC address authentication bypass.
If dumb terminals such as PCs, printers, and fax machines are connected to the interfaces of an access device and only 802.1X authentication is configured, printers and fax machines will fail to be authenticated. In this scenario, you can configure MAC address authentication bypass, so dumb terminals that do not support 802.1X authentication can access the Internet using MAC address authentication.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
- Select the type of packets that trigger authentication. By default, a switch triggers authentication through DHCP, ARP, DHCPv6, or ND packets. If a dumb terminal is configured with a static IPv4 address, and no DHCP or ARP packets are exchanged between the dumb terminal and authentication device, you need to select any-l2-packet for authentication.
- (Optional) In a wired authentication scenario of a switch, click the Authentication Device Global Configuration tab, and enable MAC address migration and Detection before MAC address migration.
After a user is authenticated and accesses the network from one port on a switch, the user removes the network cable from the port and inserts in another port on the switch. In this case, the user cannot immediately initiate authentication and access the network. The user can initiate authentication on the current port only after the user offline detection interval expires or the authentication port is manually enabled and shut down to clear user online entries. To improve user experience, MAC address migration can be enabled so that the user can immediately initiate authentication and access the network after being switched to another access port.
MAC address migration allows online NAC authentication users to immediately initiate authentication and access the network after connecting to other access ports. If the user is authenticated successfully on the new port, the online user entry on the original port is deleted immediately to ensure that the online user entry is recorded on only one port. To prevent unauthorized users from spoofing online users to attack a device, you can set Detection before MAC address migration.
NOTE:Wireless authentication needs to be configured in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
WAC
- Choose from the navigation pane. Click add and configure authentication.
- Set Authentication mode to Secure network, and specify a RADIUS server using a RADIUS template.NOTE:
WAC-side configuration needs to be performed in the web NMS. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Configuring an Authentication Rule
Authentication rules can be configured to authenticate clients and users on the network to ensure network security.
iMaster NCE-Campus provides a default authentication rule default that uses a local data source for authentication. The default template can be modified to use a third-party data source for authentication.
When configuring 802.1X authentication, set the authentication mode to User Access Authentication. When configuring MAC address authentication, set the authentication mode to MAC Address Authentication.
Authentication Rule Matching
Administrators can configure authentication rules based on network requirements. End users who access the network can be authenticated successfully after matching authentication rules. One or more parameters can be configured in an authentication rule, and the relationship between the parameters is AND. For example, configure an authentication rule named test and specify site1 and group1 in the rule. When an end user attempts to access the network, if the user belongs to group1 and accesses the network through the authentication point at site1, the user will be authenticated successfully. Otherwise, the user fails the authentication. The following figure shows the authentication procedure.
Neither the device MAC address nor the flag indicating wired or wireless access is carried in test-aaa packets. Currently, the system uses the access type (wired or wireless) to match authentication rules. By default, such test-aaa packets match authentication rules that allow wired and wireless access.
Context
You can configure multiple authentication rules to generate an authentication scheme. The authentication scheme defines the authentication rules used for user authentication. If multiple authentication rules are configured, the authentication rule with the smallest priority value has the highest priority. If the high-priority authentication rule is matched, other rules are not matched.
Procedure
- Choose from the main menu.
- Click Create to configure an authentication rule. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authentication rule if the authentication rule defines user authentication based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authentication rule
The priority value of the first authentication rule is 1 and the priority values of subsequent authentication rules increase by 1. The smaller the priority value, the higher the priority. The default authentication rule has the lowest priority. You can set the priority of an authentication rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time information |
User authentication based on time ranges. |
|
Authentication Information |
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
|
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, firewall, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. Currently, two methods are available: two-factor authentication using accounts and SMS verification code or RADIUS tokens, and two-factor authentication using SSL VPN-enabled firewalls. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. The RADIUS token factor is supported only when the two-factor authentication method is used. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
PAP must be enabled when LDAP accounts are used for Portal 2.0 authentication, FW SSL VPN authentication, and MAC address authentication. In addition, CHAP must be enabled for Portal 2.0 authentication. If iMaster NCE-Campus functions as an authentication server in other services, enable the required protocol. One of the EAP-MD5, EAP-PEAP-MSCHAPv2, EAP-TLS, EAP-PEAP-GTC, and EAP-TTLS-PAP protocols can be specified as the preferential protocol used for authentication. This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
User authentication based on user groups to which MAC accounts are mapped. |
MAC account |
User authentication based on MAC accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows: PAP protocol (local account, AD, LDAP, RADIUS Token, Third-party HTTP server, Third-party Database) CHAP protocol(Local account, Third-party Database) |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Admission device group |
User authentication based on access device groups. |
|
Terminal IP range |
User authentication based on terminal IP addresses. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Device IP address, access VLAN, access port, user MAC address, user IP address, user IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Configuring an Authorization Result
Context
When you configure portal authentication, 802.1X authentication, and MAC address authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
When you configure device administrator authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
iMaster NCE-Campus provides two default authorization results: Permit Access and Deny Access. The two results are bound to all sites to form default templates, which cannot be modified or deleted.
The rights assigned to an authenticated end user are specified by an authorization result. The permissions involve the destination IP address, protocol, and port defined by an ACL, URL permitted or rejected, and uplink or downlink bandwidth of terminals.
SSID-based policy control indicates that the STA connected to an SSID has the corresponding rights. The set of rights specified in an authorization result is dynamically authorized according to the matching policy after an end user is authenticated. The rights assigned to an end user include those specified both in an SSID and an authorization result.
Procedure
- Choose from the main menu.
- Click Create to create an authorization result. Parameters in an authorization result vary with the device type. For details about the parameters, see Parameter Description at the end of this section.
![]()
- Click OK to bind the authorization result to sites. You can also select an authorization result, click
![]()
, and select desired sites to bind them to the result.![]()
Parameter Description
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring an Authorization Rule
When iMaster NCE-Campus authorizes authenticated users, it grants specific permissions only to the users who hit the specified authorization rules.
iMaster NCE-Campus provides a default authorization rule default with the authorization result Deny Access. You can modify the authorization result in this default template as required.
Context
Authorization results define the rights assigned to authenticated end users. Each authentication rule corresponds to an authentication result. If an authenticated end user matches an authentication rule, the corresponding authorization result applies to the user. If no authorization rule is set, an authorization result is applicable to all authenticated terminals.
Procedure
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to user access authentication. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authorization rule if the authorization rule defines user authorization based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authorization rule
The priority value of the first authorization rule is 1 and the priority values of subsequent authorization rules increase by 1. The smaller the priority value, the higher the priority. The default authorization rule has the lowest priority. You can set the priority of an authorization rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server belongs to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on accounts. |
||
Role Information |
Authenticated users are authorized based on roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. |
||
Region |
Authenticated users are authorized based on regions. |
||
Protocol Information |
Enable protocol matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported:
|
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, and FW. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on regions. |
||
Region |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Protocol Information |
Enable protocol information matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported: EEAP-MD5 protocol (Local account) EAP-PEAP-MSCHAPv2 protocol (Local account, AD, and LDAP) EAP-TLS protocol (Local account, AD, LDAP) EAP-PEAP-GTC protocol (Local account, AD, LDAP, and RADIUS Token) EAP-TTLS-PAP protocol (Local account, AD, and LDAP) |
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
The Authentication Terminal Has Been Added to the AD Domain |
Whether authenticated users using terminals that have been added to AD domains have been authorized. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, and WAC. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Region |
Authenticated users are authorized based on regions. |
||
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
Admission Device Group |
Authenticated users are authorized based on access device groups. |
|
Region |
Authenticated users are authorized based on regions. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
MAC Address Authentication
Creating a MAC Account
Context
If dumb terminals such as printers and phones are connected to a network, you are advised to use the following methods to implement MAC address authentication:
Authentication Mode |
Account Type |
Description |
|---|---|---|
MAC address authentication |
MAC |
The MAC address list is provisioned by a tenant administrator on iMaster NCE-Campus in advance. |
Procedure
- Choose from the main menu.
- Click Create to create a MAC account.
![]()
- Click Create to create a MAC account.
Related Operations
- User-defined field
Click
![]()
, and then click Create to customize the user information required for registration when the administrator creates a user.![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
MAC Account Name |
MAC account name. |
|
MAC address list |
List of MAC addresses that can be accessed by end users. |
|
User Group |
User group to which the MAC account belongs. |
|
Role |
Role attached to the MAC account. |
|
Email address and phone number associated with the MAC account. |
||
Contact number |
||
Expiration time |
Expiration time of the MAC account. |
|
Terminals Bound to an Access Device |
Terminal IP address |
Terminal IP address bound to the user account. |
Bound terminal ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
SIM/USIM's IMSI |
SIM card or IMSI bound to an account. The value is a string of 1 to 15 characters consisting of digits (0-9). IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Bind an access device |
Access device IP address |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
(Optional) Attaching a Role to an Account
Context
In addition to user groups, accounts can be managed based on account roles. An account can belong to only one user group but can be attached to multiple roles. Accounts and roles are mapped in a one-to-many manner. Roles can be created manually by an administrator or created automatically during AD/LDAP account synchronization. Roles can be used for authentication, authorization, and security policy allocation.
Procedure
- Choose from the main menu.
- Click Create to create a role.
![]()
- After the role is created, click
![]()
next to the role, and click Add to attach the role to a user account, guest account, or MAC account.![]()
- Click Import to import roles in batches using an Excel template.
- Click Export All to export information about all roles.
- Click Create to create a role.
Configuring a RADIUS Server Template
Procedure
- Choose from the main menu, and select RADIUS Server.
- Click Create, set parameters, and click OK.
![]()
- When configuring an SSID for authentication based on a RADIUS server, you can select this template to specify the RADIUS server associated with the SSID. For details, see Configuring an SSID.
- Only APs running V200R008C10 and later versions support the Disable RADIUS attributes parameter. The RADIUS attributes supported vary with the AP model. If this parameter is configured in the selected RADIUS template, ensure that the model and version of the target AP meet requirements. Otherwise, the SSID-related service configuration will fail to be delivered. To view RADIUS attributes supported by a device, run the display radius-attribute command in the system view of the device.
- Only APs running V200R009C00 and later versions support the Set called-station-id attribute value parameter.
- Only APs running V200R008C00 and later versions support the Real-time accounting parameter.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS server template. |
|
Using Built-in Server |
Whether to configure iMaster NCE-Campus as a RADIUS server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
|
Authentication server |
Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight authentication servers can be added. |
|
Accounting server |
Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight accounting servers can be added. |
|
Authentication component |
This parameter needs to be set only when Using Built-in Server is enabled. The authentication component can be the Service Manager (SM) or a remote server. The SM is the headquarters controller. |
|
Server selection policy |
|
|
Server selection algorithm |
|
|
Real-time accounting |
Whether to enable real-time accounting. After this function is enabled, you can configure a real-time accounting interval. By default, this function is disabled. |
|
Billing reporting cycle |
Real-time accounting interval. |
|
Key |
Shared key of the RADIUS server. You are advised to periodically change the shared key. |
|
Disable RADIUS attributes |
Whether to filter specific attributes in the packets exchanged between the device and the RADIUS server. The default value is OFF, indicating that specific attributes are not filtered. |
|
Disable attributes |
- |
Click Create and configure a filtering policy. |
Attribute name |
Click ... and select the names of attributes to be filtered in the displayed dialog box. |
|
Prohibit Sending |
The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server. |
|
Prohibit Receiving |
The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server. |
|
Service-Type |
- |
The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server. |
Attribute value |
Specifies the value of service-type attribute to be modified. |
|
Option |
Sets the user authentication mode to MAC address authentication. |
|
called-station-id |
- |
After this function is enabled, you can set the called-station-id attribute value, which specifies content encapsulated in the called-station-id attribute of RADIUS packets. Currently, only APs support this function. By default, this function is disabled. |
Attribute value |
Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location. |
|
Carry SSID attributes |
After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled. |
|
Attribute separator |
Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains the SSID. The value is of enumerated type, and can be \, /, :, <, >, |, @, ', %, *, +, -, &, !, #, ^, and ~. The default value is :. |
|
Mac address format setting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
Server status auto-detection |
Username |
Username for automatic RADIUS server detection. |
Password |
Password for automatic RADIUS server detection. |
|
Retransmit authentication requests |
Retransmission count |
Number of retransmission times if an authentication request times out. |
Timeout interval |
Timeout interval of an authentication request. |
|
Server down duration |
Period during which the authentication server remains Down. |
|
(Optional) Configuring an Online User Control Policy
You can configure a policy to limit the online duration or traffic usage of end users. In this case, end users will be forced offline when they reach the online duration or traffic limit. Such policies are required if end users need to be charged.
Context
In some public areas, the online duration or traffic usage of guests needs to be limited. For example, each user can be online for at most one hour a day or is allowed to consume a maximum of 500 MB data. If any of the limits is reached, the user is forced offline.
The policies for limiting the online duration or traffic usage take effect only when iMaster NCE-Campus functions as a portal server or RADIUS server. These policies take effect in HACA authentication, Portal 2.0 authentication, 802.1X authentication, and MAC address authentication. However, such policies do not take effect in the following scenarios: without authentication, username and password authentication, third-party portal server authentication, or third-party RADIUS server authentication.
This configuration is not required if firewalls function as authentication points.
End users who go online using auto-identified terminals and auto-admitted terminals are not added to any user group. Therefore, such policies cannot be configured for these users based on user groups.
Procedure
- Choose from the main menu.
- Click the Traffic and Duration Policy tab. Then, click Create and configure an online user control policy for limiting the online duration and traffic usage of users.
![]()
- (Optional) Choose from the main menu.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
![]()
- After the parameters are set, click
![]()
to apply the created user control policy to a specific user group or user.![]()
![]()
- When creating a user, you can also set the maximum number of access terminals. The maximum number of access terminals configured on different pages takes effect in the following sequence in descending order: Maximum number of access terminals when a user is created > Number of access terminals allocated to the user > Number of access terminals allocated to the user group. If the Maximum number of terminals parameter is disabled when a user is created, the maximum number of access terminals is subject to the configuration in the user control policy. If the Maximum number of terminals parameter is enabled and no restrictions is selected, there will be no limit on the number of access terminals. Users passing MAC address authentication are not restricted by this configuration. If a user group is configured, each user in the user group supports the maximum number of access terminals.
- When an authentication component is remotely deployed, the maximum number of access terminals supported on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
- Click the Max. Number Of Terminals tab, and then click Create to create a user control policy.
Follow-up Procedure
- Choose from the main menu to view online users. You can forcibly log out users and update Change-of-Authorization (CoA), as well as export online user data. Click
![]()
to set the type of the attribute value displayed for an online user. You can select Force users offline or Force users offline and disable the port to forcibly log out users, and select Re-authentication or Intermittent port disconnection to update user authorization through CoA packets. If re-authentication is triggered, the user who has been forced offline will go online again after being re-authenticated. If you alternate the port to which the user connects between Up and Down, the user will go offline when the port is Down and will be re-authenticated and go online again after the port is Up.![]()
When you click Log Out, selected users are forced offline. If you click Log Out And Disable The Port, selected users are forced offline and the authentication ports to which the users are connected are disabled. When performing this operation, ensure that only one user is connected to each port. Otherwise, other irrelevant users will be forced offline as well.
Port flapping and port disabling are not supported when wireless authentication, HACA Portal authentication, policy association, or an Eth-Trunk is configured. In Portal 2.0 authentication scenarios, you can alternate the port to which a user connects between Up and Down. However, in this case, users cannot go online again after being forced offline.
Re-authentication is not supported in portal authentication scenarios.
CoA update is not supported by access users passing device administrator authentication.
- Choose from the main menu to view the online duration or traffic usage limits of users or terminals. You can reset the limits as needed. By default, the username, terminal IP address, and terminal MAC address are masked. If you need to view the information, disable terminal data masking on the Configuring a Terminal Privacy Policy page.
![]()
When an authentication component is remotely deployed, the online duration statistics on the authentication component and at the headquarters is collected separately, and data synchronization is not performed.
Parameter Description
Parameter |
Description |
|---|---|
Max. Number Of Terminals |
|
Allocate to User Groups/Users |
Apply the created user control policy to a specific user groups or users. |
Parameter |
Description |
|---|---|
site |
Site where the online user control policy takes effect. If Site Information Matching is disabled in an online user control policy, this policy takes effect at all sites under the tenant. In such cases, user's traffic usage or online duration is controlled on a per-site basis. |
User Level/Terminal Level |
Whether to configure an online user control policy on a per-user basis or on a per-terminal basis. The following two types of policies are available on each basis.
NOTE:
The amount of available user traffic and online duration are restricted based on the accounting request packets sent by devices. Since devices send accounting request packets periodically, there may be differences between the configured amount of available user traffic or online duration and that in actual situations. Assume that: 1. The interval for sending accounting request packets is set to 5 minutes in SSID configuration whereas the interval is set to 10 minutes in online duration control policy configuration. 2. A user or terminal initiates portal authentication at the beginning of the fourth minute in an accounting period. In this scenario, when a device sends accounting request packets for the first time and the second time, the available online duration of the user is not used up. Therefore, the user or terminal can continue to access the network. When the device sends an accounting request packet for the third time, the system determines that the online duration of the user or terminal exceeds the upper limit, and then restricts the network access of the user or terminal. In this case, the actual online duration of the user or terminal is 12 minutes, rather than 10 minutes specified in the online control policy. If both traffic-based control and duration-based control are enabled, re-authentication is triggered when either of the conditions is met. Reset traffic and duration:
|
Allocate User Group |
Click |
Configuring an Authentication Point
Context
After the authentication and authorization rules are configured, you need to configure the authentication mode on the authentication point. For example, when configuring an SSID on an AP, you need to specify an authentication mode to implement access control on wireless access users. Only one authentication mode can be specified for each SSID. Therefore, the authentication mode for an access user is determined by the SSID selected when the user accesses the Internet. However, multiple SSIDs can be deployed on one AP. Employees and guests access the Internet using different SSIDs and different authentication modes.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Semi-open network, select MAC, and specify a RADIUS server using a RADIUS template.
- (Optional) If users need to access an authentication server through its domain name, add the IP address of the DNS server to the default permit rule.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- On the Security Authentication page, set Authentication mode to Semi-open network, select MAC for wireless authentication, and specify a RADIUS server using a RADIUS template.
- Set Interface access mode and Terminal access mode. Currently, the following access modes are supported:
- Allow multi-terminal access under interface and Multi-terminal authenticated access: An interface allows multiple users to go online. In this mode, the device authenticates each user. If the authentication succeeds, the device grants independent network access rights to the user. That is, if a user goes offline, other users are not affected.
Allow multi-terminal access under interface and Only the first terminal needs authentication access: An interface allows multiple users to go online. In this mode, the device authenticates only the first go-online user. If the authentication succeeds, subsequent users share the network access permission of the first user. If the first user goes offline, other users go offline accordingly.
- Allow single-terminal access under interface and Single-terminal access: An interface allows only one user to go online.
Allow single-terminal access under interface and Single common terminal accesses through voice terminal: An interface allows only one data user and one voice user to go online. This mode applies to the scenario where a data user accesses the network through a voice terminal.
- Allow multi-terminal access under interface and Multi-terminal authenticated access: An interface allows multiple users to go online. In this mode, the device authenticates each user. If the authentication succeeds, the device grants independent network access rights to the user. That is, if a user goes offline, other users are not affected.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
- Select the type of packets that trigger MAC address authentication. By default, a switch triggers MAC address authentication through DHCP, ARP, DHCPv6, or ND packets. If a dumb terminal is configured with a static IPv4 address, and no DHCP or ARP packets are exchanged between the dumb terminal and authentication device, you need to select any-l2-packet for MAC address authentication.
- (Optional) In a wired authentication scenario of a switch, click the Authentication Device Global Configuration tab, and enable MAC address migration and Detection before MAC address migration.
After a user is authenticated and accesses the network from one port on a switch, the user removes the network cable from the port and inserts in another port on the switch. In this case, the user cannot immediately initiate authentication and access the network. The user can initiate authentication on the current port only after the user offline detection interval expires or the authentication port is manually enabled and shut down to clear user online entries. To improve user experience, MAC address migration can be enabled so that the user can immediately initiate authentication and access the network after being switched to another access port.
MAC address migration allows online NAC authentication users to immediately initiate authentication and access the network after connecting to other access ports. If the user is authenticated successfully on the new port, the online user entry on the original port is deleted immediately to ensure that the online user entry is recorded on only one port. To prevent unauthorized users from spoofing online users to attack a device, you can set Detection before MAC address migration.
NOTE:- By default, a switch, which functions as an authentication device, triggers MAC address authentication using DHCP, ARP, DHCPv6, or ND packets. If a dumb terminal is configured with a static IPv4 address, no DHCP or ARP packet is transmitted between the terminal and authentication device. As a result, MAC address authentication cannot be triggered for end users using the dumb terminal.
- Wireless authentication needs to be configured in the web NMS. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
WAC
- Choose from the navigation pane. Click add and configure authentication.
- Set Authentication mode to Semi-open network, and specify a RADIUS server using a RADIUS template.NOTE:
WAC-side configuration needs to be performed in the web NMS. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Configuring an Authentication Rule
Authentication rules can be configured to authenticate clients and users on the network to ensure network security.
iMaster NCE-Campus provides a default authentication rule default that uses a local data source for authentication. The default template can be modified to use a third-party data source for authentication.
When configuring MAC address authentication, set the authentication mode to MAC Address Authentication.
Context
You can configure multiple authentication rules to generate an authentication scheme. The authentication scheme defines the authentication rules used for user authentication. If multiple authentication rules are configured, the authentication rule with the smallest priority value has the highest priority. If the high-priority authentication rule is matched, other rules are not matched.
Procedure
- Choose from the main menu.
- Click Create to configure an authentication rule. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authentication rule if the authentication rule defines user authentication based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authentication rule
The priority value of the first authentication rule is 1 and the priority values of subsequent authentication rules increase by 1. The smaller the priority value, the higher the priority. The default authentication rule has the lowest priority. You can set the priority of an authentication rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time information |
User authentication based on time ranges. |
|
Authentication Information |
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
|
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, firewall, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. Currently, two methods are available: two-factor authentication using accounts and SMS verification code or RADIUS tokens, and two-factor authentication using SSL VPN-enabled firewalls. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. The RADIUS token factor is supported only when the two-factor authentication method is used. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
PAP must be enabled when LDAP accounts are used for Portal 2.0 authentication, FW SSL VPN authentication, and MAC address authentication. In addition, CHAP must be enabled for Portal 2.0 authentication. If iMaster NCE-Campus functions as an authentication server in other services, enable the required protocol. One of the EAP-MD5, EAP-PEAP-MSCHAPv2, EAP-TLS, EAP-PEAP-GTC, and EAP-TTLS-PAP protocols can be specified as the preferential protocol used for authentication. This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
User authentication based on user groups to which MAC accounts are mapped. |
MAC account |
User authentication based on MAC accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows: PAP protocol (local account, AD, LDAP, RADIUS Token, Third-party HTTP server, Third-party Database) CHAP protocol(Local account, Third-party Database) |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Admission device group |
User authentication based on access device groups. |
|
Terminal IP range |
User authentication based on terminal IP addresses. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Device IP address, access VLAN, access port, user MAC address, user IP address, user IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Configuring an Authorization Result
Context
When you configure portal authentication, 802.1X authentication, and MAC address authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
When you configure device administrator authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
iMaster NCE-Campus provides two default authorization results: Permit Access and Deny Access. The two results are bound to all sites to form default templates, which cannot be modified or deleted.
The rights assigned to an authenticated end user are specified by an authorization result. The permissions involve the destination IP address, protocol, and port defined by an ACL, URL permitted or rejected, and uplink or downlink bandwidth of terminals.
SSID-based policy control indicates that the STA connected to an SSID has the corresponding rights. The set of rights specified in an authorization result is dynamically authorized according to the matching policy after an end user is authenticated. The rights assigned to an end user include those specified both in an SSID and an authorization result.
Procedure
- Choose from the main menu.
- Click Create to create an authorization result. Parameters in an authorization result vary with the device type. For details about the parameters, see Parameter Description at the end of this section.
![]()
- Click OK to bind the authorization result to sites. You can also select an authorization result, click
![]()
, and select desired sites to bind them to the result.![]()
Parameter Description
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring an Authorization Rule
When iMaster NCE-Campus authorizes authenticated users, it grants specific permissions only to the users who hit the specified authorization rules.
iMaster NCE-Campus provides a default authorization rule default with the authorization result Deny Access. You can modify the authorization result in this default template as required.
Context
Authorization results define the rights assigned to authenticated end users. Each authentication rule corresponds to an authentication result. If an authenticated end user matches an authentication rule, the corresponding authorization result applies to the user. If no authorization rule is set, an authorization result is applicable to all authenticated terminals.
Procedure
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to MAC authentication. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authorization rule if the authorization rule defines user authorization based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authorization rule
The priority value of the first authorization rule is 1 and the priority values of subsequent authorization rules increase by 1. The smaller the priority value, the higher the priority. The default authorization rule has the lowest priority. You can set the priority of an authorization rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server belongs to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on accounts. |
||
Role Information |
Authenticated users are authorized based on roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. |
||
Region |
Authenticated users are authorized based on regions. |
||
Protocol Information |
Enable protocol matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported:
|
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, and FW. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on regions. |
||
Region |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Protocol Information |
Enable protocol information matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported: EEAP-MD5 protocol (Local account) EAP-PEAP-MSCHAPv2 protocol (Local account, AD, and LDAP) EAP-TLS protocol (Local account, AD, LDAP) EAP-PEAP-GTC protocol (Local account, AD, LDAP, and RADIUS Token) EAP-TTLS-PAP protocol (Local account, AD, and LDAP) |
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
The Authentication Terminal Has Been Added to the AD Domain |
Whether authenticated users using terminals that have been added to AD domains have been authorized. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, and WAC. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Region |
Authenticated users are authorized based on regions. |
||
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
Admission Device Group |
Authenticated users are authorized based on access device groups. |
|
Region |
Authenticated users are authorized based on regions. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
PSK+MAC Address Authentication
Context
When dumb terminals access the network through MAC address authentication, security issues such as MAC address spoofing may occur. For smart terminals that support password input, you are advised to configure PSK+MAC address authentication to improve security. PSK+MAC address authentication is applicable only to guest access through QR code scanning using the WeChat APP via Wi-Fi. For detailed configuration, see Configuring Guest Access Through QR Code Scanning Using the WeChat APP via Wi-Fi.
Procedure
- Choose from the main menu.
- Click
![]()
to create a user. You can create users one by one.![]()
- Select a user group and click Create to create a user. You can create users one by one.
![]()
When creating a user, you are advised to bind an email address or phone number to the user to facilitate password change.
![]()
- Click
![]()
to import users and user groups. You can use an Excel template to import users and user groups in batches. - Click
![]()
to export users and user groups. After the export task is created, click OK and choose to view and download the task.
- Click
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication method to MAC address authentication and select a wireless access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to MAC address authentication and select a wireless access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure a RADIUS template.
- Choose from the main menu. On the page that is displayed, click RADIUS Server from the navigation pane.
- Click Create. In the dialog box that is displayed, set parameters and click OK.
- On iMaster NCE-Campus, set the mode of the authentication device to PSK+MAC address authentication.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Select a configuration process based on the type of device used as the authentication point.
Authentication Point
Configuration Process
AP
- Choose from the navigation pane, click Create, and set basic SSID information.
- On the Security Authentication page, set Authentication mode to Semi-open network and PSK+MAC address authentication. Set Key type to PSK and set Encryption mode, Encryption algorithm, and the SSID access password.
The options of Encryption algorithm are as follows:
- AES: Encrypt data using the Advanced Encryption Standard (AES) algorithm.
- AES-TKIP: Encrypt data using the AES or TKIP algorithm. After successful authentication, the user terminal encrypts data using the supported algorithm AES or TKIP.
- TKIP: Encrypt data using the Temporal Key Integrity Protocol (TKIP) algorithm.
- Configure the RADIUS server.
Switch
- Choose from the navigation pane. Click the Wireless Authentication tab. Click Create to create the authentication information.
- Set Authentication mode to Semi-open network and PSK+MAC address authentication and select a RADIUS server template.
- Configure the RADIUS server.
WAC
- Choose from the navigation pane. Click Create to create the authentication information.
- Set Authentication mode to Semi-open network and PSK+MAC address authentication and select a RADIUS server template.
- Configure the RADIUS server.NOTE:
WAC configuration needs to be performed in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Firewall and AR
None
Two-Factor Authentication
Overview
Context
Two-factor authentication is a secure authentication process that requires users to offer two authentication factors to prove their identity. This authentication method is mainly used in industries with high security requirements, such as the government and banks. iMaster NCE-Campus supports the following two-factor authentication methods:
- Portal authentication using a username and password and an SMS verification code. This method is supported when HACA Portal or Portal 2.0 is configured and applies to user access authentication.
- Portal authentication using a username and password and a RADIUS token (RSA). This method is supported when HACA Portal or Portal 2.0 is configured and applies to user access authentication.
- Portal 2.0 two-factor authentication using an SSL VPN-enabled firewall. This method is supported when HACA is enabled and applies to user access authentication.
- HWTACACS two-factor authentication. For details, see HWTACACS Authentication.
Authentication by Using Username and Password and SMS Verification Code
Context
Portal authentication can authenticate users based on two factors: username and password and verification code. This authentication method features easy deployment and high security.
Pre-configuration Tasks
The operations described in Configuring an SMS Server need to be completed in advance.
Procedure
- Customize a portal page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a user-defined template. In this example, select User Name and Password Template as the system template.![]()
- In the page editing area, select an authentication page, select page controls, and customize a portal page by using the two-factor control. Delete unnecessary controls from the template and click Save and Release.
![]()
- Choose from the main menu to add a user. Alternatively, choose from the main menu and enter the mobile number bound to the guest account. This ensures that the user can receive an SMS message containing a verification code.
- Choose from the main menu to configure an authentication rule. Here, you need to toggle Two-factor authentication on, set Two-factor authentication type to Two-factor access, and set Second data source type to Dynamic password (SMS message).
![]()
- Configure an authorization rule, authorization result, and access point. For details, see Portal Authentication.
Portal Authentication by Using Username and Password and RADIUS Token
Context
RSA Authentication Manager (RSA AM) is a dedicated product supporting multi-factor authentication. This product generates a random RADIUS token for each account and updates the token at intervals of 30s or 60s. Dedicated hardware or software is required for users to obtain the token. iMaster NCE-Campus supports two-factor authentication, that is username and password and RADIUS token, to enhance security.
Procedure
- Choose from the main menu and click Create to configure a RADIUS token server interconnected with iMaster NCE-Campus. After all settings are complete, click OK.
![]()
- Customize a portal page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a user-defined template. In this example, select User Name and Password Template as the system template.![]()
- In the page editing area, select an authentication page, select page controls, and customize a portal page by using the two-factor (AD and RSA) control. Delete unnecessary controls from the template and click Save and Release.
![]()
- Choose from the main menu to configure an authentication rule. Here, you need to toggle Two-factor authentication on, set Two-factor authentication type to Two-factor access, and set Second data source type to RADIUS Token.
![]()
- Configure an authorization rule, authorization result, and access point. For details, see Portal Authentication.
Two-Factor Authentication Using an SSL VPN-Enabled Firewall
Context
SSL VPN is a remote access technology over the Virtual Private Network (VPN) that uses the Security Socket Layer (SSL) protocol to enhance security. SSL VPN allows mobile office staff to connect to the intranet of an enterprise to access resources on the intranet.
Remote users access an enterprise intranet through SSL VPN must pass identity authentication. If an enterprise has high security requirements, two-factor authentication can be used to implement a secondary authentication.
Pre-configuration Tasks
- An SMS server has been deployed in advance.
- The firewall has been connected to iMaster NCE-Campus or a third-party RADIUS server and has been enabled with SSL VPN.
Procedure
- Choose from the main menu, click the Admission device tab. On the page that is displayed, click Create to add the firewall to the access control device group and set RADIUS parameters. The RADIUS parameters must be the same as those configured on the firewall.
![]()
- Choose from the main menu to configure an authentication rule. Here, you need to toggle Two-factor authentication on, set Two-factor authentication type to FW SSL VPN access, and set Second data source type to Dynamic password (SMS message).
![]()
- For details about how to configure an authentication rule, authorization rule, and authorization result, see 802.1X Authentication.
- Authentication device configuration needs to be performed on firewalls through the CLI or web system. The following describes the configuration procedure on the firewall's web system:
- Configure interfaces and security policies.
- Choose to configure a RADIUS server.
- Choose to create an authentication domain.
- Use a CSV file to import users and user groups.
- Choose .
- In Local Import, click CSV Template Download to download the CSV template to the administrator PC.
- Fill in the user information stored on the RADIUS server in the CSV file template. Read the comments in the CSV file template and follow the requirements when filling in the information. The following figure shows a completed CSV file.
- Click Browse, select the edited CSV file, click Open, and set the parameters as follows.
- Click Start Import. After the import succeeds, the user and user group information can be viewed on the firewall's web system.
- Choose to configure the SSL VPN gateway by setting parameters including the gateway IP address, user authentication mode, and maximum number of concurrent users. Enable the Web Proxy and Network Extension service functions, and set related parameters. In List of Authorized Roles, configure SSL VPN role authorization/users. Alternatively, you can use the default configuration. This configuration attaches different roles to users or user groups to authorize different permissions to them.
For details, see the sections related to SSL VPN in the corresponding firewall product documentation.
iMaster NCE-Campus as a Relay Agent
Enabling the RADIUS Port
Context
UDP is used when iMaster NCE-Campus functions as a RADIUS relay agent for authentication. However, this protocol is not an encryption protocol and may pose security risks. Therefore, the ports using UDP are disabled by default. If iMaster NCE-Campus functions as a relay agent for authentication, the RADIUS port needs to be enabled on the management plane.
Procedure
- Log in to the management plane.
- Choose from the main menu, click , set ENABLE_RADIUS_PORT(enable radius relay port or not) to true, and click OK.
- (Optional) In the four-plane installation scenario, the internal communication plane, northbound plane, southbound plane, and service plane are isolated from each other, and the RADIUS server is reachable only through the northbound plane. In this case, set ENABLE_RADIUS _NORTH(enable listen radis relay port on north ip or not) to true and click OK. Then, set Source to Northbound plane when creating a RADIUS relay template on the page.
- Click
![]()
in the upper right corner to check whether the configuration is successful.![]()
- Wait for about 10 minutes, choose from the main menu, click the Service tab, and search for CampusAccesscfgService and PortalServerService. Check whether CampusAccesscfgService and PortalServerService are successfully restarted. If the services are running properly, configure other parameters for RADIUS authentication with the controller as a relay agent.
in the upper right corner to check whether the configuration is successful.
Portal Authentication
Connecting to a Third-Party Portal Server in API Mode
Configuring a Portal Page Pushing Rule
If iMaster NCE-Campus is used as a relay server, you need to configure portal page pushing rules. iMaster NCE-Campus pushes a specified portal page to end users based on portal page pushing rules.
Context
iMaster NCE-Campus provides default pages of various authentication modes, such as the authentication page and authentication success page. Tenant administrators can configure portal page pushing rules to determine the portal pages to be pushed to end users. If the default pages do not meet the requirements, you can customize pages as needed.
If multiple portal page pushing rules are configured, the portal page pushing policy with the smallest priority value has the highest priority. If the high-priority portal page pushing rule is matched, other policies are not matched.
Procedure
- Choose from the main menu.
- Click Create to create a portal page pushing policy.
Parameter Description
Parameter |
Description |
|---|---|
Push Rule |
Push condition. A specified page is pushed for the portal authentication request that meets the pushing condition. If all the pushing conditions are not set, a portal page is pushed to all devices at the selected site. If multiple conditions are set, portal authentication requests match portal page pushing rules when they met all the conditions. |
Authentication mode |
Authentication mode. The portal page to be pushed is selected based on the authentication mode. During page customization, different login modes require different page elements. |
Push page |
Portal page to be pushed. The portal page to be pushed is selected based on the authentication mode. When the default pushed page of the system cannot meet the requirement, you can customize a portal page as prompted. Each set of portal pages to be pushed contains an authentication page, user notice page, and registration page. A tenant administrator can specify one of them as the first page to be pushed. |
First page to push |
Portal page to be pushed to users upon first login. The options are as follows:
|
Page displayed after successful authentication |
Page displayed after a user is authenticated.
NOTE:
In the UC browser of the HD type, the redirected URL can only be an HTTP URL. If Push mode is set to Fast for the desired portal page when you configure an authentication point, end users cannot be redirected to a specified URL.
|
Configuring an Authentication Point
Context
iMaster NCE-Campus functions as a relay server to connect to a third-party server.
When using a third-party authentication server for admission and authentication, ensure that the third-party server, account policies, and password complexity meet the default security requirements and the anti-brute force cracking and anti-DoS mechanisms are complete.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Open network, Push pages to ON, Page pusher to Relay authentication by cloud platform, and Interconnection mode to API.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- On the Wired Authentication page or Wireless Authentication page, set Authentication mode to Open network, Page pusher to Relay authentication by cloud platform, and Interconnection mode to API.NOTE:
Wireless authentication needs to be configured in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
WAC
- Choose from the navigation pane. Click add and configure authentication.
- Set Authentication mode to Open network, Page pusher to Relay authentication by cloud platform, and Interconnection mode to API.NOTE:
WAC configuration needs to be performed in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Configuring an Authorization Result
Context
When you configure portal authentication, 802.1X authentication, and MAC address authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
When you configure device administrator authentication, an authorization result defines the rights assigned to authenticated end users and traffic rate limiting and filtering policies for them. This configuration applies to the scenario where a FW, an AR, an AP, an LSW, or a WAC functions as an authentication point. An authorization result can be configured for a specific user group.
iMaster NCE-Campus provides two default authorization results: Permit Access and Deny Access. The two results are bound to all sites to form default templates, which cannot be modified or deleted.
The rights assigned to an authenticated end user are specified by an authorization result. The permissions involve the destination IP address, protocol, and port defined by an ACL, URL permitted or rejected, and uplink or downlink bandwidth of terminals.
SSID-based policy control indicates that the STA connected to an SSID has the corresponding rights. The set of rights specified in an authorization result is dynamically authorized according to the matching policy after an end user is authenticated. The rights assigned to an end user include those specified both in an SSID and an authorization result.
Procedure
- Choose from the main menu.
- Click Create to create an authorization result. Parameters in an authorization result vary with the device type. For details about the parameters, see Parameter Description at the end of this section.
![]()
- Click OK to bind the authorization result to sites. You can also select an authorization result, click
![]()
, and select desired sites to bind them to the result.![]()
Parameter Description
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring an Authorization Rule
When iMaster NCE-Campus authorizes authenticated users, it grants specific permissions only to the users who hit the specified authorization rules.
iMaster NCE-Campus provides a default authorization rule default with the authorization result Deny Access. You can modify the authorization result in this default template as required.
Context
Authorization results define the rights assigned to authenticated end users. Each authentication rule corresponds to an authentication result. If an authenticated end user matches an authentication rule, the corresponding authorization result applies to the user. If no authorization rule is set, an authorization result is applicable to all authenticated terminals.
Procedure
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to user access authentication. When iMaster NCE-Campus interworks with a third-party device to authenticate users, users will fail to match the authorization rule if the authorization rule defines user authorization based on sites, access device types, or devices.
![]()
Related Operations
- Setting the priority of an authorization rule
The priority value of the first authorization rule is 1 and the priority values of subsequent authorization rules increase by 1. The smaller the priority value, the higher the priority. The default authorization rule has the lowest priority. You can set the priority of an authorization rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server belongs to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on accounts. |
||
Role Information |
Authenticated users are authorized based on roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. |
||
Region |
Authenticated users are authorized based on regions. |
||
Protocol Information |
Enable protocol matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported:
|
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, and FW. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on regions. |
||
Region |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Protocol Information |
Enable protocol information matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported: EEAP-MD5 protocol (Local account) EAP-PEAP-MSCHAPv2 protocol (Local account, AD, and LDAP) EAP-TLS protocol (Local account, AD, LDAP) EAP-PEAP-GTC protocol (Local account, AD, LDAP, and RADIUS Token) EAP-TTLS-PAP protocol (Local account, AD, and LDAP) |
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
The Authentication Terminal Has Been Added to the AD Domain |
Whether authenticated users using terminals that have been added to AD domains have been authorized. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, and WAC. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Region |
Authenticated users are authorized based on regions. |
||
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
Admission Device Group |
Authenticated users are authorized based on access device groups. |
|
Region |
Authenticated users are authorized based on regions. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Connecting to a Third-Party Portal Server via a RADIUS Relay Agent
Configuring a Portal Page Pushing Rule
If iMaster NCE-Campus is used as a relay server, you need to configure portal page pushing rules. iMaster NCE-Campus pushes a specified portal page to end users based on portal page pushing rules.
Context
iMaster NCE-Campus provides default pages of various authentication modes, such as the authentication page and authentication success page. Tenant administrators can configure portal page pushing rules to determine the portal pages to be pushed to end users. If the default pages do not meet the requirements, you can customize pages as needed.
If multiple portal page pushing rules are configured, the portal page pushing policy with the smallest priority value has the highest priority. If the high-priority portal page pushing rule is matched, other policies are not matched.
Procedure
- Choose from the main menu.
- Click Create to create a portal page pushing policy.
Parameter Description
Parameter |
Description |
|---|---|
Push Rule |
Push condition. A specified page is pushed for the portal authentication request that meets the pushing condition. If all the pushing conditions are not set, a portal page is pushed to all devices at the selected site. If multiple conditions are set, portal authentication requests match portal page pushing rules when they met all the conditions. |
Authentication mode |
Authentication mode. The portal page to be pushed is selected based on the authentication mode. During page customization, different login modes require different page elements. |
Push page |
Portal page to be pushed. The portal page to be pushed is selected based on the authentication mode. When the default pushed page of the system cannot meet the requirement, you can customize a portal page as prompted. Each set of portal pages to be pushed contains an authentication page, user notice page, and registration page. A tenant administrator can specify one of them as the first page to be pushed. |
First page to push |
Portal page to be pushed to users upon first login. The options are as follows:
|
Page displayed after successful authentication |
Page displayed after a user is authenticated.
NOTE:
In the UC browser of the HD type, the redirected URL can only be an HTTP URL. If Push mode is set to Fast for the desired portal page when you configure an authentication point, end users cannot be redirected to a specified URL.
|
Configuring a RADIUS Relay Template
Procedure
- Choose from the main menu, and select RADIUS Relay Template.
- Click Create, set parameters, and click OK.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS relay server template. |
|
Portal Authentication |
Authentication server address |
Click Add, and configure the priority, IP address, port, and key information about the authentication server. You can add up to three authentication servers. |
Authentication protocol |
Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). CHAP is more secure and recommended. |
|
NAS-Identifier |
NAS identifier attribute carried in RADIUS relay packets.
|
|
Accounting server address |
Click Add, and configure the priority, IP address, port, and key information about the accounting server. You can add up to three accounting servers. |
|
Timeout period |
Negotiation time for connection to the authentication server and accounting server. After the timeout period is exceeded, the current connection fails. |
|
Resend tries |
Number of times a client connects to the authentication server and accounting server. |
|
Load balancing mode |
Policy specifying the server to which clients connect if multiple authentication servers or accounting servers are configured.
|
|
MAC address formatting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
RADIUS Authentication |
Authentication server address |
Click Add, and configure the priority, IP address, port, and key information about the authentication server. You can add up to three authentication servers. |
Accounting server address |
Click Add, and configure the priority, IP address, port, and key information about the accounting server. You can add up to three accounting servers. |
|
Timeout period |
Negotiation time for connection to the authentication server and accounting server. After the timeout period is exceeded, the current connection fails. |
|
Resend tries |
Number of times a client connects to the authentication server and accounting server. |
|
Load balancing mode |
Policy specifying the server to which clients connect if multiple authentication servers or accounting servers are configured.
|
|
MAC prioritization |
In Portal 2.0 relay authentication scenarios, MAC address-prioritized portal authentication can be configured in the following modes:
When MAC address-prioritized authentication packets are forwarded to an external RADIUS server, data source check for MAC address-prioritized portal authentication can be configured. After MAC address-prioritized portal authentication and the corresponding data source check are enabled, the controller checks whether the data source of an authentication packet is the same as that of the previously received one. If they are the same, the controller relays the packet to the desired RADIUS server. If the data source check is not enabled, the controller sends authentication packets to the same data source as previous ones. |
|
Advanced |
In a RADIUS relay scenario, authorization information contains the authorization result of the relay server. Dynamic authorization cannot be directly performed by the controller. Dynamic authorization needs to be triggered on the relay server. Transfer authorization results: The controller forwards authorization results from the external RADIUS server to target devices. Incremental authorization: The attributes in the packets returned by the external RADIUS server are used as conditions to match authorization rules, and the matched authorization result is applied. Conditional authorization: The device uses the attributes in the packets returned by the external RADIUS server as authorization conditions to match authorization rules and delivers the authorization result bound to the authorization rules to the device. |
|
Configuring an Authentication Point
Context
iMaster NCE-Campus functions as a relay server and connects to a third-party authentication server.
When using a third-party authentication server for admission and authentication, ensure that the third-party server, account policies, and password complexity meet the default security requirements and the anti-brute force cracking and anti-DoS mechanisms are complete.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Open network, Push pages to ON, Page pusher to Relay authentication by cloud platform, and Interconnection mode to RADIUS relay.
- Set the user name and password required for third-party portal authentication and select a RADIUS relay server.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- On the Wired Authentication page or Wireless Authentication page, set Authentication mode to Open network, Page pusher to Relay authentication by cloud platform, and Interconnection mode to RADIUS relay.
- Set the user name and password required for third-party portal authentication and select a RADIUS relay server.NOTE:
Wireless authentication needs to be configured in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
WAC
- Choose from the navigation pane. Click add and configure authentication.
- Set Authentication mode to Open network, Page pusher to Relay authentication by cloud platform, and Interconnection mode to RADIUS relay.
- Set the user name and password required for third-party portal authentication and select a RADIUS relay server.NOTE:
WAC-side configuration needs to be performed in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
RADIUS Authentication
Configuring a RADIUS Relay Template
Procedure
- Choose from the main menu, and select RADIUS Relay Template.
- Click Create, set parameters, and click OK.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS relay server template. |
|
Portal Authentication |
Authentication server address |
Click Add, and configure the priority, IP address, port, and key information about the authentication server. You can add up to three authentication servers. |
Authentication protocol |
Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). CHAP is more secure and recommended. |
|
NAS-Identifier |
NAS identifier attribute carried in RADIUS relay packets.
|
|
Accounting server address |
Click Add, and configure the priority, IP address, port, and key information about the accounting server. You can add up to three accounting servers. |
|
Timeout period |
Negotiation time for connection to the authentication server and accounting server. After the timeout period is exceeded, the current connection fails. |
|
Resend tries |
Number of times a client connects to the authentication server and accounting server. |
|
Load balancing mode |
Policy specifying the server to which clients connect if multiple authentication servers or accounting servers are configured.
|
|
MAC address formatting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
RADIUS Authentication |
Authentication server address |
Click Add, and configure the priority, IP address, port, and key information about the authentication server. You can add up to three authentication servers. |
Accounting server address |
Click Add, and configure the priority, IP address, port, and key information about the accounting server. You can add up to three accounting servers. |
|
Timeout period |
Negotiation time for connection to the authentication server and accounting server. After the timeout period is exceeded, the current connection fails. |
|
Resend tries |
Number of times a client connects to the authentication server and accounting server. |
|
Load balancing mode |
Policy specifying the server to which clients connect if multiple authentication servers or accounting servers are configured.
|
|
MAC prioritization |
In Portal 2.0 relay authentication scenarios, MAC address-prioritized portal authentication can be configured in the following modes:
When MAC address-prioritized authentication packets are forwarded to an external RADIUS server, data source check for MAC address-prioritized portal authentication can be configured. After MAC address-prioritized portal authentication and the corresponding data source check are enabled, the controller checks whether the data source of an authentication packet is the same as that of the previously received one. If they are the same, the controller relays the packet to the desired RADIUS server. If the data source check is not enabled, the controller sends authentication packets to the same data source as previous ones. |
|
Advanced |
In a RADIUS relay scenario, authorization information contains the authorization result of the relay server. Dynamic authorization cannot be directly performed by the controller. Dynamic authorization needs to be triggered on the relay server. Transfer authorization results: The controller forwards authorization results from the external RADIUS server to target devices. Incremental authorization: The attributes in the packets returned by the external RADIUS server are used as conditions to match authorization rules, and the matched authorization result is applied. Conditional authorization: The device uses the attributes in the packets returned by the external RADIUS server as authorization conditions to match authorization rules and delivers the authorization result bound to the authorization rules to the device. |
|
Configuring an Authentication Point
Context
iMaster NCE-Campus functions as a relay server and connects to a third-party authentication server.
When using a third-party authentication server for admission and authentication, ensure that the third-party server, account policies, and password complexity meet the default security requirements and the anti-brute force cracking and anti-DoS mechanisms are complete.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Secure network, select an encryption mode, and enable the built-in RADIUS server using a RADIUS template.
WAC
- Choose from the navigation pane. Click add and configure authentication.
- Set Authentication mode to Secure network, and enable the built-in RADIUS server using a RADIUS template.NOTE:
WAC configuration needs to be performed in the WAC's web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- Set Authentication mode to Secure network and enable the built-in RADIUS server using a RADIUS template.
NOTE:
Wireless authentication needs to be configured in the WAC's web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Configuring an Authentication Rule
Authentication rules can be configured to authenticate clients and users on the network to ensure network security.
Context
You can configure multiple authentication rules to generate an authentication scheme. An authentication scheme defines the authentication rules used for user authentication. If multiple authentication schemes are configured, the authentication scheme with the smallest priority value has the highest priority. If the high-priority authentication scheme is matched, other schemes are not matched.
Procedure
- Choose from the main menu.
- Click Create. On the page that is displayed, select Wired or Wireless, select User access authentication, MAC Address Authentication, or Device administrator authentication, and configure an authentication rule. In addition, configure the RADIUS relay function and specify a RADIUS relay server.
Related Operations
- Setting the priority of an authentication rule
The priority value of the first authentication rule is 1 and the priority values of subsequent authentication rules increase by 1. The smaller the priority value, the higher the priority. The default authentication rule has the lowest priority. You can set the priority of an authentication rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, firewall, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. Currently, two methods are available: two-factor authentication using accounts and SMS verification code or RADIUS tokens, and two-factor authentication using SSL VPN-enabled firewalls. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. The RADIUS token factor is supported only when the two-factor authentication method is used. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
PAP must be enabled when LDAP accounts are used for Portal 2.0 authentication, FW SSL VPN authentication, and MAC address authentication. In addition, CHAP must be enabled for Portal 2.0 authentication. If iMaster NCE-Campus functions as an authentication server in other services, enable the required protocol. One of the EAP-MD5, EAP-PEAP-MSCHAPv2, EAP-TLS, EAP-PEAP-GTC, and EAP-TTLS-PAP protocols can be specified as the preferential protocol used for authentication. This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
User authentication based on user groups to which MAC accounts are mapped. |
MAC account |
User authentication based on MAC accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows: PAP protocol (local account, AD, LDAP, RADIUS Token, Third-party HTTP server, Third-party Database) CHAP protocol(Local account, Third-party Database) |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Admission device group |
User authentication based on access device groups. |
|
Terminal IP range |
User authentication based on terminal IP addresses. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Device IP address, access VLAN, access port, user MAC address, user IP address, user IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Interconnection with a Third-Party Authentication Server
Connecting to a Portal Server
Configuring a Third-Party Portal Template
Context
To simplify configurations and facilitate unified management, iMaster NCE-Campus provides diversified templates where you can set multiple parameters. When configuring related services, you can set required parameters for configuration objects using templates.
Procedure
- Choose from the main menu, and select Portal Server.
- Click Create, set parameters, and click OK.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Name |
Unique identifier of the portal server template. |
Using Built-in Server |
Specify iMaster NCE-Campus as the portal server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the authentication component. The SM is the controller deployed at the headquarters. The default protocol for pushing portal pages is HTTPS. To use HTTP, enable the HTTP port. |
IP address |
IP address of a third-party portal server. Use commas (,) to separate multiple IP addresses. |
Port |
Port of a third-party portal server. |
URL |
Interface URL of a third-party portal server. |
Portal user synchronization |
Whether to synchronize user information between devices and iMaster NCE-Campus. You can enable this function when Portal 2.0 authentication is configured. The synchronization interval and maximum allowable number of synchronization failures can be set. The synchronization interval is in the range from 30 to 65535, in seconds, and its default value is 300. The maximum allowable number of synchronization failures is in the range from 2 to 255 and its default value is 3. The synchronization interval multiplied by the maximum allowable number of synchronization failures must be greater than the interval at which the portal server sends synchronization packets to devices. Otherwise, devices will log out users if they do not receive any synchronization packet from the portal server after the maximum allowable number of synchronization failures is reached. The built-in portal server of iMaster NCE-Campus sends synchronization packets at an interval of 3600 seconds. |
Key |
Shared key of a portal server. |
URL parameter profile |
URL template (with related parameters specified) associated with a portal server. If an SSID is associated with a Portal server template, the SSID is also associated with this URL template. |
Configuring a Third-Party RADIUS Template
Context
When configuring related services, you can set required parameters for configuration objects using templates
Procedure
- Choose from the main menu, and select RADIUS Server.
- Click Create, set parameters, and click OK.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS server template. |
|
Using Built-in Server |
Whether to configure iMaster NCE-Campus as a RADIUS server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
|
Authentication server |
Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight authentication servers can be added. |
|
Accounting server |
Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight accounting servers can be added. |
|
Authentication component |
This parameter needs to be set only when Using Built-in Server is enabled. The authentication component can be the Service Manager (SM) or a remote server. The SM is the headquarters controller. |
|
Server selection policy |
|
|
Server selection algorithm |
|
|
Real-time accounting |
Whether to enable real-time accounting. After this function is enabled, you can configure a real-time accounting interval. By default, this function is disabled. |
|
Billing reporting cycle |
Real-time accounting interval. |
|
Key |
Shared key of the RADIUS server. You are advised to periodically change the shared key. |
|
Disable RADIUS attributes |
Whether to filter specific attributes in the packets exchanged between the device and the RADIUS server. The default value is OFF, indicating that specific attributes are not filtered. |
|
Disable attributes |
- |
Click Create and configure a filtering policy. |
Attribute name |
Click ... and select the names of attributes to be filtered in the displayed dialog box. |
|
Prohibit Sending |
The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server. |
|
Prohibit Receiving |
The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server. |
|
Service-Type |
- |
The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server. |
Attribute value |
Specifies the value of service-type attribute to be modified. |
|
Option |
Sets the user authentication mode to MAC address authentication. |
|
called-station-id |
- |
After this function is enabled, you can set the called-station-id attribute value, which specifies content encapsulated in the called-station-id attribute of RADIUS packets. Currently, only APs support this function. By default, this function is disabled. |
Attribute value |
Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location. |
|
Carry SSID attributes |
After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled. |
|
Attribute separator |
Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains the SSID. The value is of enumerated type, and can be \, /, :, <, >, |, @, ', %, *, +, -, &, !, #, ^, and ~. The default value is :. |
|
Mac address format setting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
Server status auto-detection |
Username |
Username for automatic RADIUS server detection. |
Password |
Password for automatic RADIUS server detection. |
|
Retransmit authentication requests |
Retransmission count |
Number of retransmission times if an authentication request times out. |
Timeout interval |
Timeout interval of an authentication request. |
|
Server down duration |
Period during which the authentication server remains Down. |
|
Configuring an Authentication Point
Context
To use a third-party server for authentication, you need to select the corresponding third-party service on iMaster NCE-Campus when configuring authentication and specify the third-party server address using a specific template.
When using a third-party authentication server for admission and authentication, ensure that the third-party server, account policies, and password complexity meet the default security requirements and the anti-brute force cracking and anti-DoS mechanisms are complete.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Open network, Push pages to ON, Page pusher to Third-party authentication, and specify a third-party portal server and RADIUS server using templates.
- (Optional) Configure Portal authentication-free, Default permit rule, and Escape policy as required.NOTE:
Portal authentication-free and Escape policy are supported only in V200R009C00 and later versions.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- On the Wired Authentication page or Wireless Authentication page, set Authentication mode to Open network, Page pusher to Third-party authentication, and specify a third-party portal server and RADIUS server using templates.
- (Optional) Configure Portal authentication-free, Default permit rule, and Escape policy as required.NOTE:
Wireless authentication needs to be configured in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Firewall
- Choose from the navigation pane.
- Set Push page (Portal authentication) to ON, and configure portal authentication.
- Set the Page pusher to Third-party authentication and specify a third-party portal server and RADIUS server using templates.
Connecting to a RADIUS Server
Configuring a Third-Party RADIUS Template
Context
When configuring related services, you can set required parameters for configuration objects using templates
Procedure
- Choose from the main menu, and select RADIUS Server.
- Click Create, set parameters, and click OK.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS server template. |
|
Using Built-in Server |
Whether to configure iMaster NCE-Campus as a RADIUS server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
|
Authentication server |
Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight authentication servers can be added. |
|
Accounting server |
Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight accounting servers can be added. |
|
Authentication component |
This parameter needs to be set only when Using Built-in Server is enabled. The authentication component can be the Service Manager (SM) or a remote server. The SM is the headquarters controller. |
|
Server selection policy |
|
|
Server selection algorithm |
|
|
Real-time accounting |
Whether to enable real-time accounting. After this function is enabled, you can configure a real-time accounting interval. By default, this function is disabled. |
|
Billing reporting cycle |
Real-time accounting interval. |
|
Key |
Shared key of the RADIUS server. You are advised to periodically change the shared key. |
|
Disable RADIUS attributes |
Whether to filter specific attributes in the packets exchanged between the device and the RADIUS server. The default value is OFF, indicating that specific attributes are not filtered. |
|
Disable attributes |
- |
Click Create and configure a filtering policy. |
Attribute name |
Click ... and select the names of attributes to be filtered in the displayed dialog box. |
|
Prohibit Sending |
The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server. |
|
Prohibit Receiving |
The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server. |
|
Service-Type |
- |
The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server. |
Attribute value |
Specifies the value of service-type attribute to be modified. |
|
Option |
Sets the user authentication mode to MAC address authentication. |
|
called-station-id |
- |
After this function is enabled, you can set the called-station-id attribute value, which specifies content encapsulated in the called-station-id attribute of RADIUS packets. Currently, only APs support this function. By default, this function is disabled. |
Attribute value |
Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location. |
|
Carry SSID attributes |
After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled. |
|
Attribute separator |
Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains the SSID. The value is of enumerated type, and can be \, /, :, <, >, |, @, ', %, *, +, -, &, !, #, ^, and ~. The default value is :. |
|
Mac address format setting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
Server status auto-detection |
Username |
Username for automatic RADIUS server detection. |
Password |
Password for automatic RADIUS server detection. |
|
Retransmit authentication requests |
Retransmission count |
Number of retransmission times if an authentication request times out. |
Timeout interval |
Timeout interval of an authentication request. |
|
Server down duration |
Period during which the authentication server remains Down. |
|
Configuring an Authentication Point
Context
To use a third-party server for authentication, you need to select the corresponding third-party service on iMaster NCE-Campus when configuring authentication and specify the third-party server address using a specific template.
When using a third-party authentication server for admission and authentication, ensure that the third-party server, account policies, and password complexity meet the default security requirements and the anti-brute force cracking and anti-DoS mechanisms are complete.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Configure authentication points based on the device type.
Authentication Point
Configuration Procedure
AP
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- On the Security Authentication page, set Authentication mode to Secure network, select an encryption mode, and specify a RADIUS server using a template.
Switch
- Choose from the navigation pane. On the Wired Authentication or Wireless Authentication tab page, click Create.
- On the Security Authentication page, set Authentication mode to Secure network, select an encryption mode, and specify a RADIUS server using a template.
- (Optional) Configure Portal authentication-free, Default permit rule, and Escape policy as required.NOTE:
Wireless authentication needs to be configured in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
HWTACACS Authentication
Overview
Introduction
Huawei Terminal Access Controller Access Control System (HWTACACS) is an encryption authentication protocol. Similar to RADIUS, HWTACACS uses the client/server model to implement communication between NAS and HWTACACS servers.
HWTACACS is used to perform authentication, authorization, and accounting for users accessing the Internet through Point-to-Point Protocol (PPP) or Virtual Private Dial-up Network (VPDN) and administrative users logging in to devices. For example, an HWTACACS server can be configured to perform authentication, authorization, and accounting for administrative users logging in to a device. The device functions as an HWTACACS client to send the usernames and passwords of the administrative users to the HWTACACS server. The authorized users can log in to the device and perform operations.
- If only HWTACACS authentication is configured on devices (HWTACACS clients), when the HWTACACS server is faulty and cannot provide services, you have to log in to the devices using the console port. If HWTACACS authentication is also configured on the console port, you need to configure the bypass function to ensure that users can log in to the devices (HWTACACS clients) even if the HWTACACS server fails.
- HWTACACS authentication is not supported in the NAT scenario.
Authentication Process
The following describes how HWTACACS performs authentication, authorization, and accounting for Telnet users. Figure 5-14 shows message exchanges between an HWTACACS client and the HWTACACS server.
- A Telnet user sends a request packet to an HWTACACS client.
- The HWTACACS client sends an Authentication Start packet to the HWTACACS server after receiving the request packet.
- The HWTACACS server sends an Authentication Reply packet to the HWTACACS client to request the user name.
- The HWTACACS client sends a packet to the Telnet user to query the user name after receiving the Authentication Reply packet.
- The Telnet user enters the user name.
- The HWTACACS client sends an Authentication Continue packet containing the user name to the HWTACACS server.
- The HWTACACS server sends an Authentication Reply packet to the HWTACACS client to request the password.
- The HWTACACS client sends a packet to the Telnet user to query the password after receiving the Authentication Reply packet.
- The Telnet user enters the password.
- The HWTACACS client sends an Authentication Continue packet containing the password to the HWTACACS server.
- The HWTACACS server sends an Authentication Reply packet to the HWTACACS client, indicating that the user has been authenticated.
- The HWTACACS client sends an Authorization Request packet to the HWTACACS server.
- The HWTACACS server sends an Authorization Response packet to the HWTACACS client, indicating that the user has been authorized.
- After receiving the Authorization Response packet, the HWTACACS client pushes the device login page to the Telnet user.
- The HWTACACS client sends an Accounting-Request(Start) packet to the HWTACACS server.
- The HWTACACS server sends an Accounting-Response(Start) packet to the HWTACACS client, indicating that the Accounting-Request(Start) packet has been received.
- The Telnet user runs a command.
- The HWTACACS client sends a command authorization request packet to the HWTACACS server.
- The HWTACACS server sends a command authorization response packet to the HWTACACS client, indicating that the command has been authorized.
- After receiving the command authorization response packet, the HWTACACS client pushes the command execution result to the Telnet user.
- The Telnet user requests to terminate the connection.
- The HWTACACS client sends an Accounting-Request(Stop) packet to the HWTACACS server.
- The HWTACACS server sends an Accounting-Response(Stop) packet to the HWTACACS client, indicating that the Accounting-Request(Stop) packet has been received.
Configuration Procedure
To configure HWTACACS, you need to configure a device administrator, shell profile, command set, authentication rule, and authorization rule. The following figure shows the detailed configuration procedure.
Configuring a User Account
Context
The HWTACACS function can be used to authenticate users logging in to devices, authorize users to change passwords, and restrict the commands that users can run after logging in to devices. During authentication, user data can be obtained from the local data source. In this case, the system administrator needs to manually create accounts on or import accounts to iMaster NCE-Campus. Alternatively, user data can be obtained from external data sources, such as AD or LDAP servers. The following example describes how to create a user account if user data is obtained from the local data source. For details about how to connect iMaster NCE-Campus to an AD or LDAP server, see AD/LDAP Synchronization.
Procedure
- Choose from the main menu.
- Click
![]()
to create a user. You can create users one by one.![]()
- Select a user group and click Create to create a user. Ensure that HWTACACS is selected.
![]()
- Click
![]()
to import users and user groups. You can use an Excel template to import users and user groups in batches. - Click
![]()
to export users and user groups. After the export task is created, click OK and choose to view and download the task.
- Click
- Choose from the main menu.
- Click Create to create a role.
![]()
- After the role is created, click
![]()
next to the role, and click Add to attach the role to a user account, guest account, or MAC account.![]()
- Click Import to import roles in batches using an Excel template.
- Click Export All to export information about all roles.
- Click Create to create a role.
to create a user. You can create users one by one.
to import users and user groups. You can use an Excel template to import users and user groups in batches.
to export users and user groups. After the export task is created, click OK and choose Parameter Description
Parameter |
Description |
|
|---|---|---|
User name |
Username and password used by an end user during authentication to connect to a cloud-managed device. |
|
Password |
||
Confirm password |
||
Role |
Role attached to the user. |
|
Email address and phone number of a user. When resetting passwords, a user receives a verification code via an email or an SMS message and sets a new password based on the verification code. |
||
Phone number |
||
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. This parameter does not take effect for HWTACACS authentication access users. |
|
Expiration time |
Time when the user account expires. If this parameter is left empty, the account is valid permanently. |
|
Change password upon next login |
Whether to change the account password upon next login. If this parameter is enabled, users need to change the initial passwords upon next login. This parameter is valid only for portal authentication. This parameter does not take effect for HWTACACS authentication access users. |
|
Login mode |
Portal |
End users are allowed to access networks only through portal authentication. |
802.1X |
End users are allowed to access networks only through 802.1X authentication. |
|
HWTACACS |
End users are allowed to access networks only through HWTACACS authentication. Device administrators can use usernames and passwords configured during the creation to remotely log in to devices for management. |
|
Only mobile certificate authentication is allowed |
After this function is enabled, users can be authenticated only through the EAP-TLS protocol. If the authentication type does not match, the authentication fails. This function can be enabled only when the login mode is set to 802.1X. |
|
RADIUS attribute |
IP address of the access terminal/Subnet Mask |
IP address and mask allocated to a terminal after the terminal is authenticated by the RADIUS server. |
IP address segment of the access terminal |
IP address segment allocated to terminals after successful RADIUS authentication. This parameter applies to the scenario where a gateway functions as a terminal. The gateway allocates IP addresses to connected terminals from this IP address segment through DHCP. |
|
User-defined authorization parameters |
User-defined RADIUS attributes can be configured for terminals. A maximum of 20 user-defined RADIUS attributes can be configured. |
|
Access binding information |
IP address of the bound terminal |
Terminal IP address bound to the user account. |
MAC address of the bound terminal |
Terminal MAC address bound to the user account. The value must be in the format **-**-**-**-**-**, such as 11-11-11-11-11-11. |
|
Bind the ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
IMSI bound to the SIM or USIM card |
International mobile subscriber identity (IMSI) or SIM card number bound to the user account. The value is a string of 1 to 15 digits. IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Binding an Access Device |
IP address of the access device |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
Parameter |
Description |
|---|---|
User group name |
Name of a user group. A user group contains multiple users. When configuring an access control policy, you can specify the user group to which the policy applies. |
Configuring an Authentication Rule
Context
When a device sends a user authentication request that carries user account information to the HWTACACS authentication server, iMaster NCE-Campus, as the authentication server, matches the received request with authentication rules and sends an authentication success or failure response based on the matching result. An authentication rule includes two elements:
- Authentication condition: such as user accounts, user roles, admissioon device groups, terminal IP addresses, and access time range.
- Authentication information: such as user passwords, whether to deny user access, and whether to allow password change. User data can be obtained from the local data source or third-party AD/LDAP servers.
iMaster NCE-Campus has a default authentication rule named default. If this rule applies, users are authenticated using the local data source by default. You can modify the default rule to configure user authentication based on a third-party data source.
Pre-configuration Tasks
If two-factor authentication is used, interworking with the RADIUS token server have been configured.
Procedure
- Choose from the main menu.
- Click Create to create an authentication rule. If users are authenticated based on accounts on iMaster NCE-Campus, select a local data source. Otherwise, select a data source that synchronizes user data from a third-party AD/LDAP server. After all settings are complete, click OK.
![]()
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Authentication condition |
User information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location |
Access site |
User authentication based on sites that users access. |
|
Admission device group |
User authentication based on admission device groups. |
||
Terminal IP address segment |
User authentication based on terminal IP addresses. |
||
Other information |
Time |
User authentication based on time ranges. |
|
Authentication information |
Deny Access |
Whether to deny user access. If this function is enabled, users meeting the conditions are not allowed to log in to devices. |
|
Allow password change |
Whether to allow password changes. If this function is enabled, users authenticated using the local data source can change the login passwords after logging in to devices. |
||
Data source |
Data source used for user authentication. The local data source or a third-party AD or LDAP server can be specified as the data source. |
||
Two-factor authentication |
Whether two-factor authentication is enabled for users who meet the matching conditions. After this function is enabled, a dynamic password is required in addition to the original password. After two-factor authentication is enabled, you need to select a secondary data source and specify the dynamic password length. The secondary data source can only be a RADIUS token server. The dynamic password length must be an integer in the range of 1 to 32. The default value is 6. After two-factor authentication is configured, when you enter a password to log in to a device, you must enter both the password for your account and token verification code, without a space between them. For example, if the password for your account is abcdef and the token verification code is 123456, you can pass the authentication only after entering abcdef123456. |
||
Configuring a Shell Profile and a Command Set
Context
A shell profile defines the permission settings and other authorization parameters, whereas a command set defines commands that can be executed by users. iMaster NCE-Campus can deliver shell profiles and command sets to devices. When configuring an authorization rule, you can specify a shell profile and a command set to grant specific permissions to authorized users. A shell profile defines the privilege level, idle timeout period, and customized attributes.
When iMaster NCE-Campus is connected to a third-party device, if the HWTACACS client uses a custom authorization template, iMaster NCE-Campus matches the authorization request parameters in the custom authorization template with parameters in the received authorization request packets. If they match, iMaster NCE-Campus sends packets containing authorization response parameters to the third-party device.
In the default shell profile provided by iMaster NCE-Campus, the profile type is Shell and the user privilege level is not defined. A user is configured with privilege level 0 after logging in to a device. iMaster NCE-Campus provides two default command sets: one that allows users to run all commands and the other that disables users from running all commands.
The following table lists the attributes that can be customized in a shell profile.
Attribute |
Description |
|---|---|
ftpdir |
Local directory authorized to FTP users. |
callback-line |
ID of the callback line. |
nocallback-verify |
Whether callback verification is required for users. The value 1 indicates that no callback verification is required and the value 0 indicates that callback verification is required. |
autocmd |
Commands that the system automatically execute after a user logs in to a device. |
nohangup |
Whether to disconnect a user who has run the autocmd command. The options are true and false. true indicates that the HWTACACS server does not disconnect the user. false indicates that the HWTACACS server disconnects the user. |
acl |
ID of the ACL rule used for authorization. |
Callback-dialstring |
Callback number. iMaster NCE-Campus can issue the information, such as a mobile number, to the device that shows the information to the user. |
callback-rotary |
ID of the callback rotary group. |
noescape |
Whether to disable users from using escape characters. The options are true and false. true indicates that the HWTACACS server disables users from using escape characters. false indicates that the HWTACACS server enables users to use escape characters. |
timeout |
Timeout interval of online users, in minute. |
Procedure
- Choose from the main menu.
- Click Create to configure a shell profile to specify the user privilege level, idle timeout period, and customized attributes. When iMaster NCE-Campus interconnects with a third-party device, the HWTACACS server uses a custom authorization template for authorization. In this step, you need to set the authorization template type to Custom. After all settings are complete, click OK.
![]()
- Choose from the main menu.
- Click Create to configure a command set to specify the commands that can be executed or cannot be executed by users. After all settings are complete, click OK.
![]()
![]()
- Alternatively, click Import to import command sets in batches using the command set template.
![]()
- Click Export to export the configured command sets in batches.
- Click Create to configure a command set to specify the commands that can be executed or cannot be executed by users. After all settings are complete, click OK.
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Name of a shell profile. |
|
Authorization template type |
Type of the desired authorization template. If iMaster NCE-Campus connects to Huawei devices, select Shell. When iMaster NCE-Campus interconnects with a third-party device, the HWTACACS server uses a custom authorization template for authorization. In this step, you need to set the authorization template type to Custom. |
|
Authorization parameters |
Privilege level |
Privilege level authorized to the device administrator. The value is an integer in the range from 0 to 15. |
Idle period |
Idle timeout period for the device administrator. The value is an integer in the range from 0 to 1440, in minutes. |
|
Custom attribute |
Customized attributes authorized to the device administrator. For details about the attributes that are currently supported, see Table 5-179. |
|
Custom authorization parameters |
Authorization request parameter |
Authorization request parameters carried in requests from a third-party device that interconnects with iMaster NCE-Campus. Do not specify optional parameters in authorization requests for this item. According to the HWTACACS protocol standard, the service parameter is mandatory. |
Authorization response parameter |
Authorization response parameters delivered by the HWTACACS server when the attributes in the authorization request packets match the parameters specified for Authorization request parameters. |
|
Parameter |
Description |
|
|---|---|---|
Name |
Name of a command set. |
|
Permission on commands not listed |
Operation permission on the commands that are not defined in a command set. The options are Allow and Deny. |
|
Command set settings |
Command name |
Command name in a command set. |
Command parameter settings |
Parameters in a command. The same command name can be followed by different parameters with different permissions. The authorization result can be Allow or Deny. Parameters in a command are case sensitive. Each command can contain multiple parameters, separated with commas (,). Parameters have a priority. When you specify a parameter, you can use the character * to represent a random character, the character ^ to represent the start of a parameter, and the character $ to represent the end of a parameter. When a command contains multiple parameters, iMaster NCE-Campus searches and matches the parameters based on their priorities. A smaller priority value indicates a higher priority. For example, the hwtacacs-server template test command is used to create a HWTACACS server template. In this command, test is a variable, the command name is hwtacacs-server, and the parameter is template. If the authorization result is Allow, the device administrator can run the hwtacacs-server template test command. |
|
Permission upon a parameter match failure |
Permission for running a command when parameter matching fails. If a command contains no parameter, the authorization result depends on the value for this field. For example, if this field is set to Allow but parameter matching of a command fails, the device administrator can still run this command. |
|
Configuring an Authorization Rule
Context
After users are authenticated, access devices automatically send authorization requests to the HWTACACS server. As an authorization server, iMaster NCE-Campus matches user access information against configured authorization rules and sends an authorization success or failure response that carries the authorization result to users.
If no authorization rule is defined on iMaster NCE-Campus or a user does not match any authorization rule, the default authorization rule applies. In this rule, the default shell profile is used in the authorization result and users cannot execute any command in the command set.
Procedure
- Choose from the main menu.
- Click Create to create an authorization rule, and specify a shell profile and a command set in the authorization result. After all settings are complete, click OK.
![]()
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Authorization condition |
User information |
User group |
Authenticated users are authorized based on user groups. |
Account |
Authenticated users are authorized based on user accounts. |
||
Role |
Authenticated users are authorized based on user roles. |
||
Location |
Access site |
Authenticated users are authorized based on the sites that they access. |
|
Admission device group |
Authenticated users are authorized based on admission device groups. |
||
Terminal IP address range |
Authenticated users are authorized based on terminal IP addresses. |
||
Other information |
Time |
Authenticated users are authorized based on time ranges. |
|
Authorization result |
Name of the authorization result that takes effect after authentication. You need to specify a shell profile and a command set. |
||
Configuring an Admission Device
Context
After an HWTACACS server is configured, you need to configure admissiono devices so that users can access the network through HWTACACS authentication. Currently, iMaster NCE-Campus can deliver HWTACACS authentication server configurations to Huawei switches and APs only. When configuring an HWTACACS server template, you can select the built-in server to configure iMaster NCE-Campus as a HWTACACS server, or select a third-party HWTACACS server.
Procedure
- Configure an HWTACACS server template. The following example configures iMaster NCE-Campus as an HWTACACS server.
- Choose from the main menu, and select HWTACACS Server.
- Click Create, set parameters, and click OK.
![]()
- Configure a device administrator.
- Choose from the main menu.
- Select a site from the Site drop-down list in the upper left corner.
- Choose on the Site Configuration tab page.
- Click
![]()
next to Device Administrator and set parameters.![]()
next to 
Follow-up Procedure
- A user logs in to an admission device using console, or Telnet, or SSH. For example, if the username is tacacs and the password is 12345, the device administrator can use the username and password to log in to the admission device. You can view user login and logout logs on the page.
- A user runs a command on an admission device to check whether the assigned rights are the same as those in the specified shell profile and command set. For example, the command set specifies that only the display commands are allowed. When the user runs a command other than display commands, the system displays a message indicating that the authentication fails.
Error: Failed to pass the authorization.
You can view authorized commands in command logs on the page.
Parameter Description
Parameter |
Description |
|---|---|
Name |
Unique identifier of an HWTACACS server template. |
Using Built-in Server |
Whether to configure iMaster NCE-Campus as an HWTACACS server. If this function is enabled, you can configure either the SM or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
Primary authentication server IP address/Port |
IP address and port number of the primary and secondary authentication servers. NOTE:
If the IP address and port number of the master authentication server is configured and the IP address and port number of the master authorization server is not configured, the user only has the default permission of the device, which can be referred to in the product documentation of the device. |
Secondary authentication server IP address/Port |
|
Primary authorization server IP address/Port |
IP address and port number of the primary and secondary authorization servers. |
Secondary authorization server IP address/Port |
|
Primary accounting server IP address/Port |
IP address and port number of the primary and secondary accounting servers. |
Secondary accounting server IP address/Port |
|
Domain name included |
By default, this field is disabled. Whether the domain name is included in the username carried in request packets sent by devices to the HWTACACS server. If this function is enabled, the domain name is included in the username and the default domain name is default_admin. If this function is disabled, devices do not encapsulate the domain name in the username when sending packets to an HWTACACS server. |
Key |
Shared key of the HWTACACS server. |
Parameters |
Description |
|
|---|---|---|
Local user |
User name |
User name for logging in to a device. The password must meet the following requirements:
|
Password |
Password of the user account. The password must meet the following requirements:
|
|
Role |
Priority of a local user. After uses of different levels log in to a device, they can use only the commands of the same or a lower level than their own levels.
|
|
Service type |
Access mode of a local user.
|
|
BootROM password |
BootROM password of a switch or an AP. If you do not set this password, the administrator password and BootROM password that take effect are those set by tenant administrators when they log in to iMaster NCE-Campus for the first time, or those set in the Device Password Configuration area on the Device Management tab page under . NOTE:
If the system administrator disables The device BootROM password can be configured, tenants cannot change BootROM passwords of devices. For details about how to disable tenants from changing BootROM passwords of devices, see Configuring a BootROM Password Policy. |
|
Device login timeout interval (min) |
Period after which a user is disconnected from the user interface. The value is 10 by default. The value 0 indicates that this function is disabled. |
|
Number of lines displayed on each screen |
Number of rows printed on a split screen. The value is 24 by default. The value 0 indicates that this function is disabled. |
|
Login restriction |
Whether to restrict login to devices via SSH. You can bind SSH virtual type terminal (VTY) accounts of devices to specified advanced ACLs to restrict the accounts that are allowed to log in to devices via SSH. Only APs and switches support this function. The available ACL numbers are in the range from 3032 to 3999. |
|
HWTACACS Authentication |
- |
Whether to enable the HWTACACS authentication mode for the devices at the current site. NOTE:
HWTACACS authentication cannot be disabled if a switch supports login through a console port. |
HWTACACS Server |
Select an HWTACACS server from the drop-down list box. The server has been defined on the Policy Template page. |
|
Command line authorization |
You can set this parameter as needed. This function is optional when the controller functions as an HWTACACS authentication server. If the controller functions as an HWTACACS authorization server to authorize command lines to device users, you need to configure a command set and enable this function. |
|
HWTACACS bypass |
Bypass policy after an HWTACACS server authentication or authorization failure.
|
|
RADIUS Authentication |
RADIUS server |
RADIUS server configured in the desired RADIUS server template. The RADIUS server template is defined on the policy template page. |
Authentication protocol |
RADIUS authentication protocol. PAP and CHAP are supported. |
|
RADIUS authentication bypass |
|
|
Device Administrator Authentication
Overview
Context
The device administrator authentication feature allows device administrators to log in to devices and run commands only after they enter the correct username and password to the pass authentication. Device administrators can be assigned with different permissions to run permitted commands. The authentication server can be a HWTACACS server or a RADIUS server. If you want to use a HWTACACS server, see HWTACACS Authentication for the detailed authentication configuration. If a RADIUS server is used for device management authentication, it fits in various access scenarios, is easy to use, and enhances device login security and authentication flexibility.
Configuring a User and User Group
Context
Device administrators can access the network using usernames and passwords. During authentication, device administrators need to enter the following account information for authentication.
Authentication Mode |
Account Type |
Description |
|---|---|---|
Device administrator authentication |
User |
A username and the password are required for authentication, which are pre-configured on iMaster NCE-Campus by tenant administrators. NOTE:
The preset end user ~anonymous is used for anonymous authentication. The account has no password configured and cannot be deleted or modified. |
Procedure
- Choose from the main menu.
- Click
![]()
to create a user. You can create users one by one.![]()
- Select a user group and click Create to create a user. You can create users one by one. Ensure that 802.1X is selected.
![]()
When creating a user, you are advised to bind an email address or phone number to the user to facilitate password change.
![]()
- Click
![]()
to import users and user groups. You can use an Excel template to import users and user groups in batches. - Click
![]()
to export users and user groups. After the export task is created, click OK and choose to view and download the task.
- Click
to create a user. You can create users one by one.
to import users and user groups. You can use an Excel template to import users and user groups in batches.
to export users and user groups. After the export task is created, click OK and choose Parameter Description
Parameter |
Description |
|
|---|---|---|
User name |
Username and password used by an end user during authentication to connect to a cloud-managed device. |
|
Password |
||
Confirm password |
||
Role |
Role attached to the user. |
|
Email address and phone number of a user. When resetting passwords, a user receives a verification code via an email or an SMS message and sets a new password based on the verification code. |
||
Phone number |
||
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. This parameter does not take effect for HWTACACS authentication access users. |
|
Expiration time |
Time when the user account expires. If this parameter is left empty, the account is valid permanently. |
|
Change password upon next login |
Whether to change the account password upon next login. If this parameter is enabled, users need to change the initial passwords upon next login. This parameter is valid only for portal authentication. This parameter does not take effect for HWTACACS authentication access users. |
|
Login mode |
Portal |
End users are allowed to access networks only through portal authentication. |
802.1X |
End users are allowed to access networks only through 802.1X authentication. |
|
HWTACACS |
End users are allowed to access networks only through HWTACACS authentication. Device administrators can use usernames and passwords configured during the creation to remotely log in to devices for management. |
|
Only mobile certificate authentication is allowed |
After this function is enabled, users can be authenticated only through the EAP-TLS protocol. If the authentication type does not match, the authentication fails. This function can be enabled only when the login mode is set to 802.1X. |
|
RADIUS attribute |
IP address of the access terminal/Subnet Mask |
IP address and mask allocated to a terminal after the terminal is authenticated by the RADIUS server. |
IP address segment of the access terminal |
IP address segment allocated to terminals after successful RADIUS authentication. This parameter applies to the scenario where a gateway functions as a terminal. The gateway allocates IP addresses to connected terminals from this IP address segment through DHCP. |
|
User-defined authorization parameters |
User-defined RADIUS attributes can be configured for terminals. A maximum of 20 user-defined RADIUS attributes can be configured. |
|
Access binding information |
IP address of the bound terminal |
Terminal IP address bound to the user account. |
MAC address of the bound terminal |
Terminal MAC address bound to the user account. The value must be in the format **-**-**-**-**-**, such as 11-11-11-11-11-11. |
|
Bind the ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
IMSI bound to the SIM or USIM card |
International mobile subscriber identity (IMSI) or SIM card number bound to the user account. The value is a string of 1 to 15 digits. IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Binding an Access Device |
IP address of the access device |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
Parameter |
Description |
|---|---|
User group name |
Name of a user group. A user group contains multiple users. When configuring an access control policy, you can specify the user group to which the policy applies. |
(Optional) Attaching a Role to an Account
Context
In addition to user groups, accounts can be managed based on account roles. An account can belong to only one user group but can be attached to multiple roles. Accounts and roles are mapped in a one-to-many manner. Roles can be created manually by an administrator or created automatically during AD/LDAP account synchronization. Roles can be used for authentication, authorization, and security policy allocation.
Procedure
- Choose from the main menu.
- Click Create to create a role.
![]()
- After the role is created, click
![]()
next to the role, and click Add to attach the role to a user account, guest account, or MAC account.![]()
- Click Import to import roles in batches using an Excel template.
- Click Export All to export information about all roles.
- Click Create to create a role.
Setting Basic Parameters
Context
You can specify validity periods for user accounts, as well as retention periods for expired user accounts. As such, expired user accounts can be cleaned up automatically after the specified retention period elapses.
You can also configure a password policy for user accounts.
Procedure
- Choose from the main menu.
- Click the User Password Policy Configuration tab and modify the password policy for user accounts.
The password policy allows you to properly set the complexity of your account password, password updating period, and character limitations to prevent your password from being stolen. iMaster NCE-Campus provides a default password policy which you can modify as required.
![]()
- Click the SMS Verification Code tab, and set SMS verification code length and SMS verification template.
![]()
- Click the Advanced Parameter tab, and set advanced parameters. The following figure only shows some parameters. For details about other parameters, see Parameter Description at the end of this section.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Complexity rule |
Password complexity and password length of a user account. The password complexity requirements are as follows:
|
Length range |
|
Validity period |
Password validity period of a user account.
|
Days of notifications before password expiration |
|
Previous passwords disallowed |
Number of recent historical passwords that a user is not allowed to reuse. When changing the password, users cannot reuse previous passwords specified by Password repetition not allowed. |
User lockout |
Whether to lock user accounts for a specific period. With this function enabled, if a terminal uses an account and password to connect to a cloud-managed device, but the number of consecutive login failures reaches the value of Login failure count in specified times within the period specified by Specified time period, the terminal's account is locked for a period, which is specified by Lockout duration. |
Specified time period |
|
Login failure count in specified times |
|
Lockout duration |
|
Enable bound account IP/MAC address |
Whether to bind an IP address or a MAC address to a user account. |
Parameter |
Description |
|---|---|
SMS Verification Code Generation Policy |
Character types in an SMS verification code sent to users. The options are as follows:
|
SMS verification code length |
Length of an SMS verification code sent to a user. |
SMS verification template |
Template of an SMS verification code sent to a user. After the configuration, the system sends an SMS message based on the settings. All languages supported by the system share a configuration result. |
Parameter |
Description |
|
|---|---|---|
Account Validity Allocation |
Support the validity of login postponed account |
Whether to extend the validity period of an account. With this function enabled, after portal authentication-free is configured to implement MAC address-prioritized authentication, if a self-registered user logs in to iMaster NCE-Campus within the account validity period, the validity period of the user account will be extended for a further period from the user login time. For example, if the validity period of a self-registered user account is set to 1 day, when the user logs in to iMaster NCE-Campus at 8:00 a.m. on 1st September, the account is valid till 8:00 a.m. on 2nd September. If the user logs in to the system again at 12:00 p.m. on 1st September, the account is valid till 12:00 p.m. on 2nd September. |
Portal authentication-free NOTE:
If this function is enabled on the current page, you need to enable the portal authentication-free function in SSID settings of APs or routers, and authentication settings of switches. |
Cross-site Portal authentication-free |
After a terminal connects to an SSID of a site, the terminal can preferentially use the MAC address for authentication. If this function is enabled, the terminal is allowed to connect to the same SSID of other sites and preferentially use the MAC address for authentication. |
Mac account Portal authentication-free |
Whether to enable MAC address-prioritized portal authentication. If a user uses a MAC account that has passed portal authentication to log in to the controller within the authentication-free validity period, or uses a MAC address that has been recorded on the user management page of the controller, the user can log in to the controller successfully without authentication. NOTE:
When authentication components are deployed remotely, each authentication component performs MAC address authentication-free for users only after they pass portal authentication. MAC address authentication-free data cannot be synchronized between the authentication components and the headquarters. |
|
Support login delay Portal certification-free validity period |
After a user passes MAC address authentication and logs in to iMaster NCE-Campus within the validity period, the validity period of the user account will be extended for a further period from the user login time. |
|
Configuration for Expired Accounts |
Automatically clear expired users |
The Automatically clear expired users parameter indicates whether to automatically delete expired accounts. After this function is enabled, accounts that have expired for more than the specified number of days will be automatically deleted based on the configured clearance period. |
Clearance period (hours) |
||
Retaining expired users |
||
After the account is disabled, the validity period is recalculated |
After this function is enabled, the validity period of an account is not calculated after the account is disabled, and the remaining validity period is counted after the account is enabled again. The retention period of a disabled user specifies the time period for storing a disabled user. |
|
Disable user retention period (days) |
||
Maximum validity period |
Maximum validity period of an account. The account validity period set when you create a user or guest account or configure a guest account policy cannot exceed the maximum validity period set here. If the maximum validity period is not set, the account validity period for a user or guest account or in a guest account policy cannot exceed 9999. |
|
Timeout Interval of an Offline Device |
Timeout interval |
Device offline duration. When the device offline time exceeds the value of this parameter, the system logs out the online users on the device. This setting takes effect only for HACA portal authentication. |
Sensitive data |
IMSI data plaintext export |
Whether to export IMSIs in clear text. |
Enable the RADIUS user name identification policy |
To enable the RADIUS user name identification rule, run the following command |
Whether to enable RADIUS username identification. If this function is enabled, specified parameters will be carried in RADIUS usernames based on user identification rules. In such cases, the controller can learn the parameter values from RADIUS usernames automatically when RADIUS users go online. Currently, only an IMSI or an ESN can be carried in a RADIUS username. Therefore, if IMSIs or ESNs are specified in authentication rules, you need to enable this function. Currently, the following user identification rules are supported: ACCOUNT IMSI@ACCOUNT IMSI@ESN@ACCOUNT ESN@ACCOUNT |
RADIUS Authentication Transmission Protocol Configuration |
RADIUS authentication transmission protocol SSL configuration |
SSL for RADIUS authentication. TLSv1.2 is used by default. To set the RADIUS authentication transmission protocol to TLSv1 or TLSv1.1, perform the following operations:
TLSv1 and TLSv1.1 may pose data leakage risks. For security purposes, TLSv1.2 is recommended because it is more secure than TLSv1 and TLSv1.1. |
Default Self-Registration User Policy |
Subscriber validity period |
If third-party devices function as authentication devices, this policy takes effect only when no guest account policy is bound to the portal page specified in the desired portal page push policy. If cloud-managed devices function as authentication devices, this policy takes effect only when no guest account policy is bound to the portal page specified in the desired portal page push policy and the user self-registration function is disabled in the site configuration. |
Password validity period |
||
User group |
||
Anonymous authentication |
Enable anonymous authentication |
Whether to enable anonymous authentication. If this function is enabled, you need to set network areas where anonymous authentication is allowed. |
Account expiration notification configuration |
Alert account type |
After this function is enabled, the system can remind users that their accounts are about to expire in advance. This function is applicable only to common and guest accounts. You can set an SMS notification template or email notification template. |
Account expiration reminder time (day) |
||
Template for Notification of Expiry Messages |
||
Email notification template for expiration |
||
Configuring Portal Authentication for Multiple Networks |
Network type |
Network type for multi-network portal authentication. |
Network suffix |
Suffix of the account used by a user to access the network. |
|
Network role |
Role of the user who accesses the network. This parameter is configured on the page. |
|
Enabling SAVI |
Expiration Time (s) |
When iMaster NCE-Campus functions as a relay server to connect to a third-party authentication server and the SAVI function is configured on devices, devices will check whether packets are valid based on whether the source IP addresses of the packets match bindings between the IP addresses and interfaces. After this function is enabled, iMaster NCE-Campus checks the consistency of the MAC address, IP address, and user name to verify user validity. If a spoofing user exists, the system records the user in the blacklist and reports the blacklist to the configured blacklist server. The third-party authentication server forces the blacklisted users offline. The expiration time is the SAVI detection expiration time. When a device goes offline for a period longer than the configured expiration time, iMaster NCE-Campus does not perform MAC spoofing detection on the device when it goes online again. |
Access protocol |
||
Protocol version |
||
Certificate verification |
||
Address of the blacklist server |
||
Configuring an Authentication Rule
Authentication rules can be configured to authenticate clients and users on the network to ensure network security.
iMaster NCE-Campus provides a default authentication rule default that uses a local data source for authentication. The default template can be modified to use a third-party data source for authentication.
Context
You can configure multiple authentication rules to generate an authentication scheme. The authentication scheme defines the authentication rules used for user authentication. If multiple authentication schemes are configured, the authentication scheme with the smallest priority value has the highest priority. If the high-priority authentication scheme is matched, other schemes are not matched.
Procedure
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication method to Device Management Authentication.
![]()
Related Operations
- Setting the priority of an authentication rule
The priority value of the first authentication rule is 1 and the priority values of subsequent authentication rules increase by 1. The smaller the priority value, the higher the priority. The default authentication rule has the lowest priority. You can set the priority of an authentication rule as needed.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time information |
User authentication based on time ranges. |
|
Authentication Information |
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
|
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, firewall, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. Currently, two methods are available: two-factor authentication using accounts and SMS verification code or RADIUS tokens, and two-factor authentication using SSL VPN-enabled firewalls. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. The RADIUS token factor is supported only when the two-factor authentication method is used. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
PAP must be enabled when LDAP accounts are used for Portal 2.0 authentication, FW SSL VPN authentication, and MAC address authentication. In addition, CHAP must be enabled for Portal 2.0 authentication. If iMaster NCE-Campus functions as an authentication server in other services, enable the required protocol. One of the EAP-MD5, EAP-PEAP-MSCHAPv2, EAP-TLS, EAP-PEAP-GTC, and EAP-TTLS-PAP protocols can be specified as the preferential protocol used for authentication. This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
User authentication based on user groups to which MAC accounts are mapped. |
MAC account |
User authentication based on MAC accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows: PAP protocol (local account, AD, LDAP, RADIUS Token, Third-party HTTP server, Third-party Database) CHAP protocol(Local account, Third-party Database) |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Admission device group |
User authentication based on access device groups. |
|
Terminal IP range |
User authentication based on terminal IP addresses. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Device IP address, access VLAN, access port, user MAC address, user IP address, user IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Configuring an Authorization Result
Context
After an administrator is authenticated, the authorization result specifies the rights assigned to the administrator. The rights include the levels of commands that an administrator can execute, as well as available command sets.
iMaster NCE-Campus provides two default authorization results: allow access and reject access. Once selected, the default authorization result takes effect for all sites and cannot be modified or deleted. When configuring device administrator authentication, you can select a default authorization result or configure an authorization result as required.
Procedure
- Choose from the main menu.
- Click Create to create an authorization result. Specify Device Management Authentication in the authorization result.
![]()
Related Operations
- Setting the priority of an authorization rule
The priority value of the first authorization rule is 1 and the priority values of subsequent authorization rules increase by 1. The smaller the priority value, the higher the priority. The default authorization rule has the lowest priority. You can set the priority of an authorization rule as needed.
Parameter Description
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring an Authorization Rule
When iMaster NCE-Campus authorizes authenticated users, it grants specific permissions only to the users who hit the specified authorization rules.
iMaster NCE-Campus provides a default authorization rule default with the authorization result Deny Access. You can modify the authorization result in this default template as required.
Context
Authorization results define the rights assigned to authenticated end users. Each authentication rule corresponds to an authentication result. If an authenticated end user matches an authentication rule, the corresponding authorization result applies to the user. If no authorization rule is set, an authorization result is applicable to all authenticated terminals.
Procedure
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to Device Management Authentication.
![]()
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server belongs to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on accounts. |
||
Role Information |
Authenticated users are authorized based on roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, AR, and firewall. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. |
||
Region |
Authenticated users are authorized based on regions. |
||
Protocol Information |
Enable protocol matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported:
|
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, and FW. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on regions. |
||
Region |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Protocol Information |
Enable protocol information matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported: EEAP-MD5 protocol (Local account) EAP-PEAP-MSCHAPv2 protocol (Local account, AD, and LDAP) EAP-TLS protocol (Local account, AD, LDAP) EAP-PEAP-GTC protocol (Local account, AD, LDAP, and RADIUS Token) EAP-TTLS-PAP protocol (Local account, AD, and LDAP) |
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
The Authentication Terminal Has Been Added to the AD Domain |
Whether authenticated users using terminals that have been added to AD domains have been authorized. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, and WAC. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Region |
Authenticated users are authorized based on regions. |
||
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
Admission Device Group |
Authenticated users are authorized based on access device groups. |
|
Region |
Authenticated users are authorized based on regions. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Configuring a RADIUS Template
Procedure
- Choose from the main menu, and select RADIUS Server.
- Click Create, set parameters, and click OK.
![]()
- When configuring an SSID for authentication based on a RADIUS server, you can select this template to specify the RADIUS server associated with the SSID. For details, see Configuring an SSID.
- Only APs running V200R008C10 and later versions support the Disable RADIUS attributes parameter. The RADIUS attributes supported vary with the AP model. If this parameter is configured in the selected RADIUS template, ensure that the model and version of the target AP meet requirements. Otherwise, the SSID-related service configuration will fail to be delivered. To view RADIUS attributes supported by a device, run the display radius-attribute command in the system view of the device.
- Only APs running V200R009C00 and later versions support the Set called-station-id attribute value parameter.
- Only APs running V200R008C00 and later versions support the Real-time accounting parameter.
![]()
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Unique identifier of a RADIUS server template. |
|
Using Built-in Server |
Whether to configure iMaster NCE-Campus as a RADIUS server. If this function is enabled, you can configure either the service manager (SM) or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters. |
|
Authentication server |
Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight authentication servers can be added. |
|
Accounting server |
Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server. When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers. When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights. A maximum of eight accounting servers can be added. |
|
Authentication component |
This parameter needs to be set only when Using Built-in Server is enabled. The authentication component can be the Service Manager (SM) or a remote server. The SM is the headquarters controller. |
|
Server selection policy |
|
|
Server selection algorithm |
|
|
Real-time accounting |
Whether to enable real-time accounting. After this function is enabled, you can configure a real-time accounting interval. By default, this function is disabled. |
|
Billing reporting cycle |
Real-time accounting interval. |
|
Key |
Shared key of the RADIUS server. You are advised to periodically change the shared key. |
|
Disable RADIUS attributes |
Whether to filter specific attributes in the packets exchanged between the device and the RADIUS server. The default value is OFF, indicating that specific attributes are not filtered. |
|
Disable attributes |
- |
Click Create and configure a filtering policy. |
Attribute name |
Click ... and select the names of attributes to be filtered in the displayed dialog box. |
|
Prohibit Sending |
The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server. |
|
Prohibit Receiving |
The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server. |
|
Service-Type |
- |
The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server. |
Attribute value |
Specifies the value of service-type attribute to be modified. |
|
Option |
Sets the user authentication mode to MAC address authentication. |
|
called-station-id |
- |
After this function is enabled, you can set the called-station-id attribute value, which specifies content encapsulated in the called-station-id attribute of RADIUS packets. Currently, only APs support this function. By default, this function is disabled. |
Attribute value |
Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location. |
|
Carry SSID attributes |
After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled. |
|
Attribute separator |
Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains the SSID. The value is of enumerated type, and can be \, /, :, <, >, |, @, ', %, *, +, -, &, !, #, ^, and ~. The default value is :. |
|
Mac address format setting |
MAC address format in RADIUS packets. The following formats are supported:
|
|
Server status auto-detection |
Username |
Username for automatic RADIUS server detection. |
Password |
Password for automatic RADIUS server detection. |
|
Retransmit authentication requests |
Retransmission count |
Number of retransmission times if an authentication request times out. |
Timeout interval |
Timeout interval of an authentication request. |
|
Server down duration |
Period during which the authentication server remains Down. |
|
Configuring an Access Control Device
Context
After a RADIUS server is configured, you need to perform device management and authentication configurations for an access control device to connect the device to the network. Currently, iMaster NCE-Campus can deliver device management and authentication server configurations to Huawei switches and APs. When you configure a RADIUS template, you can use iMaster NCE-Campus as the built-in RADIUS server or use a third-party RADIUS server.
Procedure
- (Optional) If the iMaster NCE-Campus built-in server is used for authentication, add access control devices to an access device group. If a third-party RADIUS server is used for authentication, skip this step.
- Choose from the main menu.
- Click
![]()
on the left side and create a device group. Device groups are displayed in a tree structure. A maximum of 128 device groups can be created, nested in up to four levels.![]()
- Select a created device group, click the Access device tab, and click Create to add devices to the device group.
![]()
- Choose from the main menu.
- Select a site from the Site drop-down list in the upper left corner.
- Choose on the Site Configuration tab.
- Click
![]()
next to Device Administrator and set parameters.![]()
on the left side and create a device group. Device groups are displayed in a tree structure. A maximum of 128 device groups can be created, nested in up to four levels.
next to 
Parameter Description
Parameters |
Description |
|
|---|---|---|
Local user |
User name |
User name for logging in to a device. The password must meet the following requirements:
|
Password |
Password of the user account. The password must meet the following requirements:
|
|
Role |
Priority of a local user. After uses of different levels log in to a device, they can use only the commands of the same or a lower level than their own levels.
|
|
Service type |
Access mode of a local user.
|
|
BootROM password |
BootROM password of a switch or an AP. If you do not set this password, the administrator password and BootROM password that take effect are those set by tenant administrators when they log in to iMaster NCE-Campus for the first time, or those set in the Device Password Configuration area on the Device Management tab page under . NOTE:
If the system administrator disables The device BootROM password can be configured, tenants cannot change BootROM passwords of devices. For details about how to disable tenants from changing BootROM passwords of devices, see Configuring a BootROM Password Policy. |
|
Device login timeout interval (min) |
Period after which a user is disconnected from the user interface. The value is 10 by default. The value 0 indicates that this function is disabled. |
|
Number of lines displayed on each screen |
Number of rows printed on a split screen. The value is 24 by default. The value 0 indicates that this function is disabled. |
|
Login restriction |
Whether to restrict login to devices via SSH. You can bind SSH virtual type terminal (VTY) accounts of devices to specified advanced ACLs to restrict the accounts that are allowed to log in to devices via SSH. Only APs and switches support this function. The available ACL numbers are in the range from 3032 to 3999. |
|
HWTACACS Authentication |
- |
Whether to enable the HWTACACS authentication mode for the devices at the current site. NOTE:
HWTACACS authentication cannot be disabled if a switch supports login through a console port. |
HWTACACS Server |
Select an HWTACACS server from the drop-down list box. The server has been defined on the Policy Template page. |
|
Command line authorization |
You can set this parameter as needed. This function is optional when the controller functions as an HWTACACS authentication server. If the controller functions as an HWTACACS authorization server to authorize command lines to device users, you need to configure a command set and enable this function. |
|
HWTACACS bypass |
Bypass policy after an HWTACACS server authentication or authorization failure.
|
|
RADIUS Authentication |
RADIUS server |
RADIUS server configured in the desired RADIUS server template. The RADIUS server template is defined on the policy template page. |
Authentication protocol |
RADIUS authentication protocol. PAP and CHAP are supported. |
|
RADIUS authentication bypass |
|
|
Secure Access for IoT Access Control Terminals
Overview
Introduction
To implement security access for IoT access control terminals, iMaster NCE-Campus interworks with Intelligent Access Platform to connect IoT access control terminals to the network.
By doing this, iMaster NCE-Campus solves the following problems:
- Access security is ensured through MAC address authentication and 802.1X authentication.
- IoT access control terminals on an intelligent access network can be automatically deployed and go online, simplifying the installation and deployment.
- Intelligent Access Platform can manage the rights of IoT access control terminals in a unified manner, implement remote control and intelligent management, and reduce O&M costs.
Figure 5-16 shows the basic networking.
Authentication Process
MAC address + 802.1X mixed authentication is used for secure access of IoT access control terminals. Figure 5-17 shows the authentication process.
- An administrator records the MAC addresses of an access control terminal to Intelligent Access Platform.
- Intelligent Access Platform delivers the MAC address to iMaster NCE-Campus.
- Installation personnel install and deploy the access control terminal and connect it to the network through an access device.
- The access device initiates MAC authentication for the access control terminal.
- After receiving the authentication request, iMaster NCE-Campus checks whether the MAC address of the access control terminal is delivered by Intelligent Access Platform.
- If the MAC address of the access control terminal is available on iMaster NCE-Campus, the authentication succeeds, and iMaster NCE-Campus delivers restricted rights to the access control terminal. If the MAC address of the access control terminal in unavailable on iMaster NCE-Campus, the authentication fails.
- iMaster NCE-Campus reports the information about the access control terminal that passes MAC address authentication to Intelligent Access Platform. Then, an application to be approved is generated on Intelligent Access Platform.
- The administrator logs in to Intelligent Access Platform and approves the application.
- Intelligent Access Platform delivers the approval result to iMaster NCE-Campus. Only the access control terminals that pass the approval can apply for certificates and initiate 802.1X authentication.
- The installation personnel apply for a certificate on the access control terminal.
- The Boarding program pre-configured on the access control terminal initiates a RESTful certificate request to iMaster NCE-Campus based on its MAC address.
- After receiving the RESTful request, if the MAC address has been approved, iMaster NCE-Campus sends a certificate application request to the PKI system through the standard SCEP protocol.
- iMaster NCE-Campus sends a RESTful response containing the applied certificate to the Boarding program of the access control terminal.
- The Boarding program installs the certificate on the access control terminal. Then, the access control terminal sends a certificate authentication request to the access device.
- The access device sends the certificate authentication request to iMaster NCE-Campus.
- iMaster NCE-Campus verifies the certificate.
- After the certificate is verified, iMaster NCE-Campus delivers access permissions to the access control terminal so that the terminal can register with Intelligent Access Platform.
Configuring Interconnection with Intelligent Access Platform
Prerequisites
The certificate, app ID, and app key of Intelligent Access Platform have been obtained.
Procedure
- Choose from the main menu and click the Intelligent Access Control tab.
- Enter the server address, app ID, and app key of Intelligent Access Platform.
![]()
- (Optional) Import the Intelligent Access Platform certificate. If Certificate verification is enabled, you need to import the Intelligent Access Platform certificate to iMaster NCE-Campus.
- Choose from the main menu.
- Choose from the navigation pane and click Intelligent Access Control on the Services page.
- Click the Trust Certificate tab, click Import, enter the certificate information, select the Intelligent Access Platform certificate, and click Submit to upload the certificate to iMaster NCE-Campus.
![]()
Configuring MAC Address + 802.1X Mixed Authentication
To implement secure access of access control terminals, administrators need to perform the following configurations on iMaster NCE-Campus:
- Configure MAC address authentication on servers.
- Configure 802.1X authentication on servers.
- Configure MAC address + 802.1X mixed authentication on access devices.
Configuring MAC Address Authentication
Context
After an administrator imports the MAC addresses of access control terminals to Intelligent Access Platform, Intelligent Access Platform delivers the MAC addresses to iMaster NCE-Campus. After an access control terminal is installed and deployed, it needs to access the network through an access device which initiates MAC address authentication for the access control terminal. The administrator needs to configure authentication rules, authorization rules, and authorization results for MAC address authentication on iMaster NCE-Campus. After passing MAC address authentication, access control terminals can access iMaster NCE-Campus but cannot access Intelligent Access Platform.
Procedure
- Configure a MAC address authentication rule.
- Choose from the main menu, click Create, and configure an authentication rule.
- Set the authentication mode to MAC Address Authentication and set other parameters as needed.
- After matching conditions and authentication information are configured, iMaster NCE-Campus can authenticate users based on matching conditions such as users, locations, and other information.
- Set advanced parameters. Specifically, set The account does not exist to Deny Access
![]()
- Click OK.
- Choose from the main menu, click Create, and configure an authentication rule.
- Configure an authorization result for MAC address authentication.
- Choose from the main menu, click Create, and configure an authorization result.
- Specify an ACL template. Click
![]()
to create an ACL template or select an existing ACL template. For details, see ACL Template. - Set other parameters in the authorization result. Different types of devices support different authorization result parameters. For details, see Table 5-203.
![]()
- Specify an ACL template. Click
- Click OK and bind the authorization result to a specific site. Alternatively, select the created authorization result and click
![]()
to bind the authorization result to a specific site.![]()
- Choose from the main menu, click Create, and configure an authorization result.
- Configure an authorization rule for MAC address authentication.
- Choose from the main menu, click Create, and configure an authorization rule.
- Set the authentication mode to MAC Address Authentication and set other parameters as needed.
- Configure matching conditions, such as users, locations, MDM information, and other information.
- Specify an authorization result.
![]()
- Click OK.
- Choose from the main menu, click Create, and configure an authorization rule.
to create an ACL template or select an existing ACL template. For details, see 
to bind the authorization result to a specific site.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
User authentication based on user groups to which MAC accounts are mapped. |
MAC account |
User authentication based on MAC accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows: PAP protocol (local account, AD, LDAP, RADIUS Token, Third-party HTTP server, Third-party Database) CHAP protocol(Local account, Third-party Database) |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
MAC account mapping user group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
MAC account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, and WAC. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Terminal IP Range |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Region |
Authenticated users are authorized based on regions. |
||
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring 802.1X Authentication
Context
After passing MAC address authentication, access control terminals obtain can only access iMaster NCE-Campus but cannot access Intelligent Access Platform. In this case, certificate authentication is required. After the terminal certificates are authenticated, iMaster NCE-Campus delivers access permissions to the access control terminals to enable their registration with Intelligent Access Platform.
Prerequisites
- The system administrator has configured interconnection between iMaster NCE-Campus and Intelligent Access Platform. For details, see Configuring Interconnection with Intelligent Access Platform.
- The tenant administrator has configured an SCEP certificate server. For details, see Configuring an SCEP Server.
Procedure
- Configure an authentication rule for 802.1X authentication.
- Choose from the main menu, click Create, and configure an authentication rule.
- Set the authentication mode to User access authentication and set other parameters as needed.
- After matching conditions and authentication information are configured, iMaster NCE-Campus can authenticate users based on matching conditions such as users, locations, and other information.
- Set advanced parameters. Specifically, set The account does not exist to Continue.
![]()
- Click OK.
- Choose from the main menu, click Create, and configure an authentication rule.
- Configure an authorization result for 802.1X authentication.
- Choose from the main menu, click Create, and configure an authorization result.
- Configure an authorization result.
- Specify an ACL template. Click
![]()
to create an ACL template or select an existing ACL template. For details, see ACL Template. - Set other parameters in the authorization result. Different types of devices support different authorization result parameters. For details, see Table 5-203.
![]()
- Specify an ACL template. Click
- Click OK and bind the authorization result to a specific site. Alternatively, select the created authorization result and click
![]()
to bind the authorization result to a specific site.![]()
- Configure an authorization rule for 802.1X authentication.
- Choose from the main menu, click Create, and configure an authorization rule.
- Set the authentication mode to User access authentication and set other parameters as needed.
- Configure matching conditions, such as users, locations, protocols, MDM information, and other information.
- Specify an authorization result.
![]()
- Click OK.
- Choose from the main menu, click Create, and configure an authorization rule.
to create an ACL template or select an existing ACL template. For details, see 
to bind the authorization result to a specific site.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User group |
User authentication based on user groups. |
Account |
User authentication based on user accounts. |
||
Role |
User authentication based on user roles. |
||
Location Information |
Site |
User authentication based on sites. |
|
Admission device group |
User authentication based on access device groups. |
||
Access device type |
User authentication based on access device types. Currently, the following device types are supported: LSW, firewall, AP, and WAC. |
||
Device |
User authentication based on devices. |
||
SSID |
User authentication based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
User authentication based on custom terminal groups. You can configure terminal groups on the page. |
||
Device type |
User authentication based on terminal types. |
||
Operating system |
User authentication based on the OS of terminals. |
||
Match registered terminals |
Whether to match end users against authentication rules based on terminals registered on an MDM server or through Boarding. |
||
Terminal IP range |
User authentication based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Other Information |
Time |
User authentication based on time ranges. |
|
Customization Condition |
User authentication based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
Authentication Information |
Enable RADIUS relay |
User authentication based on specified relay server templates. |
|
Access Parameters |
Access attributes specified for accounts. When Accounts that are not bound to access parameters are not allowed to access the network is enabled, if the access attributes of an account are inconsistent with the ones specified on the controller, the account fails to be authenticated. If Self-learning access parameters is enabled, after an account is authenticated successfully, the access attributes are learned automatically and bound to the user account. If Self-learning access parameters is disabled, you need to bind the user's access attributes to the user account manually on the page. Currently, the following access attributes are supported: Authentication device IP address, authentication device VLAN, authentication device interface, terminal MAC address, terminal IP address, terminal IMSI, and terminal ESN. |
||
Data sources |
Data source used for authentication. You can select either the local data source or an external data source. This parameter is not supported when the RADIUS relay function is enabled. |
||
Two-Factor Authentication |
Two-factor authentication type |
Type of the desired two-factor authentication method. Currently, two methods are available: two-factor authentication using accounts and SMS verification code or RADIUS tokens, and two-factor authentication using SSL VPN-enabled firewalls. |
|
Second data source type |
Second authentication source for two-factor authentication. You can specify dynamic SMS verification codes or RADIUS tokens. The RADIUS token factor is supported only when the two-factor authentication method is used. |
||
Authentication timeout interval in phase 2 (s) |
Timeout period for the second phase in two-factor authentication. The value ranges from 60 to 100, in seconds. The default value is 60. |
||
Authentication protocol |
Protocol used for authentication. The options are as follows:
PAP must be enabled when LDAP accounts are used for Portal 2.0 authentication, FW SSL VPN authentication, and MAC address authentication. In addition, CHAP must be enabled for Portal 2.0 authentication. If iMaster NCE-Campus functions as an authentication server in other services, enable the required protocol. One of the EAP-MD5, EAP-PEAP-MSCHAPv2, EAP-TLS, EAP-PEAP-GTC, and EAP-TTLS-PAP protocols can be specified as the preferential protocol used for authentication. This parameter is not supported when the RADIUS relay function is enabled. |
||
Advanced options |
The Account Does Not Exist |
Authentication action performed when an account does not exist. The options are as follows:
|
|
Identity Authentication Failed |
Authentication process performed when the use identify fails to be authenticated. The options are as follows:
|
||
Parameter |
Description |
||
|---|---|---|---|
Matching Condition |
User Information |
User Group |
Authenticated users are authorized based on user groups. |
External group |
Data on an AD server is saved to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
||
Account |
Authenticated users are authorized based on user accounts. |
||
Role Information |
Authenticated users are authorized based on user roles. |
||
Location Information |
site |
Authenticated users are authorized based on sites. |
|
Admission Device Group |
Authenticated users are authorized based on access device groups. |
||
Access Device Type |
Authenticated users are authorized based on access device types. The following device types are supported: LSW, AP, WAC, and FW. |
||
Device |
Authenticated users are authorized based on devices. |
||
SSID |
Authenticated users are authorized based on SSIDs. This parameter is configurable only when the wireless access mode is configured. |
||
Custom terminal group |
Authenticated users are authorized based on custom terminal groups. You can configure terminal groups as needed on the page. |
||
Device type |
Authenticated users are authorized based on terminal types. |
||
Operating system |
Authenticated users are authorized based on OS types of terminals. |
||
Match registered terminals |
Authenticated users are authorized based on registered terminals. If this function is enabled, the controller matches authenticated users against authorization rules based on the terminals registered on the MDM system or registered through the boarding function. |
||
Terminal IP Range |
Authenticated users are authorized based on regions. |
||
Region |
Authenticated users are authorized based on terminal IP addresses. This parameter is configurable only when the wired access mode is configured. |
||
Protocol Information |
Enable protocol information matching |
Authenticated users are authorized based on protocols. Currently, the following protocols are supported: EEAP-MD5 protocol (Local account) EAP-PEAP-MSCHAPv2 protocol (Local account, AD, and LDAP) EAP-TLS protocol (Local account, AD, LDAP) EAP-PEAP-GTC protocol (Local account, AD, LDAP, and RADIUS Token) EAP-TTLS-PAP protocol (Local account, AD, and LDAP) |
|
MDM information |
MDM server |
Authenticated users are authorized using an MDM server. You can configure the action to be taken if the MDM server fails to be connected or the query times out:
|
|
MDM registration |
Whether to authorize an end user based on the terminal registration status on the MDM server.
|
||
Other Information |
Time |
Authenticated users are authorized based on time ranges. |
|
Customization Condition |
User authorization based on customized conditions. You can select either preset RADIUS attributes or customized RADIUS attributes to match those carried in user accounts. |
||
The Authentication Terminal Has Been Added to the AD Domain |
Whether authenticated users using terminals that have been added to AD domains have been authorized. |
||
Authentication result |
Authorization result that takes effect after successful authentication. |
||
Parameter |
Description |
|---|---|
Device management service |
Whether to enable device administrator authentication. NMS login privilege: indicates the login privilege of users who match an authorization rule. The value is in the range from 0 to 15. Only Huawei authentication devices support this parameter. Custom authorization parameter: indicates the custom authorization parameters for end users who match an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. The following parameters are not supported if Device management service is enabled. |
VIP User |
Whether to ensure preferential access for VIP users. After this function is enabled, you can set Access threshold policy on the AP > Radio page and AP > SSID page, ensuring preferential access for VIP users. For LSWs, you can also configure an application scheduling template on the page to set the guaranteed bandwidth for VIP users. |
ACL/Dynamic ACL |
ACL or dynamic ACL that permits or prevents STAs to access or from accessing specified resources.
|
IPV6 ACL |
ACL6 that permits or prevents STAs to access or from accessing specified resources. Only some switch models support ACL6. For details, see the section "acl-id (service scheme view)" in the product documentation of switches. NOTE:
For LSWs only. Only IPv6 ACLs with a specified number are supported. ACLs with a number range are not supported. Wireless users are 3001 to 3031, and wired users are 3001 to 3999. |
Security group |
Security group to which STAs matching an authorization rule are dynamically assigned. |
URL Filtering |
URL filtering mode:
NOTE:
This parameter is supported on APs only. However, central APs do not support this parameter. |
VLAN |
ID of the VLAN to which an end user that matches the authorization rule is assigned. Different control policies can be bound to different VLAN IDs or the same VLAN ID. The value can be a VLAN ID or a VLAN pool. The interfaces that join the VLANs authorized to end users must be hybrid interfaces. When devices are managed by iMaster NCE-Campus, you can choose from the main menu and choose from the navigation pane to configure interfaces as hybrid interfaces. |
Enable downlink rate (Mbit/s)/Enable uplink rate (Mbit/s) |
Uplink or downlink bandwidth limits of each STA. |
Forcible redirection |
ACL or URL to which users are forcibly redirected to. This function is available in common authentication, boarding, and CWA authentication services.
|
DSCP |
DSCP for a STA that matches an authorization rule. The differentiated services code point (DSCP) is used to classify the traffic QoS of STAs. |
Custom Authorization Parameters |
Authorization parameters customized for the end user that matches an authorization rule. The following custom authorization parameters are supported: attribute ID, attribute type, attribute value, and vendor. You can set RADIUS attribute values as needed. For details about the supported RADIUS attributes, see descriptions on the authorization result page of the controller web UI. |
Configuring an Authentication Point
Context
After configuring authentication and authorization rules for MAC address and 802.1X authentication on servers, configure authentication on authentication points on the network. After an IoT access control terminal accesses the network, the access device to which the terminal connects initiates authentication for the terminal.
The configuration on authentication points varies in different scenarios:
- Wired authentication
- (Recommended) Dual SSIDs: Two SSIDs are configured on an access device. One SSID is used for MAC address authentication, and the other is used for 802.1X authentication.
- An access device is configured with one SSID and has MAC address bypass authentication enabled. After an IoT access control terminal accesses the network, the access device cannot initiate 802.1X authentication for the terminal since the terminal has not applied for a certificate. In this case, the access device initiates MAC address bypass authentication instead. After MAC address bypass authentication is successful, the access device applies for a certificate for the terminal and initiates 802.1X authentication.
- Wireless authentication: MAC address bypass authentication is enabled on an access device. After an IoT access control terminal accesses the network, the access device initiates MAC address bypass authentication for the terminal. After MAC address bypass authentication is successful, the access device applies for a certificate for the terminal and initiates 802.1X authentication.
Procedure
- Select a site.
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Select a configuration procedure based on the authentication point.
Authentication Point
Configuration Procedure
AP
-
- Choose from the navigation pane, click Create, and configure basic information about an SSID.
- You are advised to configure two SSIDs on an AP.
- On the Security Authentication page, set Authentication mode of an SSID to Semi-open network with MAC Address Authentication , and specify a RADIUS server using a template. This SSID is used for MAC address authentication.
- On the Security Authentication page, set Authentication mode of the other SSID to Secure network, and specify a RADIUS server using a template. This SSID is used for 802.1X authentication.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
NOTE:If only one SSID is configured on an AP, set Authentication mode to Secure network and enable MAC address bypass authentication.
Switch
Wired authentication
Choose from the navigation pane and click the Wired Authentication tab. Click Create and configure authentication.
- Set Authentication mode to Secure network and specify a RADIUS server using a template.
- Enable MAC address bypass authentication.
- Set Interface access mode and Terminal access mode. Currently, the following access modes are supported:
- Allow multi-terminal access under interface and Multi-terminal authenticated access: An interface allows multiple users to go online. In this mode, the device authenticates each user. If the authentication succeeds, the device grants independent network access rights to the user. That is, if a user goes offline, other users are not affected.
Allow multi-terminal access under interface and Only the first terminal needs authentication access: An interface allows multiple users to go online. In this mode, the device authenticates only the first go-online user. If the authentication succeeds, subsequent users share the network access permission of the first user. If the first user goes offline, other users go offline accordingly.
- Allow single-terminal access under interface and Single-terminal access: An interface allows only one user to go online.
Allow single-terminal access under interface and Single common terminal accesses through voice terminal: An interface allows only one data user and one voice user to go online. This mode applies to the scenario where a data user accesses the network through a voice terminal.
- Allow multi-terminal access under interface and Multi-terminal authenticated access: An interface allows multiple users to go online. In this mode, the device authenticates each user. If the authentication succeeds, the device grants independent network access rights to the user. That is, if a user goes offline, other users are not affected.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
- Select the type of packets that trigger authentication. By default, a switch triggers authentication through DHCP, ARP, DHCPv6, or ND packets. If a dumb terminal is configured with a static IPv4 address, and no DHCP or ARP packets are exchanged between the dumb terminal and authentication device, you need to select any-l2-packet for authentication.
Wireless authentication
Choose from the navigation pane and click the Wireless Authentication tab. Click Create and configure authentication.
- You are advised to configure two SSIDs on an AP.
- On the Security Authentication page, set Authentication mode of an SSID to Semi-open network with MAC Address Authentication, and specify a RADIUS server using a template. This SSID is used for MAC address authentication.
- On the Security Authentication page, set Authentication mode of the other SSID to Secure network, and specify a RADIUS server using a template. This SSID is used for 802.1X authentication.
- Configure a bypass policy to ensure basic network access when a network fault occurs or iMaster NCE-Campus is being upgraded. Currently, the following bypass policies are supported:
- Permit access from authenticated users and reject access from new users.
- Permit user access without authentication.
- Permit user access without authentication based on a user-defined bypass policy. You can define a bypass policy as needed using a bypass policy template.
NOTE:If only one SSID is configured on an AP, set Authentication mode to Secure network and enable MAC address bypass authentication.
Terminal Management
Context
- iMaster NCE-Campus provides the terminal management capability. Currently, the following types of terminal groups are supported.
- Self-defined: Terminal information obtained from Intelligent Access Control can be viewed in the user-defined group.
- Identified: Information about terminals managed through terminal identification can be viewed in the identified group.
- Unidentified: Information about unidentified terminals can be viewed in the unidentified group.
- When viewing terminal information, you can filter terminals by type, vendor, model, operating system, blacklist status, approval status, and self-registration status.
- Pending Approval: The terminal has completed MAC address authentication by iMaster NCE-Campus but Intelligent Access Platform does not approve this terminal.
- Approved: The terminal has been approved by Intelligent Access Platform.
- Self-registration: The terminal has completed self-registration after the Boarding or MDM authentication succeeds.
- Blacklist: It lists terminals that are not allowed to be authenticated, for example, terminals that have been claimed missing. Terminals can be migrated from other groups to the blacklist group.
- Based on the authentication capability of iMaster NCE-Campus, cellular networks allow mobile terminals to access enterprises' campus networks without being restricted by physical boundaries.
Procedure
- Choose from the main menu, and enable Terminal approval.
After this function is enabled, only approved terminals can initiate MAC address authentication for Internet access.
![]()
- Choose from the main menu.
You can view terminal information on this page.
![]()
- You can click
![]()
to delete a terminal. After an access control terminal is deleted, iMaster NCE-Campus automatically checks whether the terminal has applied for a certificate. If the terminal has applied for a certificate, iMaster NCE-Campus revokes the certificate.
to delete a terminal. After an access control terminal is deleted, Configuring Secure Access for Cellular Network Terminals (IoT)
Overview
Introduction
Cellular networks feature high-speed mobility and wide coverage. As an effective supplement to campus networks, cellular networks are widely used in education and scientific research, telemedicine, and smart manufacturing scenarios. To ensure that cellular terminals can securely access an enterprise internal network, the enterprise AAA server needs to perform secondary authentication on cellular network terminals, and interworks with a multi-service control gateway (MSCG) on the enterprise internal network to implement unified policy control on cellular network terminals.
Figure 5-18 shows the basic networking.
Abbreviations |
Full Name |
Description |
|---|---|---|
IMEI |
International Mobile Equipment Identity |
Unique identifier of a terminal. A dual-SIM terminal has two IMEIs. |
IMSI |
International Mobile Subscriber Identity |
Unique ID of a SIM card. |
MSISDN |
Mobile Station International Subscriber Directory Number |
Complete phone number. |
APN |
Access Point Name |
Access point name. |
MSCG |
Multi-service Control Gateway |
MSCGs provide the following functions at network edges: validity check for user services, dynamic service detection and differentiation, service policy control, QoS, network resource allocation, and service traffic distribution. In most cases, an ME60, S5700, S5720, S5730, or S12700 can function as an MSCG. |
ULI |
User Location Info |
User location information. |
SMF |
Session Management Function |
Session management unit. |
This function applies only to IoT devices and is not supported by terminals that have roaming issues, such as laptops and tablets. Do not use this function on personal mobile terminals.
This function is not applicable to the Huawei public cloud scenario.
This function allows cellular network terminals to access enterprise campus networks from carrier networks. When cellular network terminals switch between carrier networks and campus Wi-Fi networks, they will go offline and need to be authenticated again.
Authentication Process
Figure 5-19 shows the authentication process for a cellular network terminal to access an enterprise campus network.
Terminal Go-Online Process
- The enterprise administrator purchases SIM cards and terminals, and imports terminal information such as the IMSIs and IMEIs to iMaster NCE-Campus. Alternatively, the enterprise administrator can import such information to the IoT center and the IoT center then synchronizes the information to iMaster NCE-Campus through a northbound API.
- A cellular network terminal with a built-in SIM card accesses the core network and sets up a PDU session.
- The SMF on the core network negotiates the authentication mode (RADIUS PAP or RADIUS CHAP) with iMaster NCE-Campus.
- The SMF on the core network sends an authorization request carrying the terminal's IMSI, IMEI, or other information to iMaster NCE-Campus. Since the SMF sends sensitive information to iMaster NCE-Campus, their communication is carried over a private line and encrypted through an IPsec tunnel.
- iMaster NCE-Campus records terminal login information, and displays the information on the online user page and in RADIUS login and logout logs.
- After authenticating and authorizing the terminal, iMaster NCE-Campus can interwork with the MSCG to implement Internet access control for the terminal in the following two methods. A firewall functions as an MSCG and an online behavior management device, and is configured with SSO. After being interconnected with iMaster NCE-Campus, the firewall can manage online behavior of terminals that go online on iMaster NCE-Campus. Alternatively, a switch can function as an MSCG. In this case, iMaster NCE-Campus synchronizes IP-security group entries to the switch for Internet access control on terminals authorized with security groups.
- After being authorized successfully, the terminal can access resources on the enterprise internal network through the core network.
- The cellular network terminal notifies the SMF on the core network that it wants to go offline.
- The SMF notifies iMaster NCE-Campus that the terminal goes offline. Then iMaster NCE-Campus updates the terminal status and records a terminal go-offline log.
- (Optional) iMaster NCE-Campus notifies the MSCG that the terminal goes offline.
Configuring Interconnection with the SMF on the Core Network
Prerequisites
You have obtained the IP address, accounting key, and authorization key of the SMF on the core network.
Procedure
- Choose from the main menu.
- Click
![]()
on the left to create an admission device group. Admission device groups are organized in a tree structure. A maximum of 128 admission device groups at up to four levels can be configured.![]()
- Select the created admission device group and click Create on the Admission device tab page.
- On the Create Admission Control Device page, enter the SMF name and IP address as planned, and set Device Series to Other.
![]()
- Enable RADIUS authentication parameters, set CoA Type to No CoA, and set other parameters as needed.
![]()
- Click OK.
on the left to create an admission device group. Admission device groups are organized in a tree structure. A maximum of 128 admission device groups at up to four levels can be configured.
Managing Terminals
Prerequisites
You have obtained the IMEI, IMSI, MSISDN, APN, username, and password of a terminal.
Procedure
- Choose from the main menu, click the Carrier's Wireless Network Terminal tab, select a custom category from the left pane, and click
![]()
to create a terminal group. On the page that is displayed, configure a terminal group name and an APN default account.![]()
![]()
The APN, username, and password are carried in the Internet access request sent by a terminal. The username and password set here must be the same as those carried in the request. Otherwise, terminal access will be denied.
- Select the created terminal group, click the Carrier's Wireless Network Terminal tab, and click Create to create a terminal.
![]()
![]()
- Either IMSI or IMEI, or both, in the basic information must be set. If both parameters are set, iMaster NCE-Campus will verify the two parameters during terminal authentication. If the IMSI or IMEI does not match, terminal access is denied.
- The MSISDN and terminal IP addresses are optional.
To import terminals in batches, choose More > Import, download the template, enter terminal information in the template, and then import the template to iMaster NCE-Campus.
![]()
- (Optional) After a terminal is added, you can delete or modify the terminal.
- Choose More > Export to export terminal information. The system automatically switches to the page and you can download the corresponding file to the local host to view terminal information.
- Select a terminal and click Delete to delete the terminal.
- Click
![]()
next to a terminal and modify the terminal information. - Select a terminal and click More > Add to Blacklist to blacklist the terminal.
- Select a terminal and choose More > Unblacklist to remove the terminal from the blacklist.
- Select multiple terminals and choose More > Batch Modify Custom Terminal Group to modify terminal groups to which the terminals belong in batches.
to create a terminal group. On the page that is displayed, configure a terminal group name and an APN default account.
next to a terminal and modify the terminal information.Configuring an Authentication Rule and an Authorization Rule for Cellular Network Terminal Access
Context
User access authentication is used for cellular network terminal access.
Procedure
- Choose from the main menu, click Create, and configure an authentication rule.
- Configure a rule name, set Authentication mode to User access authentication, and set Access mode to Cellular.
![]()
- (Optional) Configure location information. Select device groups (on the core network) and terminals to which this authentication rule is applicable.
![]()
- Configure authentication information.
- (Optional) Configure access parameters.
![]()
You can bind the terminal's IMSI, IMEI, and MSISDN for authentication on iMaster NCE-Campus. If the actual access parameter values of a terminal are inconsistent with the bound values on iMaster NCE-Campus, the authentication fails. You can enable access parameter self-learning to automatically bind terminal access parameters or manually bind terminal access parameters on the page. Self-learned access parameter values, such as the terminal MSISDN, are used as terminals attributes and will not be deleted even if access parameter self-learning is disabled.
If you bind a terminal's IMEI and MSISDN together on iMaster NCE-Campus but the actual MSISDN and IMEI of a terminal do not match with those bound values, iMaster NCE-Campus will automatically learn the terminal's IMEI and MSISDN. In addition, iMaster NCE-Campus can bind one access parameter to a maximum of two other access parameters.
Configuration example:
Assume that terminal A has connected to the campus network through the carrier Wi-Fi network, and its IMEI and MSISDN are IMEI1 and MSISDN1 on iMaster NCE-Campus, respectively. If terminal B with IMEI1 and MSISDN2 initiates authentication, the authentication succeeds and iMaster NCE-Campus automatically learns a new binding between IMEI1 and MSISDN2. When terminal C with IMEI1 and MSISDN3 initiates authentication, the authentication fails. This is because iMaster NCE-Campus has bound IMEI1 to two values, that is, MSISDN1 and MSISDN2, and cannot bind IMEI1 to any more values.
![]()
- Configure an authentication protocol. Currently, only PAP and CHAP are supported.
- (Optional) Configure access parameters.
- Set other parameters as needed and click OK.
- Configure an authorization rule.
![]()
(Optional) Configuring Interconnection with an MSCG
After a cellular network terminal is authenticated and authorized, it will initiate access to servers on the enterprise campus network. In this situation, you can configure interconnection between iMaster NCE-Campus and an MSCG to authenticate the terminal again, enhancing network security.
iMaster NCE-Campus can interconnect with an MSCG in the following two methods. A firewall functions as an MSCG and an online behavior management device, is configured with SSO. After being interconnected with ,iMaster NCE-Campus the firewall can manage online behavior of terminals that go online on iMaster NCE-Campus. Alternatively, a switch can function as an MSCG. In this case, iMaster NCE-Campus synchronizes IP-security group entries to the switch for Internet access control on terminals authorized with security groups.
Configuring Online Behavior Management
Procedure
- Choose from the main menu and click Create to add an online behavior management device.
![]()
- Log in to the online behavior management device and add iMaster NCE-Campus.
Add iMaster NCE-Campus to NGFW to implement association.
Choose Object > Authentication Server > TSM. Click Add, set parameters and click OK.
![]()
Click Detection to check the connectivity between NGFW and iMaster NCE-Campus.
If the connection between NGFW and iMaster NCE-Campus is normal, the system displays Server detection succeeded.
Create a user import policy for importing users and the organizational structure on iMaster NCE-Campus automatically.
Choose Object > User > User Import.
Click the Server Import tab and click Add.
Set parameters and click OK.
![]()
Select import, click Import Now, and click Yes in the dialog box that is displayed to execute the policy immediately and import the departments or users on iMaster NCE-Campus to NGFW.
Configure security policies to grant corresponding Internet access permission to authenticated users.
Choose Policy > Security Policy > Security Policy and click Add to configure security policies.
Configure a security policy for control traffic from the trust zone where users reside to the DMZ where the iMaster NCE-Campus server resides, so that users are authenticated on iMaster NCE-Campus.
Configure a security policy to control the DMZ where iMaster NCE-Campus resides to the local domain, so that iMaster NCE-Campus can communicate with NGFW.
Configure security policies for users to access the Internet.
Configure TSM SSO and enable the NGFW to implement online behavior management.
Choose Object > User > default, configure TSM SSO, and click Apply. Configure new users as temporary users and grant network access permission of the newuser user to the users.
![]()
Choose Object > User > Authentication Policy, click Add to configure authentication policies. Configure the action in the authentication policy for users to access the iMaster NCE-Campus server as no-authentication so that the users' authentication packets can go through NGFW to the iMaster NCE-Campus server. Configure the action in the authentication policy for users' service traffic to authentication exemption so that NGFW can obtain user information through SSO.
![]()
![]()
Configuring IP-Security Group Entry Synchronization
Procedure
- Choose from the main menu. Click Create to create a security group. You can search for security groups by IP address or domain name using fuzzy match.
![]()
- Click Import to import security groups in batches using an Excel template.
- Choose from the main menu. Click Create to configure IP-security group entry subscription.
![]()
- Click Full Delivery to deliver all IP-security group entries to the policy enforcement points added to the IP-security group entry subscription list.
- Choose from the main menu to view IP-security group entries.
Viewing Online Users
You can view end user status on iMaster NCE-Campus after cellular network terminals go online successfully.
Procedure
- View online user information on the Online User Control page.
Choose Admission > Admission Policy > Online User Control > Online User from the main menu.
- Click
![]()
and select IMEI, IMSI, and Carrier's Wireless Network Terminal Information. By doing so, you can view such information in the online user list.![]()
- View online user information in RADIUS login and logout logs and RADIUS accounting logs.
- Choose Monitoring > Event Logs > Terminal Authentication Logs > RADIUS Login and Logout logs from the main menu and click RADIUS Authentication Logs or RADIUS Accounting Logs tab.
- Click
![]()
and select IMEI, IMSI, and Carrier's Wireless Network Terminal Information. By doing so, you can view such information in the log list.![]()
and select IMEI, IMSI, and Carrier's Wireless Network Terminal Information. By doing so, you can view such information in the online user list.
and select IMEI, IMSI, and Carrier's Wireless Network Terminal Information. By doing so, you can view such information in the log list.
Guest Management
Configuring a Guest Administrator
Context
When a large number of guests want to access the network, a tenant administrator can specify multiple guest administrators by account or role to manage the guests. The guest administrators can manage these guests separately on the self-service page to improve the processing efficiency.
Procedure
- Choose from the main menu.
- Click the By Account or By Role tab and create a guest administrator.
- Click the By Account tab and then click Create.
![]()
- Click the By Role tab and then click Create.
![]()
- Click the By Account tab and then click Create.
Related Operations (Self-Service Portal)
Guest administrators can register and manage guest accounts, approve guest account applications, and view account approval records on the self-service portal. To allow guest administrators to create or import guest accounts on the self-service portal, tenant administrators need to enable Allow to create guest accounts when creating guest administrators.
Guest administrators can log in to the self-service portal via the authentication success page or access the self-service portal at https://portal server IP address:19008/selfService/index.html. The username for login is tenant name\guest administrator name.
Guest administrators can manage guest accounts on the page.
Guest administrators can approve guest account applications on the page.
Guest administrators can view guest account approval records on the page.
After logging in to the self-service Portal, guest administrators can view online self-service users on the page and click Terminate the session to log out a self-service user.
Users can associate mobile numbers and email addresses with their accounts on the page.
Parameter Description
Parameter |
Description |
|
|---|---|---|
By Account |
Local and synchronized AD/LDAP accounts |
Uses a local account or a synchronized AD/LDAP account as the account for the guest administrator. |
Unsynchronized AD/LDAP account |
Uses an unsynchronized AD/LDAP account as the account for the guest administrator. You need to specify the address of the AD/LDAP server where the account is located and specify the account for the guest administrator. |
|
Guest Account Creation |
Allows guest administrators to create guest accounts on the self-help service page. |
|
Visible Password |
Whether to make passwords visible. When this function is enabled, guest administrators can view guest account passwords on the self-service portal. |
|
By Role |
Role |
Configures an account as the guest administrator. |
Guest Account Creation |
Allows guest administrators to create guest accounts on the self-help service page. |
|
Visible Password |
Whether to make passwords visible. When this function is enabled, guest administrators can view guest account passwords on the self-service portal. |
|
Configuring Guest Access Through Self-Registered Accounts
Context
Users who need to access the network temporarily in specific places are regarded as guests. If there are a large number of guests, guests can register accounts by themselves. iMaster NCE-Campus then authorizes the accounts to allow guest access.
Prerequisites
If approval notifications or guest notifications are set via SMS, an SMS server must be deployed in advance. If approval notifications or guest notifications are sent via email, an email server must be deployed in advance.
Procedure
- Choose from the main menu to create an SMS or email notification template.
![]()
- Choose from the main menu and configure a guest account policy, including the user group to which a guest belongs, approval mode, and guest notification mode.
![]()
- (Optional) Customize a portal page. Skip this step if you use a default customized page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a customization template. In this template, select Generic Auth Template or User Name and Password Template as the system template. - If Generic Auth Template is selected, reference the guest account policy configured in the previous step in the customization template for portal page customization.
- After a portal page is customized, click Save and Release.
- (Optional) Configure a portal page push policy. Skip this step if the authentication point uses a fast page push mode.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create to create a portal page push policy. Here, you need to set the authentication method to username and password authentication, select the portal page customized in the previous step as the push page, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Here, you need to set the authentication method to User Access Authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point. When an advanced page push mode is used, set the login mode to username and password authentication. If a portal page of the Generic Auth Template type has been configured in the selected portal page push policy and attached to a guest account policy, the username and password authentication parameters configured in this guest account policy take effect. Otherwise, the settings under user self-registration configured in this step take effect. If neither is configured, the default self-registration user policy in Advanced Parameters on the page takes effect. For details about how to set the other parameters, see Configuring an Authentication Point.
- If the approval mode defined in the guest account policy is approval by the tenant administrator, the tenant administrator can choose from the main menu to approve guest accounts after guests register accounts using a mobile number or an email address.
- If the approval mode defined in the guest account policy is approval by the tenant administrator, the tenant administrator can choose from the main menu to approve guest accounts after guests register accounts using a mobile number or an email address.
If the approval mode defined in the guest account policy is approval by the guest administrator, the guest administrator can approve guest accounts on the self-help service page after guests register accounts using a mobile number or an email address. The approver can be specified by the tenant administrator or be the receptionist specified during guest registration. In the former method, the approver must be a guest administrator specified by the tenant administrator. In the latter method, the approver can be any guest administrator.
If the approval mode defined in the guest account policy is receptionist approval (email activation), the receptionist can click the link in the email to activate the accounts after guests register accounts using a mobile number or an email address. The receptionist specified during guest registration must be an enabled user account not in the blacklist. Unsynchronized AD/LDAP accounts cannot be used as receptionists.
to create a customization template. In this template, select Follow-up Procedure
After a guest is authenticated successfully and goes online, you can choose from the main menu to view the guest account.
After a guest account is successfully approved, you can choose and click the Guest Approval Logs tab to view the approval log.
Parameter Description
Parameter |
Description |
|---|---|
Name |
Name of an SMS or email notification template. |
Type |
Type of a notification template. The options are: guest notification template and approval notification template. |
Title |
Title of an SMS or email notification. |
Content |
Content of an SMS or email notification. |
Parameter |
Description |
|---|---|
Name |
Name of a guest account policy. |
Username policy |
User name policy in a guest account policy. Currently, three modes are supported: account, mobile number, and email. |
Password type |
Password type set during guest self-registration. If an account or email address is specified in a user name policy, Enter the password manually and System generated password are supported. If a mobile number is specified in a user name policy, Enter the password manually, System generated password, and SMS verification code are supported. |
Password Policy /Password length |
Password policy for the system to generate a password. The password policy defines the characters that a password can contain, such as digits, letters, and special characters, and defines the password length. The password can contain a string of 6 to 28 characters. This parameter is configurable only when the password type is set to System generated password. |
Effective time/Validity period |
Time when a guest account takes effect and the validity period of the guest account. The effective time has three options: Take effect upon creation, Take effect upon first login, and Self-defined during approval. |
Guest user group |
User group to which a self-registered guest belongs. |
Guest role |
Role attached to a self-registered guest account. |
Approval mode |
Approval mode after guest registration. Currently, four approval modes are supported: Approval without approval, Tenant administrator approval, Guest administrator approval, and Receptionist approval (email activation). You can specify whether to notify the approver of a guest registration by SMS or email when a tenant administrator or a guest administrator is configured to approve guest accounts. If you set this parameter to Guest administrator approval, the approver can be specified by the tenant administrator or specified by guests when they register guest accounts. If you set this parameter to Receptionist Approval (Email activation), you need to configure the email notification template, email format, and activation link validity period. After the activation is successful, the activation success message will be sent to the guest or receptionist. |
Guest notification mode |
Notification mode after a guest account is successfully registered. The options are as follows:
|
Change the password upon the first login |
Whether to change the password upon next login. When this function is enabled, guests must change their passwords upon first login. This function is disabled by default. |
Repeated registration is allowed |
Whether to allow repeated registration of a guest account. The setting can be applied to all guest accounts or to only expired guest accounts. This function is enabled by default. |
Limit the registration frequency |
Allowed registration frequency of a guest account. You can specify Registration frequency cycle and Maximum number of registrations in a measurement period to restrict the registration frequency of a guest account. |
Account field |
Account field that needs to be entered by a guest when the guest registers an account. You need to select required accounts fields on the account registration page when you customize a set of portal pages. You can configure customized fields as required and sort accounts fields in the desired order. The order defined in the guest account policy determines the sequence of account fields displayed on the account registration page. When you customize the account registration page, you can only select or deselect account fields but cannot adjust the field sequence. NOTE:
The information entered by guests in account fields is not encrypted in the system. Therefore, you are advised not to customize account fields that may involve personal privacy data. |
Configuring Guest Access Through One-Click Authentication by Account, Email Address, or Mobile Number
Context
The one-click authentication solution is used to quickly authenticate guests and allow them to access networks without the need to register an account.
Pre-configuration Tasks
If the guest notification mode is set to SMS, an SMS server must be deployed in advance. If the guest notification mode is set to email, an email server must be deployed in advance.
Procedure
- Choose from the main menu. Configure the user group to which a guest belongs, approval mode, and guest notification mode.
![]()
In the one-click authentication scenario, the following parameters do not take effect: User name policy, Password type, Effective time, Validity period, Approval method, Guest notification method, Change password upon initial login, and Allow repeated registrations.
![]()
- (Optional) Customize a portal page. Skip this step if you use a default customized page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a customization template. In this section, select the one-click authentication template as the system template. - Reference the guest account policy configured in the previous step in the customization template for portal page customization.
- After a portal page is customized, click Save and Release.
- (Optional) Configure a portal push policy. Skip this step if the authentication point uses a fast page push mode.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create to create a portal page push policy. Here, you need to set the authentication method to one-click authentication, select the portal page customized in the previous step as the push page, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Here, you need to set the authentication method to User Access Authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point. When an advanced page push mode is used, set the login mode to one-click authentication. For details about how to set the other parameters, see Configuring an Authentication Point.
to create a customization template. In this section, select the Follow-up Procedure
After a guest is authenticated successfully and goes online, you can choose from the main menu to view the guest account.
After a guest account is successfully approved, you can choose and click the Guest Approval Logs tab to view the approval log.
Configuring Guest Access Using a Public QR Code
Context
After guests connect to a Wi-Fi network using their mobile phones, they can scan QR codes posted in public areas for authentication to easily access a network.
Certification process
The following figure shows the process for authenticating guests that connect to the network by scanning a public QR code.
An end user uses a mobile phone to scan a public QR code. A public QR code is similar to a URL; therefore, a guest obtains a URL by scanning a public QR code. The administrator can choose on iMaster NCE-Campus and specify the URL prefix for a public QR code in Public QR code parameters. The URL carries account information matching the public QR code.
The WAC detects that the user is not authenticated and redirects the URL entered by the user to the portal authentication page. The authentication page is determined by the URL for portal authentication configured on the WAC and carried parameters.
The terminal automatically sends the redirection URL to the portal server.
The portal server pushes the public QR code authentication page customized by the administrator on iMaster NCE-Campus to the terminal.
The terminal automatically initiates a portal authentication request, and the end user does not need to click Login. The authentication request carries account information matching the public QR code.
The portal server sends a login request to the WAC, carrying account information matching the public QR code.
The WAC sends an authentication request carrying account information matching the public QR code to the RADIUS server.
The RADIUS server sends an Access-Accept packet containing the user authorization result to the WAC.
The WAC sends an accounting request to the RADIUS server.
The RADIUS server sends an accounting response to the WAC and adds the end user to its online user list.
The WAC sends the authentication result to the portal server and adds the end user to its online user list.
The portal server returns the authentication result to the end user and adds the end user to its online user list. The authentication success page is displayed on the user's mobile phone.
Procedure
- Choose from the main menu, enable Public QR code, and set parameters.
![]()
- Choose from the main menu and click Create to create a public QR code.
![]()
Click OK. A public QR code is generated. In the Upload logo area, select the enterprise logo image and click Upload to add the enterprise logo to the public QR code. Click Export the QR code to export the public QR code to the local computer, print it, and paste it in the public area.
![]()
- (Optional) Customize a portal page. If you want to use the default portal page, skip this step.
- Choose from the main menu.
- Click
![]()
to create a custom template. Set System template to Public QR Code Auth Template. - After the configuration is complete, click Save and then Release.
- After a portal page is customized, click Save and Release.
- (Optional) Configure a portal page push policy. If the fast push mode is configured on the authentication point, you do not need to perform this step.
- Choose from the main menu.
- Click Create to configure a portal page push policy. Set Authentication mode to Public QR code authentication , set Push page to the customized portal page, and set First page to push to Authentication page. For details about other parameter settings, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Here, you need to set the authentication method to User Access Authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point. When Push mode is set to Advanced, set Authentication Policy to Public QR code. For details about other parameter settings, see Configuring an Authentication Point.
to create a custom template. Set System template to Public QR Code Auth Template.Parameter Description
Parameter |
Description |
|---|---|
URL prefix |
Prefix of the public QR code URL, which is used only to trigger portal page pushing. Set the link address to any address that cannot be accessed before authentication. |
URL encryption key/Confirm URL encryption key |
Key for encrypting the URL used by users to access a network by scanning a public QR code. It enhances user access security. |
Configuring Guest Access Using Accounts Created by Administrators
Context
A guest refers to a person who needs to access the network temporarily at a specific location. If you have obtained guest accounts in advance, record the guest accounts on iMaster NCE-Campus in advance and grant specified permissions to the guest accounts.
Pre-configuration Tasks
If guest notifications are sent via SMS, an SMS server has been deployed in advance. If guest notifications are sent via email, an email server has been deployed in advance.
Procedure
- Choose from the main menu to create a guest account. Two guest account types are supported: common guest and passcode guest.
- Click Create to create a guest account.
![]()
- Click Batch Create to create common guest accounts or passcode guest accounts in batches. After parameters are set, the system automatically creates guest accounts.
![]()
- Click Import to import common guest accounts or passcode guest accounts in batches using an Excel template.
![]()
- Click Export All to export all guest account information in batches.
- Click Create to create a guest account.
- Choose from the main menu to create an SMS or email notification template.
![]()
- (Optional) Customize a portal page. Skip this step if you use a default portal page.
- Choose from the main menu.
- On the page Customization tab, click
![]()
to create a custom portal page template. In this template, select User Name and Password Template as the system template. - After a portal page is customized, click Save and Release.
- (Optional) Configure a portal page push policy. Skip this step if the authentication point uses a fast page push mode.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create to create a portal page push policy. Here, you need to set the authentication method to username and password authentication, select the portal page customized in the previous step as the push page, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Here, you need to set the authentication method to User Access Authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point. When an advanced page push mode is used, set the login mode to username and password authentication. If a portal page of the Generic Auth Template type has been configured in the selected portal page push policy and attached to a guest account policy, the username and password authentication parameters configured in this guest account policy take effect. Otherwise, the settings under user self-registration configured in this step take effect. If neither is configured, the default self-registration user policy in Advanced Parameters on the page takes effect. For details about how to set the other parameters, see Configuring an Authentication Point.
to create a custom portal page template. In this template, select Related Operations
- Reset the password of a guest account.
Select the guest account whose password needs to be changed and click
![]()
to reset the password.![]()
Click OK and select SMS Notification or Mail notification to reset the password as required.
to reset the password.
Description
Parameter |
Description |
|
|---|---|---|
User name |
User name and password used for common guest authentication. |
|
Password |
||
Confirm password |
||
Role |
Role attached to the common guest. |
|
Email address and phone number of a user. When resetting passwords, a user receives a verification code via an email or an SMS message and sets a new password based on the verification code. |
||
Mobile number |
||
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. |
|
Effective time |
Time when the account takes effect and time when the account expires. The options are as follows:
|
|
Expiration time |
||
User group |
User group to which the common guest belongs. |
|
Change password upon next login |
Whether to change the password upon next login. When this function is enabled, guests must change their passwords upon first login. This function is enabled by default. |
|
Name |
Name of the user who applies for a common guest account, user's company, and reason for applying for a common guest account. |
|
Company |
||
Application reason |
||
Terminals Bound to an Access Device |
Terminal IP address |
Terminal IP address bound to the user account. |
Terminal MAC address |
Terminal MAC address bound to the account. The value must be in the format **-**-**-**-**-**, such as 11-11-11-11-11-11. |
|
Bind the ESN |
Terminal ESN bound to the account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
SIM/USIM's IMSI |
IMSI of an SIM card. The value is a string of 1 to 15 characters consisting of digits (0 to 9). IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Bind an access device |
Access device IP address |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
Parameter |
Description |
|
|---|---|---|
Passcode |
Passcode number. |
|
Role |
Role attached to the passcode guest. |
|
Maximum number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. |
|
Effective time |
Time when the passcode guest account takes effect. The options of this parameter are as follows:
|
|
Expiration time |
||
User group |
User group to which the passcode guest belongs. |
|
Company |
Company of the user who applies for a passcode guest account, and reason for applying for an account. |
|
Application reason |
||
Access binding information |
IP address of the bound terminal |
Terminal IP address bound to the user account. |
MAC address of the bound terminal |
Terminal MAC address bound to the user account. The value must be in the format **-**-**-**-**-**, such as 11-11-11-11-11-11. |
|
Bind the ESN |
Terminal ESN bound to the user account. The value is a string of 20 characters consisting of uppercase letters (A to Z) and digits, such as 2102310WYGG6EC914846. |
|
IMSI bound to the SIM or USIM card |
International mobile subscriber identity (IMSI) or SIM card number bound to the user account. The value is a string of 1 to 15 digits. IMSIs are sensitive data. Exercise caution when using IMSIs in case of data leakage. |
|
Binding an Access Device |
IP address of the access device |
IP address of the access device to which a user connects. |
Port |
Port number of the access device to which a user connects. |
|
VLAN |
VLAN of the access device to which a user connects. |
|
Parameter |
Description |
|---|---|
Number of accounts |
Number of common guest accounts to be created in batches. |
Username policy |
Policy for automatically generating user names for guests. An automatically-generated user name is in the format User name prefix + Padding +User name suffix. The user name prefix and suffix are optional. You can configure a length and a policy for the padding. The following provides the available policies for the padding:
|
Username prefix |
|
Username padding length |
|
Username suffix |
|
Password policy |
Policies for automatically generating passwords for common guests and for setting the password length. The following provides the available password policies:
NOTE:
After successful creation, in the creation result dialog box that is displayed, you can view the initial passwords automatically generated according to the preceding configuration and export user information into an Excel file. |
Password length |
|
Max. number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. |
Effective time |
Time when the account takes effect and time when the account expires. The options are as follows:
|
Expiration time |
|
User group |
User group to which the common guests belong. |
Role |
Role attached to the common guests. |
Change password upon next login |
Whether to change the password upon next login. When this function is enabled, guests must change their passwords upon first login. This function is enabled by default. |
Company |
Company of the user who applies for a guest account, and reason for applying for an account. |
Application reason |
Parameter |
Description |
|---|---|
Number of accounts |
Number of passcode guests to be created in batches. |
Passcode generation policy |
Policies for automatically generating passcodes and for setting the passcode length. The following provides the available passcode policies:
|
Passcode length |
|
Maximum number of terminals |
Maximum number of terminals that can use the same account to connect to the network simultaneously. |
Effective time |
Time when the account takes effect and time when the account expires. The options are as follows:
|
Expiration time |
|
User group |
User group to which the passcode guests belong. |
Role |
Role attached to the passcode guests. |
Company |
Company of the user who applies for a passcode guest account, and reason for applying for an account. |
Application reason |
Parameter |
Description |
|---|---|
Import user name list |
List of common guests to be created. NOTE:
You need to click |
Password policy |
Policies for automatically generating passwords for common guests and for setting the password length. The following provides the available password policies:
|
Password length |
|
Effective time |
Time when the account takes effect and time when the account expires. The options are as follows:
|
Expiration time |
|
User group |
User group to which the common guests belong. |
Change password upon next login |
Whether to change the password upon next login. If this parameter is enabled, users need to change the initial passwords upon next login. |
to download an Excel template, fill in the guest information, and then upload the modified Excel file to the system.Parameter |
Description |
|---|---|
Import user name list |
List of passcode guest accounts to be created. NOTE:
You need to click |
Effective time |
Time when the account takes effect and time when the account expires. The options are as follows:
|
Expiration time |
|
User group |
User group of the passcode guests belong. |
to download an Excel template, fill in the guest information, and then upload the modified Excel file to the system.Parameter |
Description |
|---|---|
Name |
Name of an SMS or email notification template. |
Type |
Type of a notification template. The options are: guest notification template and approval notification template. |
Title |
Title of an SMS or email notification. |
Content |
Content of an SMS or email notification. |
Parameter |
Description |
|---|---|
Name |
Name of a guest account policy. |
Username policy |
User name policy in a guest account policy. Currently, three modes are supported: account, mobile number, and email. |
Password type |
Password type set during guest self-registration. If an account or email address is specified in a user name policy, Enter the password manually and System generated password are supported. If a mobile number is specified in a user name policy, Enter the password manually, System generated password, and SMS verification code are supported. |
Password Policy /Password length |
Password policy for the system to generate a password. The password policy defines the characters that a password can contain, such as digits, letters, and special characters, and defines the password length. The password can contain a string of 6 to 28 characters. This parameter is configurable only when the password type is set to System generated password. |
Effective time/Validity period |
Time when a guest account takes effect and the validity period of the guest account. The effective time has three options: Take effect upon creation, Take effect upon first login, and Self-defined during approval. |
Guest user group |
User group to which a self-registered guest belongs. |
Guest role |
Role attached to a self-registered guest account. |
Approval mode |
Approval mode after guest registration. Currently, four approval modes are supported: Approval without approval, Tenant administrator approval, Guest administrator approval, and Receptionist approval (email activation). You can specify whether to notify the approver of a guest registration by SMS or email when a tenant administrator or a guest administrator is configured to approve guest accounts. If you set this parameter to Guest administrator approval, the approver can be specified by the tenant administrator or specified by guests when they register guest accounts. If you set this parameter to Receptionist Approval (Email activation), you need to configure the email notification template, email format, and activation link validity period. After the activation is successful, the activation success message will be sent to the guest or receptionist. |
Guest notification mode |
Notification mode after a guest account is successfully registered. The options are as follows:
|
Change the password upon the first login |
Whether to change the password upon next login. When this function is enabled, guests must change their passwords upon first login. This function is disabled by default. |
Repeated registration is allowed |
Whether to allow repeated registration of a guest account. The setting can be applied to all guest accounts or to only expired guest accounts. This function is enabled by default. |
Limit the registration frequency |
Allowed registration frequency of a guest account. You can specify Registration frequency cycle and Maximum number of registrations in a measurement period to restrict the registration frequency of a guest account. |
Account field |
Account field that needs to be entered by a guest when the guest registers an account. You need to select required accounts fields on the account registration page when you customize a set of portal pages. You can configure customized fields as required and sort accounts fields in the desired order. The order defined in the guest account policy determines the sequence of account fields displayed on the account registration page. When you customize the account registration page, you can only select or deselect account fields but cannot adjust the field sequence. NOTE:
The information entered by guests in account fields is not encrypted in the system. Therefore, you are advised not to customize account fields that may involve personal privacy data. |
Configuring Guest Access Using a Facebook Account
Context
In public areas such as shopping malls and airports, users can use a Facebook account for authentication to easily access a network. In the Facebook authentication scenario, iMaster NCE-Campus needs to connect to Facebook.
Prerequisites
iMaster NCE-Campus and the Facebook system can communicate with each other.
Procedure
- Apply for a Facebook account.
If end users want to use their own Facebook accounts for authentication, the enterprise must apply for a Facebook account of the developer type from Facebook so that the enterprise is authorized by Facebook.
- Open a web browser.
- Enter https://developers.facebook.com/ in the address box.
- Click Log In in the upper right corner of the page to register a Facebook account.
- Create a Facebook application.
- Open a web browser, enter https://developers.facebook.com/ in the address box, log in using a Facebook account, and choose My Apps > Add New App.
Upon the first login, click Get Started in the upper right corner on the page to register as a developer. Then you can create an application.
![]()
- Set Display Name and Contact Email and click Create App ID.
![]()
- On the dashboard, click Set Up under Facebook Login.
![]()
- Choose , and set Valid OAuth redirect URIs and Deauthorize Callback URL.
![]()
Table 5-220 Parameter descriptionParameter
Data Type
Value
Valid OAuth redirect URIs
https
The value is the URL of the Portal authentication page.
To obtain the URL, log in to iMaster NCE-Campus, choose from the main menu, select the default or customized Portal page, and click the authentication page for preview. You need to add the URLs of Portal authentication pages on both the PC and mobile phone. The following URLs are provided as examples:
PC: https://IP Address:19008/portalpage/00000000-0000-0000-0000-000000000000/facebook01/pc/auth.html
Mobile phone: https://IP Address:19008/portalpage/00000000-0000-0000-0000-000000000000/facebook01/phone/auth.html
NOTE:- IP Address indicates the southbound service IP address, which is specified during the iMaster NCE-Campus installation.
- 00000000-0000-0000-0000-000000000000 is the fixed field on the default page. A field is randomly generated on the customized page. You can obtain the required URLs by referring to the preceding method.
- When a portal page is customized on iMaster NCE-Campus, the page push protocol of the customized page must be the same as the value specified here.
Deauthorize Callback URL
https
The value is the same as that of Valid OAuth redirect URIs.
- Choose , and set Privacy Policy URL and Category.
![]()
Table 5-221 Parameter descriptionParameter
Value
Privacy Policy URL
Privacy policy URL. Facebook requires a privacy policy for each Facebook application. A dedicated website can be set up for adding privacy policies. If the URL is for test only, you can set this parameter to www.facebook.com.
For details on how to add a privacy policy, see http://wp4fb.com/how-to-add-a-privacy-policy-to-your-apps/.
Category
Utility & Productivity
- Click Save changes.
- Choose and check the values of App ID and App Secret for each application. You can click Show to view the value of App Secret.
Record the values of App ID and App Secret. The values are required when you configure Facebook interconnection on iMaster NCE-Campus.
![]()
- Click App Review, and set Make 123 public to Yes.
![]()
- Open a web browser, enter https://developers.facebook.com/ in the address box, log in using a Facebook account, and choose My Apps > Add New App.
- Set interworking parameters on iMaster NCE-Campus.
- Choose from the main menu.
- Enable Facebook authentication and configure interconnection with Facebook.
The values of App ID and App secret are the same as those on the Facebook system.
![]()
- (Optional) Customize a portal page. Skip this step if you use a default customized page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a customization template. In this template, select Social Media Template as the system template.
- (Optional) Configure a portal page push policy. Skip this step if the authentication point uses a fast page push mode.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create to create a portal page push policy. Here, you need to set the authentication method to Social media authentication, select the portal page customized in the previous step as the push page, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Here, you need to set the authentication method to User Access Authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point.
Configure Portal authentication on APs, WACs, or switches based on the network type. Access from unauthenticated users to the following domain names must be allowed, so that unauthenticated users can communicate with the Facebook server after connecting to the SSID for the first time: connect.facebook.net, *.facebook.com, and *.fbcdn.net.
For detailed operations, see Configuring an Authentication Point.
- To configure a WAC to allow access from unauthenticated users to the preceding domain names, run the following commands on the WAC:
<AC> system-view [AC] passthrough-domain name connect.facebook.net id 1 [AC] passthrough-domain name *.facebook.com id 2 [AC] passthrough-domain name *.fbcdn.net id 3 [AC] acl 6000 // Create an ACL numbered from 6000 to 6031 and configure rules to permit access to the preceding domain names. [AC-acl-adv-6000] rule 1 permit ip destination passthrough-domain connect.facebook.net [AC-acl-adv-6000] rule 5 permit ip destination passthrough-domain *.facebook.com [AC-acl-adv-6000] rule 10 permit ip destination passthrough-domain *.fbcdn.net [AC-acl-adv-6000] quit [AC] free-rule-template name default_free_rule // Enter the authentication-free rule profile view. [AC-free-rule-default_free_rule] free-rule acl 6000 // Define an authentication-free rule by the configured ACL. [AC-free-rule-default_free_rule] quit
- To configure devices of other types to allow access from unauthenticated users to the domain names, add the domain names to the default permit rule.
For details about how to configure an authentication point, see Configuring an Authentication Point.
- To configure a WAC to allow access from unauthenticated users to the preceding domain names, run the following commands on the WAC:
to create a customization template. In this template, select Parameters
Parameter |
Description |
|---|---|
App ID |
The two parameters indicate the developer identifier and the corresponding password respectively allocated by the Facebook platform. You can view the identifier and password on the Facebook platform GUI. |
App secret |
|
Mapped user group |
Mappings between Facebook accounts and user groups. This function is used to control the rights of guest accounts. By using this function, you can map all Facebook accounts to a user group so that you can set rights for the accounts in a unified manner. |
Mapping Role |
Whether to map all Facebook accounts to the same role. This function allows you to configure rights for accounts in 10 unified manner. |
Configuring Guest Access Using a Twitter Account
Context
iMaster NCE-Campus can associate with a Twitter server to authenticate end users based on their existing social media accounts. In this way, end users do not need to register new accounts for identity authentication. They can use their Twitter account and password to pass authentication on the Service Manager (SM) page and obtain the network access permission.
Authentication Process
An end user attempts to connect to the network.
When detecting that the end user is unauthenticated, the access device redirects the user's access request to the URL of the portal authentication page configured on it.
- The terminal automatically sends the redirection URL to the portal server.
- The portal server pushes an authentication page customized on iMaster NCE-Campus to the terminal. The default page is as follows:
![]()
The user clicks the Twitter icon to initiate an authentication request.
- The portal server requests an authentication page from the Twitter server.
![]()
The portal server needs to connect to the Twitter server.
The Twitter server verifies whether parameters for interconnection with iMaster NCE-Campus are consistent. If so, the Twitter server returns the login page.
The portal server returns the login page to the user.
The user enters the user name and password on the login page.
The Twitter server verifies the user name and password, and returns the authentication result containing the access token to the terminal.
The terminal sends the access token to the portal server.
The portal server obtains user information through the Twitter server based on the access token.
The Twitter server returns user information.
The portal server sends a login request carrying the account identifier to the WAC. The portal server and WAC use CHAP for authentication; therefore, the portal server sends a challenge request packet and the WAC replies a challenge response packet before this step. The two steps are omitted in the flowchart.
The access device sends an authentication request carrying the account identifier to the RADIUS server.
The RADIUS server sends an authentication accept packet carrying the authorization result to the access device.
The access device sends an accounting request to the RADIUS server.
The RADIUS server sends an accounting response to the access device and adds the end user to its online user list.
The access device sends the authentication result to the portal server and adds the end user to its online user list.
The portal server sends the authentication result to the terminal and adds the user to the local online user list.
Procedure
- Apply for a Twitter account.
To enable end users to use Twitter accounts for guest identity authentication, enterprises must request their own Twitter accounts from Twitter to obtain the authorization information from Twitter.
Launch a web browser, access the Twitter official website at https://twitter.com/, and register an account.
- Create a Twitter application.
Enter https://apps.twitter.com/ in the address box. On the page that is displayed, log in using a Twitter account, and click Create New App.
![]()
- Enter application information.
![]()
You need to enter URLs of Portal authentication pages on both the PC and mobile phone for Callback URLs. To obtain the URL, log in to iMaster NCE-Campus, choose from the main menu, select the default or customized Portal page, and click the authentication page for preview. The following URLs are provided as examples:
PC: https://IP Address:19008/portalpage/00000000-0000-0000-0000-000000000000/facebook01/pc/auth.html
Mobile phone: https://IP Address:19008/portalpage/00000000-0000-0000-0000-000000000000/facebook01/phone/auth.html
- IP Address indicates the southbound service IP address, which is specified during the iMaster NCE-Campus installation.
- 00000000-0000-0000-0000-000000000000 is the fixed field on the default page. A field is randomly generated on the customized page. You can obtain the required URLs by referring to the preceding method.
![]()
- Click Create your Twitter application.
![]()
- Click Settings, select Allow this application to be used to Sign in with Twitter, and click Update Settings.
![]()
- Click Keys and Access Tokens.
![]()
Save the API Key and API Secret.
- On iMaster NCE-Campus, set parameters for association with the social media server.
Choose .
Toggle Twitter on and set association parameters.
![]()
- Customize a portal page.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a customization template. In this section, select Social Media Template as the system template.![]()
- In the page editing area, customize authentication pages and authentication success pages for mobile phones and PCs as required. After page customization is completed, click Save and Release.
![]()
- Configure a portal page push policy.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create a create a portal page push policy. Set the authentication method to social media authentication, select the portal page customized in the previous step as the push page, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Push Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication method to portal authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point.
Configure Portal authentication on APs, WACs, or switches based on the network type. Access from unauthenticated users to the following domain names must be allowed, so that unauthenticated users can communicate with the Twitter server after connecting to the SSID for the first time: api.twitter.com, abs.twimg.com, mobile.twitter.com, and twitter.com.
For details about how to permit access to the preceding domain names, see 9.
For details about how to configure an authentication point, see Configuring an Authentication Point.
to create a customization template. In this section, select Social Media Template as the system template.
Configuring Guest Access Through One-Click WeChat Portal Authentication
Prerequisites
The DNS server has been configured to resolve domain names.
One-click WeChat portal authentication is currently unavailable because the WeChat configuration background and corresponding APIs are disabled by WeChat.
Context
In public areas such as shopping malls and airports, users can follow a WeChat official account for authentication to easily access a network. In the WeChat authentication scenario, iMaster NCE-Campus needs to interwork with WeChat.
Procedure
- Set interworking parameters on the WeChat Official Accounts Platform.
- Apply for an enterprise's WeChat official account and pass the Tencent authentication. For details, see guidance provided on the WeChat Official Accounts Platform.
Record the values of AppID and AppSecret, which need to be set when you set parameters for interworking with WeChat on iMaster NCE-Campus.
- Log in to the WeChat Official Accounts Platform, choose Function > Add Plug-ins, and add functional plug-ins Wi-Fi and Store MiniProgram.
- Choose Function > Store MiniProgram, click
![]()
, and add store information. - Choose Function > Wi-Fi, click the Device Management tab, click
![]()
, and add a portal device.The network name must be the same as the SSID of the portal device.
- (Optional) Choose Development > Basic Configuration, and view AppID of the official account. If you forgot AppSecret, you can click Reset to get a new value of AppSecret.
- Configure an IP address whitelist. The IP addresses in the whitelist are accessible to the WeChat official account.
In Huawei public cloud for China scenarios, the Get access_token interface can be invoked only after NAT gateway addresses of iMaster NCE-Campus, including 114.115.167.144, 117.78.34.72, 117.78.60.139, and 49.4.1.252, are added to the IP whitelist accessible to the public account. For details, see Added access white list protection for access_token interface.
In private cloud scenarios, you need to add the public IP addresses used by the private cloud with iMaster NCE-Campus deployed for Internet access to the IP address whitelist.
- Apply for an enterprise's WeChat official account and pass the Tencent authentication. For details, see guidance provided on the WeChat Official Accounts Platform.
- Set interworking parameters on iMaster NCE-Campus.
- Choose from the main menu.
- Enable WeChat authentication and configure interconnection with WeChat.
The values of App ID and App secret must be the same as those on the WeChat Official Accounts Platform.
![]()
, and add store information.
, and add a portal device.
Parameters
Parameter |
Description |
|
|---|---|---|
App ID |
The two parameters indicate the developer identifier and the corresponding password respectively allocated by the WeChat Official Accounts Platform. You can view the identifier and password on the WeChat Official Accounts Platform. |
|
App secret |
||
Obtain tokens from a third-party server |
- |
Whether to obtain a token from a third-party server. If this function is enabled, the system invokes the interface of a third-party server to obtain a token based on configured parameters. If this function is disabled, the system obtains a token from the WeChat server. The following describes how to set related parameters if you invoke an interface to obtain a token from the Huawei token server. The HTTP Method of this interface is Get and the coding format of the request message is UTF-8. The URL for invoking the interface is as follows: https://apigw-beta.huawei.com/api/wechat/getAccessTokenExternal?appId=wxdcc70cd0f4232779&thirdDomain=http://smartspace.huawei.com&X-HW-ID=com.huawei.cbg.cptp.mt&X-HW-APPKEY=eXRKTCVSeENwM3JCYjl1Mg== If the token is successfully obtained, the following information is returned: {"errcode":0,"errmsg":"success","data":"{"access_token":"10_k4g3w82qmr0tYlWb8xwprnDDpQ0WwgPXnKGp9k8w--jPCCIklHS0ZwB72JLI4kZ88NQhb_LtAxXFqy5fNeL0jc-2i3K1OZr6o73JzKPUvUq9Q7xymoJPnI-iFqTv5R4SS0MCmJQ94PHfb5J-ITMhACAUFY","expired_time":1260}"} |
Request sending mode |
Mode in which a request message for obtaining a third-party token is sent. The system supports both Get and Post modes. If the invoked interface is the preceding example, the value of this parameter is Get. The value must be the same as the mode of invoking the interface provided by the third-party server to obtain a token. |
|
Coding format |
Coding format of a request message. The system supports both UTF-8 and GBK formats. If the invoked interface is the preceding example, the value of this parameter is UTF-8. The value must be the same as the mode of invoking the interface provided by the third-party server to obtain a token. |
|
URL address |
Unique identifier of the interface to be invoked. It is the content before a question mark (?) of the URL for a request message interface. If the invoked interface is the preceding example, the value of this parameter is apigw-beta.huawei.com/api/wechat/getAccessTokenExternal. |
|
Request parameters |
Parameters to be transferred. The part after a question mark (?) of the URL address for a request message interface is used to transfer specific parameters and values to the interface. Request parameters can contain {APP_ID} and {APP_SECRET}, whose values are obtained from the APP ID and APP Secret parameters on the GUI, respectively. The format and content are specified in the configuration interface document of the third-party token server. If the invoked interface is the preceding example, the value of this parameter is appId={APP_ID}&thirdDomain=http://smartspace.huawei.com&X-HW-ID=com.huawei.cbg.cptp.mt&X-HW-APPKEY=eXRKTCVSeENwM3JCYjl1Mg==. |
|
Response success tag |
Interface response message that indicates whether the interface is successfully invoked. If the invoked interface is the preceding example, the value of this parameter is as follows: "errcode":0,"errmsg":"success". |
|
Response token tag |
Interface response message that indicates the token obtained. If the invoked interface is the preceding example, the value of this parameter is access_token. |
|
Response validity period tag |
Interface response message that indicates the token expiration time, in seconds. After the token expires, you need to invoke the interface again to obtain a new token. If the invoked interface is the preceding example, the value of this parameter is expired_time. |
|
Advanced Settings |
Log report account information |
WeChat account information reported in logs. The value can be the OpenID of the WeChat account or the encrypted user mobile number (TID). |
Network access duration granted temporarily |
Before connecting to a cloud-managed device through WeChat authentication, a terminal needs to obtain the Internet access rights temporarily from iMaster NCE-Campus so that the terminal can communicate with the WeChat Official Accounts Platform to complete the authentication. If the value of Network access duration granted temporarily or Number of network access times granted temporarily is exceeded, the system determines whether to lock the terminal based on the value of Enable terminal lock. The recommended value of Network access duration granted temporarily is 5 minutes, and that of Number of network access times granted temporarily is 5. |
|
Number of network access times granted temporarily |
||
Station lock |
If a terminal connected to a cloud-managed device through WeChat authentication triggers the temporary permit mechanism for multiple times within the period specified by Specified time period and the value of Network access duration granted temporarily or Number of network access times granted temporarily is exceeded, iMaster NCE-Campus locks the terminal based on the MAC address temporarily, and the lock duration is specified by Lockout duration. |
|
Specified time period |
||
Lockout duration |
||
Mapped user group |
Used to control the rights of guest accounts. By using this function, you can map all WeChat accounts to a user group so that you can set rights for the accounts in a unified manner. |
|
Supplementary Information
- If an end user fails to pass WeChat authentication, the possible cause is that the WeChat version is outdated. Upgrade the WeChat app and try again.
- If the WeChat app cannot be opened after the user clicks the WeChat authentication button on the web page, the possible cause is that the browser used by the user does not support the WeChat app. Use another browser and try again.
Configuring Guests to Obtain an Authentication URL by Following a WeChat Official Account (Editing Mode)
Context
The authentication method in this section applies when a merchant wants guests to follow a WeChat official account to obtain an authentication URL. After a user follows an official account and replies a message in the official account, the official account returns an authentication URL to the user. The user can click this URL to pass authentication. The user can also click the network access menu in the official account for authentication. A merchant can provide one or more official accounts. If multiple official accounts are available, guests can obtain an authentication URL after they follow any official account.
Authentication Process
WeChat authentication uses the portal authentication process. Before guests can pass portal authentication on iMaster NCE-Campus, they need to follow a WeChat official account to obtain an authentication URL (carrying users' identity information obtained from the WeChat server).
- A guest connects to an SSID.
- A guest follows a WeChat official account.
- The follow event is notified to WeChat Official Accounts Platform, and then WeChat Official Accounts Platform returns an authentication URL containing a URL access key. The authentication URL is configured on WeChat Official Accounts Platform.
- The guest clicks the received URL to initiate portal authentication. (iMaster NCE-Campus pushes an authentication page and initiates an asynchronous authentication request.)
- The iMaster NCE-Campus server extracts the URL access key from the authentication URL and checks whether it is the same as that configured on iMaster NCE-Campus.
- The user terminal polls the authentication result at intervals until receiving an authentication success or query timeout message.
- iMaster NCE-Campus returns the authentication result to the guest.
- The authentication succeeds and the guest can access the network.
Configuration process
To allow guests to obtain an authentication URL by following an official account, you need to apply for one or more WeChat official accounts, configure interconnection parameters on WeChat Official Accounts Platform, and configure portal authentication. The portal authentication configuration includes authentication rules, authorization results, authorization rules, customized pages, portal page push policies, and social media parameters. The following figure shows the configuration process.
Procedure
- Apply for one or more enterprise service or subscription accounts on WeChat Official Accounts Platform and pass Tencent authentication. For detailed operations, see instructions on WeChat Official Accounts Platform.
- Set interconnection parameters on WeChat Official Accounts Platform.
- Log in to WeChat Official Accounts Platform using the applied WeChat official account.
- Choose Function > Auto-Reply.
![]()
- Enter the following content in the Auto-Reply text box:
<a href="http://any IP address or domain name in the post-authentication domain?wxauth=3&wxtoken=[URL access key]">text displayed in the reply </a>
- Any IP address or domain name in the post-authentication domain: The URL is used to trigger portal authentication. The specified IP address or domain name cannot be accessed by unauthenticated guests.
![]()
The IP address in the authentication URL cannot be in the same network segment as the user terminal's IP address. Otherwise, the IP address allocated to the user terminal is reachable before authentication.
- Text displayed in the reply: Text displayed along with the authentication URL sent by WeChat Official Accounts Platform to users. For example: The following figure shows the text AccessNetwork displayed along the authentication URL sent by WeChat Official Accounts Platform.
![]()
- [URL access key]: A string of 16 to 32 letters or digits or a combination of them. You need to set the URL access key manually and keep it secure. Ensure that the value configured on WeChat Official Accounts Platform are the same as that configured on .
- Any IP address or domain name in the post-authentication domain: The URL is used to trigger portal authentication. The specified IP address or domain name cannot be accessed by unauthenticated guests.
- (Optional) Click the Replay on keywords tab to set a rule for replying an authentication URL to a user if the user enters the configured keywords.
![]()
As shown in the preceding figure, click Add reply to add a keyword auto-reply rule. Set different auto-reply content in the Reply content area by clicking different buttons. In this example, the automatic reply content is an authentication URL. The meaning of the authentication URL is the same as that in the previous step.
- (Optional) Click Custom menu on WeChat Official Accounts Platform and add a customized menu to allow guests to click this menu to access the network.
![]()
This function is available only for an official account that has passed WeChat authentication and whose entity is not individual. On the WeChat official accounts platform home page, choose Settings > WeChat Verification to request for WeChat authentication.
Choose Function > Custom menu. You can customize the menus displayed in the WeChat official account. Menu name specifies the name of the customized menu. Set Menu content to Jump to Web page. Set Page address as follows:
http://any IP address or domain name in the post-authentication domain?wxauth=3&wxtoken=[URL access key]
The meanings of any IP address or domain name in the post-authentication domain, [URL access key], and &customized parameters are the same as those in the preceding steps. After the configuration is completed, click Save and publish.
![]()
- Set social media parameters on iMaster NCE-Campus.
- Choose from the main menu. Enable WeChat authentication and set parameters for interconnection with WeChat Official Accounts Platform.
![]()
- Set the authentication method to WeChat link authentication. Click Add and create a WeChat official account. You need to set the official account name and URL access key when creating the WeChat official account. The URL access key is a string of 16 to 32 letters or digits or a combination of them. You need to set the URL access key manually and keep it secure. Ensure that the value configured on WeChat Official Accounts Platform are the same as that configured on iMaster NCE-Campus.
You can create multiple official accounts, so that guests can obtain an authentication URL after they follow any official account. If you have created multiple official accounts, log in to WeChat Official Accounts Platform using each of these accounts and complete relevant settings on the platform.
![]()
- Choose from the main menu. Enable WeChat authentication and set parameters for interconnection with WeChat Official Accounts Platform.
- Customize a portal page on iMaster NCE-Campus.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a customization template. In this section, select WeChat Link Auth Template as the system template.![]()
- In the page editing area, customize authentication pages and authentication success pages for mobile phones and PCs as required. After page customization is completed, click Save and Release.
![]()
- Configure a portal page push policy.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create to create a portal page push policy. Here, you need to set the authentication method to WeChat link authentication, select the portal page customized in the previous step as the page to be pushed, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication method to portal authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point.
Configure portal authentication on an AP, a WAC, or a switch based on the network type.
To trigger authentication, guests need to connect to a WeChat official accounts platform server and follow a WeChat official account to obtain an authentication URL. Therefore, guests must be allowed to access the WeChat official accounts platform server before being authenticated. In this case, they need to obtain the IP address of the WeChat official accounts platform server through the corresponding interface provided by the WeChat Official Accounts Platform. To implement this, you need to add the IP address of the WeChat official accounts platform server to the default permit rule. If IP addresses of some WeChat official accounts platform servers may not be listed in the default permit rule, guests may fail to send and receive WeChat messages after connecting to the Wi-Fi network.
Configure Portal authentication on APs, WACs, or switches based on the network type.
To obtain an authentication URL, guests need to connect to a WeChat official accounts platform server and follow a WeChat official account. Therefore, guests must be allowed to access WeChat official accounts platform servers before authentication. To implement this, you need to obtain the IP addresses of WeChat official accounts platform servers through the corresponding interface provided by the WeChat Official Accounts Platform, and add the IP addresses to the default permit rule. However, there is a possibility that you obtain IP addresses only of some WeChat official accounts platform servers using the preceding method. If this occurs, guests may fail to send and receive WeChat messages after connecting to the Wi-Fi network.
Access from unauthenticated users to the following domain names must be allowed, so that unauthenticated users can communicate with WeChat Official Accounts Platform servers after connecting to the SSID for the first time:
weixin.qq.com, long.weixin.qq.com, short.weixin.qq.com, mp.weixin.qq.com, dns.weixin.qq.com, szshort.weixin.qq.com, szlong.weixin.qq.com, extshort.weixin.qq.com, wx1.qq.com, wx2.qq.com, support.weixin.qq.com, shshort.weixin.qq.com, shlong.weixin.qq.com, and wifi.weixin.qq.com
For details about how to permit access to the preceding domain names, see 9.
For details about how to configure an authentication point, see Configuring an Authentication Point.
to create a customization template. In this section, select WeChat Link Auth Template as the system template.
Configuring Guests to Obtain an Authentication URL by Following a WeChat Official Account (in Developer Mode)
Overview
Comparison Between the Developer Mode and Editing Mode
Based on the configurations on the WeChat Official Accounts Platform, WeChat authentication can be implemented on iMaster NCE-Campus in either of the following modes:
- Editing mode
You need to configure WeChat authentication on the GUI provided by the WeChat Official Accounts Platform. This method is applicable to the enterprises that do not have an independent WeChat official accounts platform server deployed.
- Developer mode
You need to first perform secondary development on the code of the WeChat official accounts platform server. After the code development is complete, you need to choose Development > Basic Configuration and click Enable Server Configuration on the WeChat Official Accounts Platform to complete the configuration. This method is applicable to the enterprises that have an independent WeChat official accounts platform server deployed.
WeChat authentication can be implemented in either editing or developer mode, but not in both simultaneously.
The following table compares the editing mode and developer mode.
Mode |
Whether an Independent WeChat Official Accounts Platform Server Is Required |
Whether to Edit Code |
Security |
|---|---|---|---|
Editing mode |
No |
No |
Low |
Developer mode |
Yes |
Yes |
High. The authentication URL is encrypted using an authentication key. |
You are advised to configure WeChat authentication in developer mode to ensure security.
WeChat Authentication in Developer Mode
If an enterprise deploys an independent WeChat official accounts platform server and has its own developers, WeChat authentication can be implemented in developer mode. In this situation, WeChat authentication involves interactions between the WeChat Official Accounts Platform and the enterprise's WeChat official accounts platform server, and between iMaster NCE-Campus servers and the enterprise's WeChat official accounts platform server.
- Interactions between the WeChat Official Accounts Platform and the enterprise's WeChat official accounts platform server
The Tomcat service needs to be enabled on the server, regardless of whether a third-party web server or an enterprise's real server is used to set up the enterprise's WeChat official accounts platform server. Associated with the PHP application, the Tomcat service functions as the enterprise's web service platform to provide web services for external users after being bound to the WeChat Official Accounts Platform. The WeChat Official Accounts Platform interworks with the enterprise's WeChat official accounts platform server through the URL of the web service and the URL access key configured on both parties. Users can follow WeChat official accounts to access web services. iMaster NCE-Campus does not participate in the process of building a WeChat official accounts platform server.
Figure 5-23 Interactions between the WeChat Official Accounts Platform and the enterprise's WeChat official accounts platform server![]()
- Interactions between iMaster NCE-Campus and the enterprise's WeChat official accounts platform server
Figure 5-24 shows the authentication process in developer mode when a user follows a WeChat official account to obtain an authentication URL. In the entire process, iMaster NCE-Campus does not need to communicate with either the WeChat Official Accounts Platform or enterprise's WeChat official accounts platform server. To implement WeChat authentication, you need to change the URL access key and authentication key in the PHP code of the enterprise's WeChat official accounts platform server to be the same as those configured on iMaster NCE-Campus. In step h, the URL returned by the enterprise's WeChat official accounts platform server carries the URL access key and authentication key. When the user clicks the URL for authentication, iMaster NCE-Campus verifies the validity of the URL based on the URL access key and authentication key configured on itself. If the URL is the same as that configured in the system, the user passes the authentication.
Figure 5-24 Process of obtaining an authentication URL by following a WeChat official account (in developer mode)![]()
- A user connects to an SSID using a terminal.
- The user accesses a specific Internet resource.
- The authentication device detects that the user is not authenticated and redirects the user to the portal authentication page.
- The user terminal automatically accesses the URL (http://IP address of the portal server:19008/carried parameter) that is redirected by the WAC.
- The portal server detects that the user is authenticated for the first time and pushes the WeChat authentication page customized by the administrator on iMaster NCE-Campus to the user.
- The user follows a WeChat official account as prompted.
- The WeChat Official Accounts Platform sends the follow event to the enterprise's WeChat official accounts platform server.
- The enterprise's WeChat official accounts platform server obtains the unique identifier (openid) of the user's WeChat account and generates an authentication URL that contains the openid and parameters for interconnection with iMaster NCE-Campus.
- The enterprise's WeChat official accounts platform server sends the authentication URL to the WeChat Official Accounts Platform.
- The WeChat Official Accounts Platform sends the authentication URL to the WeChat client on the user terminal.
- The user clicks the received URL to initiate portal authentication.
- The WAC detects that the user is not authenticated and redirects the user to the portal authentication page again. In this case, the redirection URL contains the openid generated by the enterprise's WeChat official accounts platform server and parameters for interconnection with iMaster NCE-Campus.
- The terminal automatically accesses the redirection URL.
- iMaster NCE-Campus obtains the parameters contained in the authentication URL, verifies them, and completes portal authentication and RADIUS authentication with the WAC.
- iMaster NCE-Campus returns the authentication result to the user.
- The user is successfully authenticated and can access the network.
Configuration Process
Figure 5-25 shows the process for configuring interconnection between the WeChat Official Accounts Platform, enterprise's WeChat official accounts server, and iMaster NCE-Campus in developer mode.
Setting Up a WeChat Official Accounts Platform Server Using the PHP Application
Context
A WeChat official accounts platform server runs the WeChat official account code to respond to web requests sent by the WeChat server.
Currently, iMaster NCE-Campus can interwork with a WeChat official accounts platform server set up based on PHP.
The following describes how to set up a WeChat official accounts platform server using a Windows 2008 server.
Prerequisites
- Apache HTTP Server has been downloaded.
Download Apache HTTP Server at https://www.apachelounge.com/download/vc15/.
- PHP has been downloaded.
Download PHP at https://windows.php.net/downloads/releases/archives/.
![]()
The Apache HTTP Server version must match the PHP version. Otherwise, they cannot be connected. Apache HTTP Server 2.4.43 and PHP 7.4.5 are recommended.
Apache HTTP Server 2.4.43 and php-7.4.5-Win32-vc15-x64.zip are used as examples.
- Web service files have been prepared by enterprises, such as home pages and images.
The following table lists the file paths involved in this example.
Project
Path Description
Apache HTTP Server
Decompress all files to C:\Program Files (x86)\Apache without installation.
PHP application
Decompress all files to C:\Program Files (x86)\php7.
Home directory folder of enterprise web services (storing web service images, home pages, and secondary development code files for interconnection with iMaster NCE-Campus)
The files are saved in C:\Program Files (x86)\Apache\httpd-2.4.43-win64-VC15\Apache24\htdocs.
Procedure
- Decompress the Apache HTTP Server installation package to a directory, for example, C:\Program Files (x86)\Apache\.
- Install PHP.
Decompress the PHP package to a directory on the server, for example, C:\Program Files (x86)\, and then rename the directory php.
This step is performed to enable the Windows operating system to obtain the DLL files for running PHP, which is similar to specifying system environment variables.
- Configure PHP.
- Rename the php.ini-development file in the PHP folder as php.ini, and open the file using Notepad.
The php.ini file records PHP configuration information. If you configure all parameters following instructions provided in this example, you can directly replace the php.ini file in the PHP folder with that contained in the attachment. In this case, you do not need to perform step b.
- Delete the configuration comments in the php.ini file as follows:
Specify the directory of the PHP extension package to call appropriate DLL files. Delete comments to support the function invoking of the corresponding module.
- Search for extension_dir = "ext", delete the semicolon (;) before it, and change the path based on the site requirements.
![]()
- Search for extension=openssl and delete the semicolon (;) before it.
![]()
- Search for extension=sodium and delete the semicolon (;) before it.
![]()
- Search for extension=curl, extension=gd2, and extension=mbstring, and delete the semicolon (;) before them.
![]()
- Search for extension_dir = "ext", delete the semicolon (;) before it, and change the path based on the site requirements.
- Save the file.
- Rename the php.ini-development file in the PHP folder as php.ini, and open the file using Notepad.
- Configure Apache.
- Open the httpd.conf file in C:\Program Files (x86)\Apache\httpd-2.4.43-win64-VC15\Apache24\conf using Notepad.
- Search for LoadModule php7_module and modify the code as follows. If the following code does not exist in the file, add the code to this file.
In this step, you need to associate the Apache service with the PHP application, enable PHP application parsing, and specify the path where the required PHP files are stored.
LoadModule php7_module "C:/Program Files (x86)/php7/php7apache2_4.dll" // Replace C:/Program Files (x86) with the path where the required PHP files are stored. PHPIniDir "C:/Program Files (x86)/php7" // Replace C:/Program Files (x86) with the path where the required PHP files are stored. AddType application/x-httpd-php .php DirectoryIndex index.php index.html
![]()
![]()
- Save the web service files, such as the home page and images, to the C:\Program Files (x86)\Apache\httpd-2.4.43-win64-VC15\Apache24\htdocs directory.
- Search for IfModule dir_module and change the directory index to index.php index.html.
![]()
- Save the file.
- On the Apache download page, download mod fcgid-2.3.9-win64-VC15.zip.
- Double-click the Apache icon to start the Apache service.
- Map the IP address of the enterprise's WeChat official accounts platform server to a public IP address for communication with the WeChat Official Accounts Platform.
In this example, the enterprise's WeChat official accounts platform server is deployed on the enterprise's internal network. If the server is deployed on a public network, ensure that it can communicate with both iMaster NCE-Campus and the WeChat Official Accounts Platform. In this case, the IP address of iMaster NCE-Campus must be mapped to a public IP address on the NAT device at the enterprise egress.
- Configure the NAT device at the enterprise egress.
- Access http://mapped public IP address/enterprise web application.php. If the access is successful, the configuration is successful.
In this example, the test application test02.php in the C:\Program Files (x86)\Apache\httpd-2.4.43-win64-VC15\Apache24\htdocs directory is used. You can use a test application as needed.
![]()
Binding a WeChat Official Account to the Enterprise WeChat Official Accounts Platform Server
Context
WeChat official accounts need to send WeChat messages of guests to the enterprise's WeChat official accounts platform server. Therefore, interconnection between the two parties is required.
Procedure
- Configure and apply for an enterprise service account or subscription account on the WeChat Official Accounts Platform and pass Tencent authentication. For details, see instructions provided by the WeChat Official Accounts Platform.
- On the home page of the WeChat Official Accounts Platform, choose Development > Basic Configuration, select I agree to the WeChat Public Platform Developer Service Agreement, and click Be a developer.
- Click Change Configuration on the right of Server Configuration.
![]()
- Enter the server URL, token, and message encryption and decryption key, and click Submit.
- The server URL is the URL of the enterprise's WeChat official accounts platform server.
This URL must be in the format of http://public IP address of the server/enterprise web application.php. In this example, the enterprise web application is index.php.
- The token must be the same as that in the code package uploaded during the setup of the enterprise's WeChat official accounts platform server, as shown in the following figure. In this example, enter weixin as the token.
![]()
- Click Random Generation on the right of EncodingAESKey to generate a message encryption and decryption key.
![]()
- The server URL is the URL of the enterprise's WeChat official accounts platform server.
- Click Submit.
If the system displays a message indicating that the token verification fails, choose Development > Developer tools > Developer Document to go to the developer document page. Choose Getting Started with Development > Access Guide, download the sample code provided in step 2 again, rename the code file as index.php, and store this file in the PHP application on the enterprise's WeChat official accounts platform server.
If an enterprise does not set up its own server using the PHP application, replace the files in the enterprise's own web application. In this example, the file path is C:\Program Files (x86)\Apache\httpd-2.4.43-win64-VC15\Apache24\htdocs.
![]()
![]()
- After the verification is complete, click Enable.
After the server is configured and enabled, messages sent by users to WeChat official accounts and events required by developers will be forwarded to the enterprise's WeChat official accounts platform server.
![]()
Setting Parameters for Connecting the Enterprise WeChat Official Accounts Platform Server to iMaster NCE-Campus
You need to perform secondary development on the PHP code of the enterprise web application to add the configuration for connecting to iMaster NCE-Campus so that the enterprise's WeChat official accounts platform server can connect to iMaster NCE-Campus.
Context
If an enterprise has set up a WeChat official accounts platform server and has been bound to a WeChat official account, you only need to modify the PHP code of the WeChat official accounts platform server.
The purpose of modifying the PHP code is to add the configuration for connecting the WeChat official accounts platform server to iMaster NCE-Campus.
Procedure
In this example, you can directly modify the code in the index.php, aes.php, and weixin.php files decompressed from WeChatApp.zip.
The code in index.php is used by the WeChat Official Accounts Platform to obtain the authentication URL. The code in weixin.php is used to configure the method of generating WeChat authentication information. The code in aes.php is used to configure the method of encrypting WeChat authentication information. The code package is for reference only. The following information needs to be modified in the code files:
- If the image with an authentication URL needs to be customized, you need to modify the image link in the index.php code.
![]()
The image URL must be permitted on the authentication device based on a portal authentication-free rule and added to the pre-authentication domain. Otherwise, terminals cannot access the image.
To facilitate management, you can place the image in the web service directory of the enterprise's WeChat official accounts platform server. In this example, the image is placed in the C:\Program Files (x86)\Apache\httpd-2.4.43-win64-VC15\Apache24\htdocs directory of the enterprise's WeChat official accounts platform server.
![]()
- Change the IP address in the authentication URL to any IP address in a non-pre-authentication domain, that is, an IP address that end users cannot access before authentication.
This authentication URL is used to trigger portal authentication on terminals. Therefore, the IP address in the authentication URL must be an unreachable IP address to unauthenticated terminals.
![]()
The IP address in the authentication URL cannot be on the same network segment as IP addresses of end users. Otherwise, the IP address in the authentication URL may become reachable to end users after they obtain IP addresses.
![]()
- Modify the parameters for interconnection with iMaster NCE-Campus.
The interconnection between the enterprise's WeChat official accounts platform server and iMaster NCE-Campus requires two parameters, which are URL access key and Authentication key on the iMaster NCE-Campus web UI. The two parameters map the following two fields in corresponding PHP files. The parameter values set on iMaster NCE-Campus must be the same as those in the PHP files.
- URL access key on the iMaster NCE-Campus web UI corresponds to token in the index.php code. The value must be the same as the URL access key configured on the iMaster NCE-Campus web UI.
![]()
- Authentication key on the iMaster NCE-Campus web UI corresponds to _secret_key in aes.php. You can change the value to a string of no more than 32 characters. The authentication key is used to encrypt the authentication URL.
![]()
To set the token and authentication key on iMaster NCE-Campus, perform the following steps:
- Log in to iMaster NCE-Campus.
- Choose .
- Set the social media type to WeChat and set the token value in the interconnection parameter configuration area.
A token is a string of 16 to 32 characters that can contain letters, digits, or both. You need to manually set the token value and ensure that the token value on the WeChat Official Accounts Platform is the same as that configured on iMaster NCE-Campus.
![]()
- URL access key on the iMaster NCE-Campus web UI corresponds to token in the index.php code. The value must be the same as the URL access key configured on the iMaster NCE-Campus web UI.
- Modify the parameters for interconnecting with iMaster NCE-Campus through an API. You need to obtain the northbound IP address of Master NCE-Campus, username and password of a third-party system user, and the user group ID.
- Log in to iMaster NCE-Campus.
- Choose and create a third-party system user. If such a user has been created, obtain the username and password.
![]()
- In the weixin.php file, change the username and password to those configured on iMaster NCE-Campus and set the northbound IP address of iMaster NCE-Campus. You also need to obtain the ID of the corresponding user group.
![]()
![]()
![]()
![]()
Configuring iMaster NCE-Campus
- Set social media parameters on iMaster NCE-Campus.
- Choose from the main menu. Enable and configure WeChat authentication.
![]()
- Set Authentication mode to WeChat URL-based authentication. Click Add to add a WeChat official account. When adding a WeChat official account, you need to set the official account name and URL interconnection key. The URL interconnection key is a string of 16 to 32 characters containing letters, digits, or both. You need to manually set the URL interconnection key. Ensure that the key set on iMaster NCE-Campus is the same as that set on the WeChat Official Accounts Platform.
You can add multiple WeChat official accounts so that users can obtain the authentication link no matter which official account they follow. To use multiple official accounts, you need to log in to the WeChat Official Accounts Platform using each WeChat official account and complete the configuration.
![]()
- Choose from the main menu. Enable and configure WeChat authentication.
- Customize the WeChat authentication page pushed to end users on iMaster NCE-Campus.
- Choose from the main menu.
- On the Page Customization tab page, click
![]()
to create a custom portal page template, and set System template to WeChat Link Auth Template.![]()
- Customize a portal authentication page and an authentication success page for mobile phones and PCs. After the pages are customized, click Save and then Release.
![]()
- Configure a portal page push policy.
- Choose from the main menu.
- On the Portal Page Push Policy tab, click Create to create a portal page push policy. Here, you need to set the authentication method to WeChat link authentication, select the portal page customized in the previous step as the page to be pushed, and select the authentication page as the first page to be pushed. For details about how to set other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication method to portal authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication method to User Access Authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure an authentication point.
Configure portal authentication on an AP, a WAC, or a switch based on the network type.
To trigger authentication, guests need to connect to a WeChat official accounts platform server and follow a WeChat official account to obtain an authentication URL. Therefore, guests must be allowed to access the WeChat official accounts platform server before being authenticated. In this case, they need to obtain the IP address of the WeChat official accounts platform server through the corresponding interface provided by the WeChat Official Accounts Platform. To implement this, you need to add the IP address of the WeChat official accounts platform server to the default permit rule. If IP addresses of some WeChat official accounts platform servers may not be listed in the default permit rule, guests may fail to send and receive WeChat messages after connecting to the Wi-Fi network.
Configure Portal authentication on APs, WACs, or switches based on the network type.
To obtain an authentication URL, guests need to connect to a WeChat official accounts platform server and follow a WeChat official account. Therefore, guests must be allowed to access WeChat official accounts platform servers before authentication. To implement this, you need to obtain the IP addresses of WeChat official accounts platform servers through the corresponding interface provided by the WeChat Official Accounts Platform, and add the IP addresses to the default permit rule. However, there is a possibility that you obtain IP addresses only of some WeChat official accounts platform servers using the preceding method. If this occurs, guests may fail to send and receive WeChat messages after connecting to the Wi-Fi network.
Access from unauthenticated users to the following domain names must be allowed, so that unauthenticated users can communicate with WeChat Official Accounts Platform servers after connecting to the SSID for the first time:
weixin.qq.com, long.weixin.qq.com, short.weixin.qq.com, mp.weixin.qq.com, dns.weixin.qq.com, szshort.weixin.qq.com, szlong.weixin.qq.com, extshort.weixin.qq.com, wx1.qq.com, wx2.qq.com, support.weixin.qq.com, shshort.weixin.qq.com, shlong.weixin.qq.com, and wifi.weixin.qq.com
For details about how to permit access to the preceding domain names, see 9.
For details about how to configure an authentication point, see Configuring an Authentication Point.
to create a custom portal page template, and set System template to WeChat Link Auth Template.
Appendix - Secondary Development of the WeChat Official Accounts Platform
WeChat Authentication Information Management
Method Definition
public static function getParaStr($openId,$token);
Parameter Description
Parameter |
Type |
Mandatory (Y/N) |
Description |
|---|---|---|---|
$openId |
String |
Yes |
Unique identifier of a WeChat account. |
$token |
String |
Yes |
Token used for interconnection with iMaster NCE-Campus. The value must be the same as Token configured on the page of iMaster NCE-Campus. |
Parameter |
Type |
Description |
|---|---|---|
result |
String |
Complete authentication information required for WeChat authentication. |
Configuring an Encryption Key
Method Definition
public static function setKey($key);
Parameter Description
Parameter |
Type |
Mandatory (Y/N) |
Description |
|---|---|---|---|
$key |
String |
Yes |
Shared key. The value must be the same as the authentication key configured on the page of iMaster NCE-Campus. The value is a string of 32 characters. |
Parameter |
Type |
Description |
|---|---|---|
resultCode |
Boolean |
false: Operation failed. true: Operation is successful. |
Encrypting Authentication Information
Method Definition
public static function encrypt($plaintext);
Parameter Description
Parameter |
Type |
Mandatory (Y/N) |
Description |
|---|---|---|---|
$plaintext |
String |
Yes |
WeChat authentication information to be encrypted, which is obtained using the public static function getParaStr($openId,$token) method. |
Parameter |
Type |
Description |
|---|---|---|
result |
String |
Encrypted authentication information. |
Sample Code
The parameter name in the authentication URL must be info.
// Example of setting an encryption key $key="Bond.James Bond. Bond.James Bond.";
aes::setKey($key);
// Example of generating a URL // The token must be the same as that configured on iMaster NCE-Campus. $token="controllertoken";
// Invoke the getParaStr method to generate WeChat authentication information in plaintext. $plaintext =weixin::getParaStr($OpenId,$token);
// Encrypt the WeChat authentication information. $encrptText =aes::encrypt($plaintext); // Combine the URL and encrypted parameter to form a WeChat authentication URL. $url = "http://192.168.1.1? info=".$encrptText;
Configuring Guest Access Through QR Code Scanning Using the WeChat APP via Wi-Fi
Context
The authentication method in this section applies when a merchant wants to allow guests to follow the merchant's WeChat official account and associate with an SSID for network access after scanning the QR code posted in the merchant's store.
The merchant's WeChat official account is shared by multiple stores, each of which provides an independent SSID. Guests can scan the QR code posted in any store of the merchant to connect to Wi-Fi and get authenticated.
After users use their WeChat to scan the QR code posted in a store, the Wi-Fi screen is displayed on their terminal. They can tap the Connect button to associate with the SSID and access the network.
QR code scanning using the WeChat APP via Wi-Fi is currently unavailable because the WeChat configuration background and corresponding APIs are disabled by WeChat.
Authentication Process
- An end user opens a WeChat app and scans the QR code posted in a store.
- WeChat Official Accounts Platform verifies the App ID and App Secret registered by the end user for Wi-Fi connection. If the verification is successful, the Wi-Fi screen is displayed on the user terminal.
- The user taps Access network to connect to Wi-Fi. If the user uses an iOS terminal, the user needs to copy the password and manually select an SSID.
- The authentication device performs PSK authentication.
- After successful PSK authentication, the authentication device initiates a MAC address authentication request to iMaster NCE-Campus by using the terminal MAC address as the account.
- iMaster NCE-Campus verifies whether the SSID is in PSK+MAC authentication mode. If so, the authentication is successful.
- iMaster NCE-Campus returns an authentication result to the authentication device.
- The authentication device grants the network access permission to the end user.
- The authentication is successful. The end user can access the network.
Procedure
- Apply for one or more enterprise service or subscription accounts on WeChat Official Accounts Platform and pass Tencent authentication. For detailed operations, see instructions on WeChat Official Accounts Platform.
- Log in to WeChat Official Accounts Platform using the applied WeChat official account.
- Choose Function > Add Plug-ins and add the Wi-Fi and Store MiniProgram plug-ins separately.
![]()
- Choose Function > Store MiniProgram and click Add to add store information.
![]()
- Choose Function > Wi-Fi, click the Device Management tab, and then click Add device to add a password-authenticated device.
The password-authenticated device refers to the AP that provides the SSID for Wi-Fi connection. The end user associates with this SSID to connect to the network through Wi-Fi.
Select the store to which the device belongs.
Set Device Type to Password-authenticated device.
Set Network name (SSID) to the SSID that provides the Wi-Fi connection function. This SSID must be the same as that configured on the AP.
Set Password to the password required for associating with the SSID. It must be the same as the password configured on the AP.
- Click Add.
![]()
- Confirm that the network name and password are the same as those configured on the AP. Then, click Next.
![]()
- Scan the QR code, set a WeChat account as the administrator account, and click Next.
You can log in to WeChat using any WeChat account. After login, scan the QR code and set the current account as the administrator account. Then, the WeChat account can be used to manage the Wi-Fi function of the store. After a WeChat account is set as an administrator account, Wi-Fi Assistant is automatically displayed on the user's mobile phone. The end user can use Wi-Fi Assistant to customize the merchant homepage, set Wi-Fi parameters, and re-download a QR code to be posted in the store.
The device quantity is displayed as 0 immediately after a device is added. The added device will automatically register after a user goes online from this device.
- Download and save the QR code to be posted in the store. If you do not download the QR code in this step or the downloaded QR code is lost, use Wi-Fi Assistant to re-download one. Click Done after downloading the QR code.
![]()
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication mode to MAC address authentication and select the wireless access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. Set the authentication mode to MAC address authentication and select the wireless access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- Configure a RADIUS server template.
- Choose from the main menu. On the page that is displayed, choose RADIUS Server from the navigation pane.
- Click Create. In the dialog box that is displayed, set parameters and click OK.
- On iMaster NCE-Campus, set the authentication mode to PSK (WeChat QR code scanning).
- Choose from the main menu.
- In the displayed window, select a site from the Site drop-down list in the upper left corner.
- Choose the Site Configuration tab.
- Select a configuration process based on the type of device used as the authentication point.
![]()
If the V300R019C10SPC207 patch is not installed, set the authentication mode to PSK+MAC address authentication. If the V300R019C10SPC207 patch is installed, set the authentication mode to PSK (WeChat QR code scanning).
Authentication Point
Configuration Process
AP
- Choose from the navigation pane, click Create, and set basic SSID information.
- On the Security Authentication page, set Authentication mode to Semi-open network and PSK (WeChat QR code scanning). Set Key type to PSK and set Encryption mode, Encryption algorithm, and the SSID access password.
The options of Encryption algorithm are as follows:
- AES: Encrypt data using the Advanced Encryption Standard (AES) algorithm.
- AES-TKIP: Encrypt data using the AES or TKIP algorithm. After successful authentication, the user terminal encrypts data using the supported algorithm AES or TKIP.
- TKIP: Encrypt data using the Temporal Key Integrity Protocol (TKIP) algorithm.
- Configure the RADIUS server.
Switch
- Choose from the navigation pane. Click the Wireless Authentication tab. Click Create to create the authentication information.
- Set Authentication mode to Semi-open network and PSK (WeChat QR code scanning) and select a RADIUS server template.
- Configure the RADIUS server.
WAC
- Choose from the navigation pane. Click Create to create the authentication information.
- Set Authentication mode to Semi-open network and PSK (WeChat QR code scanning) and select a RADIUS server template.
- Configure the RADIUS server.NOTE:
WAC configuration needs to be performed in the web system. For details, see Configuration > Web-based Configuration in the Wireless Access Controller (AC and Fit AP) Product Document.
Firewall and AR
None
Account Blacklist Management
Context
An account blacklist is a list of accounts that are locked automatically or manually. End users will fail in the authentication if they use locked accounts. The administrator can manually lock accounts or configure an automatic account lock policy to lock accounts upon authentication failure.
If the administrator manually locks an account that has been locked automatically, the account will be moved from the blacklist of automatically locked accounts to the blacklist of manually locked accounts.
After an account is added to an account blacklist, it will fail in all authentication methods, and the corresponding user cannot log in to the self-help service page.
The blacklist of automatically locked accounts and the blacklist of manually locked accounts can contain 200,000 accounts in all. If the threshold is reached, accounts cannot be added to the blacklists in either way.
Configuring a Policy to Automatically Lock Accounts
- Choose from the main menu. On the User Password Policy Configuration tab, toggle User lockout on.
After this function is enabled, if an end user fails to log in to a cloud device with an account for the number of times specified by Login failure count in specified times within the period specified by Specified time period (min), the account will be locked for a period specified by Lockout duration (min). The locked account will be added to an account blacklist automatically.
![]()
- Choose from the main menu and click the Auto-Locked Accounts tab to view locked accounts in the blacklist.
- The administrator can set filtering conditions such as the username, user group, user type, IP address, or MAC address to view only specific accounts in the blacklist.
- The administrator can manually delete an account from a blacklist to unlock the account. End users can use accounts after they are unlocked automatically when the lockout duration is reached.
After the administrator toggles Enable bound account IP/MAC address on, accounts will fail in the authentication on terminals whose IP addresses or MAC addresses are bound to the accounts. These accounts can pass authentication from other terminals. After the administrator toggles Enable bound account IP/MAC address off, accounts will be locked on all terminals and fail in the authentication so long as the number of incorrect attempts reaches the threshold.
Manually Locking Accounts
The administrator manually adds accounts to the blacklist of manually locked accounts. Manually locked accounts will fail the authentication on all terminals. Accounts will be unlocked after the administrator deletes them from the blacklist.
- Choose from the main menu.
- Click the Manually-Locked Accounts tab and Add, and then select accounts to be added to the blacklist.
- Click OK.
CA Management
Overview
Context
As an open standard of IETF, Extensible Authentication Protocol Transport Layer Security (EAP-TLS) is the original version of WLAN extended authentication protocol. It is considered as one of the most secure EAP standards although its configuration is complex. EAP-TLS requires client certificates which can be stored in a smart card. If the smart card is not stolen, client certificates cannot be obtained. Therefore, EAP-TLS provides a more secure authentication scheme than other authentication modes.
iMaster NCE-Campus can connect to an external CA server or uses its built-in CA server to provide EAP-TLS-based 802.1X authentication for users. In addition, whether client certificates are valid can be verified based on the CRLs of an external CA server and the built-in CA server.
Certificate-based Authentication Process
Certificate-based authentication applies to two scenarios: terminal authentication and client authentication. The following figures show the terminal authentication process and client certificate application process, respectively.
Third-Party CA Management
Deploying a Third-party CA Server
A CA server needs to be deployed in advance if 802.1X authentication is required.
The Windows CA server must be deployed as an enterprise CA. Follow the video to deploy a CA server.
You are advised to check CA server configurations according to the following flowchart.
- Open a browser and enter https://Server-IP/certsrv. Server-IP indicates the IP address of the CA server.
If the following page is displayed after login using the AD domain account administrator and its password, the CA server is functioning properly. Otherwise, delete and then add the CA server again.
![]()
- In the Certification Authority area, right-click the root certificate. In the displayed dialog box, click the Extensions tab and check extended fields CDP and AIA.
- CDP: Include in the CDP extension of issued certificates must be selected for LDAP and HTTP.
![]()
- AIA: The two options in the red box must be selected for the OCSP URL.
![]()
- Open a browser and enter https://Server-IP/certsrv/mscep_admin, where Server-IP indicates the IP address of the CA server.
If the following page is displayed after login using the AD domain account administrator and its password, the SCEP and HTTPS settings are correct.
![]()
If the page is displayed in HTTP mode but cannot be displayed in HTTPS mode, check whether HTTPS is bound to the CA server, and whether the correct root certificate is selected. Select the certificate the same as the full computer name for SSL certificate.
![]()
If the page cannot be displayed in HTTP mode, check whether Network Device Enrollment Service is Installed.
![]()
- The SCEP template must contain the Client Authentication field. Otherwise, end users may fail the authentication. If the SCEP template does not contain the Client Authentication field, correct the settings based on the video instruction.
![]()
- In the registry, set the SCEP template name and disable EnforcePassword.
Find entries in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP, and set their values to the SCEP template name.
Registry modification takes effect only after the operating system is restarted.
![]()
Set EnforcePassword to 0.
![]()
- Check the permission settings in the SCEP and OCSP templates. If the settings are incorrect, correct them based on the video instruction.
![]()
![]()
- Check whether the SCEP and OCSP templates are issued. If SCEP and OCSP templates are not in the certificate template list, issue the templates based on the video instruction.
![]()
- Choose Start > Administrative Tools > Online Responder Management to check whether OCSP is in working state. If not, delete ocsp_test and create it again based on the video instruction.
![]()
- The properties of the revocation configuration and the random number and signature of iMaster NCE-Campus must have the relationship shown in the following figure:
![]()
Configuring a CA Certificate Policy
Context
After an external CA server is configured, you need to import the CA root certificate to iMaster NCE-Campus. In addition, you need to configure a certificate policy and bind the certificate policy to the external CA server.
To manage clients who use certificates to access iMaster NCE-Campus, you need to define mappings between client certificates and iMaster NCE-Campus user accounts when configuring certificate-based authentication. That is, you need to create user accounts and define mappings between the accounts and client certificates on iMaster NCE-Campus. In this case, administrators can manage the clients who use certificates to access iMaster NCE-Campus by managing the accounts associated with the certificates.
Procedure
- Upload a CA certificate.
- Contact the administrator to obtain the certificate file.
- Choose from the main menu.
- Choose Service Certificate Management from the navigation pane. On the Services page, click CA-Manager.
- Click the Trust Certificate tab and click Import. On the displayed page, enter the certificate information, select the desired CA certificate, and click Submit to upload the certificate to iMaster NCE-Campus.
![]()
- Choose from the main menu. The default CA management mode is third-party CA. If the CA management mode is not third-party CA, click
![]()
to switch to this mode.![]()
- Click the Policy Configuration tab and click Add to associate a specific certificate policy with users based on mapping rules.
![]()
- After the policy is added, click
![]()
next to the policy to configure mapping rules between certificates and users, between certificates and user groups, or between users and user roles.![]()
to switch to this mode.
next to the policy to configure mapping rules between certificates and users, between certificates and user groups, or between users and user roles.
Parameter Description
Parameter |
Description |
||
|---|---|---|---|
User mapping rule |
Theme |
Theme |
Subject based on which user name information is obtained from a user certificate. The options are as follows:
|
Verify the user |
Check whether theuser name in the user certificate is the same as that configured on the local device or CA server. If the information is consistent, the user is authenticated. If the information is inconsistent, the user fails to be authenticated. If the user does not exist, the system only checks whether the user certificate is valid. If the user certificate is valid, the user passes the authentication. In this case, the user is authorized based on the specified user group. |
||
Default user group |
Default user group specified when Verify the user is disabled. If a certificate user whose information is obtained based on the theme does not exist, the user is authorized based on the rules applied to the default user group. |
||
Advanced |
Mapping rule |
Advanced mapping rule based on which user name information is obtained from a user certificate. Rule based on which user name information is obtained from a user certificate. The rule format is Subject field variable+Specified character string. Multiple subject field variables and character strings can be contained. For example, if the mapping rule is CN + "@huawei.com" and CN=JSON, the parsed user name is JSON@huawei.com. If the mapping rule is CN + "at" + O + "@huawei.com", and CN=TER and O=BOB, the parsed user name is TERatBOB@huawei.com. If multiple duplicate fields exist in a user certificate, iMaster NCE-Campus obtains the value of the first field when parsing a username. |
|
Verify the user |
Check whether the username in the user certificate is the same as that configured on the local device or CA server. If the information is consistent, the user is authenticated. If the information is inconsistent, the user fails to be authenticated. If the user does not exist, the system only checks whether the user certificate is valid. If the user certificate is valid, the user passes the authentication. In this case, the user is authorized based on the specified user group. |
||
Default user group |
Default user group specified when Verify the user is disabled. If a certificate user whose information is obtained based on the advanced mapping rule does not exist, the user is authorized based on the rules applied to the default user group. |
||
Role Mapping Rule |
Matching rule |
Mode in which a certificate user maps one or more roles when the user matches multiple rules.
|
|
Rule name |
Name of a role mapping rule. |
||
Role |
Role that is mapped when a certificate user matches the rule. |
||
Rule matching mode |
Mode in which a certificate user matches a rule when multiple filter conditions are created. Or: If any of the filter conditions is met, the rule is matched. And: If all filter conditions are met, the rule is matched. |
||
Filter condition |
Filter condition for a certificate user. Currently, certificate users can only be filtered by certificate template. The conditions that can be set are as follows: Attribute: certificate template Operation: is, is not, begins with, ends with, not begins with, not ends with Value: value included or excluded in the user-defined certificate template name The value can contain only letters, digits, and underscores (_). |
||
(Optional) Configuring CRL Synchronization
Context
The certificates used for user authentication are valid for a certain period of time. The revoked certificates are recorded in the CRL. Users using revoked certificates will fail to be authenticated.
When an end user uses an EAP-TLS certificate for authentication, iMaster NCE-Campus checks whether the certificate used by the user for authentication is valid using OCSP. In addition, the CRL of an external CA server can be uploaded to iMaster NCE-Campus, or be periodically synchronized with that on iMaster NCE-Campus. In this manner, iMaster NCE-Campus can check whether certificates used by terminals are valid.
Prerequisites
iMaster NCE-Campus has been connected to an external authentication source, for example, a CA server, for CRL synchronization.
Procedure
- Choose from the main menu. The default CA management mode is third-party CA. If the CA management mode is not third-party CA, click
![]()
to switch to this mode.![]()
- Click the Certificate Verification > CRL Synchronization tab and click Create to create a CRL synchronization task.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Authentication source |
Name of an external authentication source, that is, the CA server that generates a certificate revocation list (CRL). |
Enable periodic synchronization |
Interval for automatically synchronizing the CRL from an external authentication source. |
(Optional) Uploading a CRL File
Context
The certificates used for user authentication are valid for a certain period of time. The revoked certificates are recorded in the CRL. Users using revoked certificates will fail to be authenticated.
- When an end user uses an EAP-TLS certificate for authentication, iMaster NCE-Campus checks whether the certificate used by the user for authentication is valid using OCSP. In addition, the CRL of an external CA server can be uploaded to iMaster NCE-Campus, or be periodically synchronized with that on iMaster NCE-Campus. In this manner, iMaster NCE-Campus can check whether certificates used by terminals are valid based on the CRL.
- If the CRL on an external CA server seldom changes, you are advised to manually upload the CRL file to iMaster NCE-Campus. If the CRL file on an external CA server changes frequently, you are advised to enable CRL synchronization between iMaster NCE-Campus and the external CA server. Before using this function, enable AD/LDAP synchronization to configure an external CA server from which the CRL is synchronized to iMaster NCE-Campus.
Procedure
- Choose from the main menu.
- Click the Certificate Verification > CRL Management tab and click Upload to update a CRL file.
![]()
Configuring an OCSP Server
Context
iMaster NCE-Campus can check revoked certificates from an Online Certificate Status Protocol (OCSP) server. Revoked certificates cannot be used for authentication. Therefore, you are advised to configure an OCSP server. Otherwise, configure CRL synchronization or manually upload a CRL to iMaster NCE-Campus to verify whether certificates are revoked.
Procedure
- Choose from the main menu.
- Click the Certificate Verification > OCSP Server Configuration tab, enable OCSP, and configure an OCSP server.
![]()
If Verify random number and Verify response signature are enabled when you configure an OCSP server, Random number verification and Signature verification need to be enabled for the CA server, as shown in the following figure.
![]()
Parameter Description
Parameter |
Description |
|---|---|
OCSP server URL |
URL of an OCSP server. You can configure active and standby OCSP servers. |
Random number verification |
Whether to verify that the random number sent from iMaster NCE-Campus to the CA server is the same as that returned from the CA server to iMaster NCE-Campus. This function can prevent replay attacks. This function needs to be enabled on the OCSP server and CA server together. |
Verification response signature |
After this function is enabled, the CA server responds to OCSP requests from iMaster NCE-Campus using certificate signatures and iMaster NCE-Campus verifies signatures in the responses to prevent forgery. This function needs to be enabled on the OCSP server and CA server together. |
Cache storage duration (min) |
Duration during which certificate revocation results are cached on iMaster NCE-Campus. The value is in the range from 0 to 1440. The value 0 indicates that the query results are not cached. The default value is 0. After this parameter is configured, iMaster NCE-Campus queries cached results during the specified cache duration, without the need to query revoked certificates from the OCSP server. |
Bypass |
Whether to enable bypass authentication. After this function is enabled, when the OCSP server fails, iMaster NCE-Campus authenticates user without verifying user certificates. |
Configuring an SCEP Server
Context
If end users access the Internet through certificate authentication, you need to configure a Simple Certificate Enrollment Protocol (SCEP) server so that iMaster NCE-Campus can apply for client certificates from the Windows CA server through SCEP. The SCEP server generates client certificates based on CA certificates and issues the certificates to end users.
Procedure
- Choose from the main menu.
- Click the Boarding Management > SCEP Server Configuration tab, set parameters, and click Test Connection.
![]()
- After the test is successful, click Save.
Parameter Description
Parameter |
Description |
|---|---|
Access protocol |
Protocol used by iMaster NCE-Campus to access the SCEP server. HTTPS and HTTP are supported. If Require SSL is enabled for the SCEP server, this parameter must be set to HTTPS. |
SCEP server URL |
URL of the SCEP server. HTTPS is recommended, because it is more secure than HTTP. An example using HTTPS is https://scep_ip:port/CertSrv/mscep/mscep.dll and an example using HTTP is http://scep_ip:port/CertSrv/mscep/mscep.dll. In the URL, scep_ip indicates the IP address of the SCEP server, and port indicates the port number of the SCEP server. The port number is 80 or 443 if HTTP or HTTPS is specified, respectively. |
Authentication domain account/Password |
If Windows identity authentication is enabled on the SCEP server, a domain account is required to apply for a user certificate from the SCEP server. |
Certificate DN template |
Fields supported in a certificate DN template used to apply for certificates. CN: account, in the %Username% format DC: domain controller OU: organizational unit O: organization C: country/region |
Verifying the server certificate |
Whether to verify the SCEP server certificate. When this function is enabled, the root certificate of the SCEP server is verified during client certificate application. Client certificates will be issued to users only when the verification succeeds. If this function is disabled, the root certificate of the SCEP server is not verified. |
CaCert parameters |
Built-in CA Management
Configuring a Certificate Profile
Context
A certificate profile contains a set of rules and settings used for certificate application and management. These rules and settings can be simple or complex to meet your varying requirements. This section describes only the mandatory steps for configuring a certificate profile for the built-in CA. For details about how to configure other certificate profiles, see Configuring a Certificate Profile and Configuring a CA.
Procedure
- Choose from the main menu.
- Choose Management > Certificate Profile from the navigation pane.
- Click New to create a certificate profile with Certificate Level being Root CA or End entity.
![]()
![]()
For parameter description, see the following table.
- Click Submit.
- Choose Management > CA from the navigation pane and click New to associate the created certificate profile with the root CA.
![]()
For parameter description, see the following table.
- Click Next.
- In the profile association list, select the profile to be associated.
![]()
Configure an associated profile for the CA to issue certificates. The associated profile must be a sub-CA profile or an end-entity profile.
A CA must be associated with at least one profile, and a maximum of 16 profiles can be associated.
- In the default profile list, select an associated profile as the default profile.
![]()
- During certificate application using CMP, if the request carries the profile name parameter, the specified profile is used; if the request does not carry the profile name parameter, the default profile of the CA is used.
- Only one default profile can be set for a CA.
![]()
![]()
Parameter Description
Parameter |
Description |
Value |
|
|---|---|---|---|
Label |
Name of a certificate profile. |
The name is a string of 1 to 45 characters containing letters, digits, underscores (_), and hyphens (-). The name cannot be null or all (case insensitive). |
|
Certificate Level |
Certificate level, which can be root CA, subordinate CA, or end-entity CA. |
N/A |
|
Description |
Description of a certificate profile. |
The description is a string of 0 to 128 characters containing digits, uppercase letters, lowercase letters, spaces, and special characters: ( , . ! : ; ? ). |
|
Subject |
Identifiable alias of the certificate user, including Common name(CN), Country name(C), Email address (E), Organization(O), Organizational unit(OU), State(ST), Locality(L), Domain component (DC), and User identifier (UID). |
By default, Common name is mandatory and cannot be deselected. When you need to fill in the profile subject information, the common name is a string of 1 to 127 characters containing uppercase letters, lowercase letters, digits, spaces, hyphens (-), colons (:), and dots (.). If Domain component is selected, a maximum of 4 domain components can be configured at a time when Domain component information needs to be set in the profile. |
|
Validity Period |
Validity period of a certificate profile. |
You can set the certificate profile's validity period in units of day, month, or year. The maximum validity period is 18250 days. |
|
Key Algorithm |
Key algorithm, which can be RSA or ECDSA. |
N/A |
|
Key Length |
If RSA is used, the available options are 2048, 3072, 4096, and 8192. If ECDSA is selected, the available options are 256, 384, and 521. |
N/A |
|
ECDSA Key Type |
Available options: ECprime256v1, ECsecp256r1, ECsecp384r1, and ECsecp521r1. NOTE:
Set this parameter when you select the ECDSA algorithm. |
N/A |
|
Subject Key Identifier |
Unique identifier of the certificate owner. |
N/A |
|
Authority Key Identifier |
Include Issuer and SN |
Unique identifier of the key contained in a certificate. It is used to identify multiple pairs of keys of the same certificate owner. |
N/A |
Basic Constraints |
Used to ensure that certificates are used only in certain applications. |
N/A |
|
Path Length Constraint |
When the value of the path length constraint extension is 0, it indicates that the CA certificate can only issue end entity certificates in the valid certificate path. When the value of the path length constraint extension is greater than 0, it indicates the maximum number of intermediate subordinate CA certificates that may exist in the path from the CA certificate to end entity certificates. If a CA system has n layers, the path length constraint of the top-layer CA certificate is n - 2, and those of the lower-layer certificates is n - 3, n - 4, and so on. The result is greater than or equal to 0. For example, if n is 4, the four-layer structure of the CA is root CA > subordinate CA1 > subordinate CA2 > end entity certificate. That is, the root CA issues the subordinate CA1, subordinate CA1 issues subordinate CA2, and subordinate CA2 issues the end entity certificate. In this case, the path length of the root CA is 2, the path length of subordinate CA1 is 1, and the path length of subordinate CA2 is 0. NOTE:
The path length constraint can be set only when Certificate Level is set to Root CA or Subordinate CA. |
The path length constraint must range from 0 to 9. |
|
Subject Alternative Name |
Domain name |
Domain name contained in the alias of the certificate issuing object. |
If Subject Alternative Name is selected, a maximum of 16 domain names and IP addresses in total can be configured at a time when Subject Alternative Name information needs to be set in the profile. |
IP Address |
IP address contained in the alias of the certificate issuing object. |
||
Certificate Policy |
A certificate policy defines the policy for issuing certificates and the application scenarios of certificates. A certificate policy ID is in the format of object identifier (OID). 2.5.29.32.0 indicates any policy. If you need to customize your own certificate policy, you must create a certificate policy ID, which must be constructed based on the enterprise ID allocated by the IANA. You can obtain the enterprise ID from the IANA free of charge. A certificate policy consists of a certificate policy ID and a qualifier. The certificate policy ID must be unique in the certificate policy extensions of a certificate. The qualifier is used to express the detailed information that depends on the policy. The qualifier includes the following three types:
|
A maximum of four certificate policies can be created for each certificate profile. The certificate policy ID must be a string of 3 to 256 characters prefixed with 0./1./2. If the period (.) is followed by 0, 0 cannot be followed by other digits. For example, 2.5.29.32.0 is in correct format, but 2.02 is in incorrect format. The CPS URI must contain 1 to 256 characters. The user notice text must contain 1 to 200 characters, including digits, uppercase letters, lowercase letters, spaces, and special characters: ( , . ! : ; ? ). |
|
Key Usage |
Digital Signature |
A signature generated using the private key of the issuer. It is used for entity authentication and data source integrity authentication. |
N/A |
Content Commitment |
Verifies digital signature denial services used to provide non-digital signatures, preventing the signing entity from incorrectly denying certain operations. In the case of subsequent conflicts, a reliable third party can determine the authenticity of the signature data. |
N/A |
|
Key Encipherment |
This extension must be present in the certificate containing the public key and is used to verify the digital signature certificate or CRL in other public keys. When this extension exists, it shall be marked as critical. |
N/A |
|
CRL Signature |
Required when the subject public key is used to verify the signature in the revocation information (such as CRL). |
If the certificate level of the profile is Root CA or Subordinate CA, CRL Signature is selected by default for Key Usage and can be deselected. |
|
Data Encipherment |
Used to encrypt important user data instead of encoding keys. |
N/A |
|
Certificate Signature |
Used to verify the signature in the public key certificate. |
If the certificate level of the profile is Root CA or Subordinate CA, Certificate Signature is selected by default for Key Usage and can be deselected. |
|
Key Agreement |
Key protocol. For example, when the Diffie-Hellman key is used for key management, select this option. |
N/A |
|
Encipher Only |
Uses a key to encrypt data only when the key protocol is run. |
N/A |
|
Decipher Only |
Uses a key to decrypt data only when the key protocol is run. |
N/A |
|
Extended Key Usage |
TLS Web Server Identity Authentication |
Authenticates the TLS www server. Digital Signature, Key Encipherment, or Key Agreement may also provide the same function. |
N/A |
TLS Web Client Identity Authentication |
Authenticates the TLS www client. Digital Signature and/or Key Agreement may also provide the same function. |
N/A |
|
Sign Executable Code |
Signs the executable code that can be downloaded. Digital Signature may also provide the same function. |
N/A |
|
Timestamping |
Binds the hash of the object to the time. Digital Signature and/or Content Commitment may also provide the same function. |
N/A |
|
Email Protection |
Protects emails. Digital Signature, Content Commitment, and/or Key Encipherment or Key Agreement may also provide the same function. |
N/A |
|
IPSec End System |
IP security terminal system. |
N/A |
|
IPSec User |
IP security user. |
N/A |
|
IPSec Tunnel |
IP security tunnel. |
N/A |
|
CRL Distribution Point |
CRL distributions. Users can access the corresponding CRL based on this parameter setting. |
N/A |
|
Parameter |
Description |
Value |
|
|---|---|---|---|
Label |
Name of a CA. |
|
|
Status |
Whether to activate a CA. |
By default, the CA created is activated. |
|
Signature Algorithm |
Signature algorithm used for a CA to issue certificates. NOTE:
RSASSA-PSS is more secure than RSA. Currently, only TLS1.3 supports the certificate signed by RSASSA-PSS. TLS1.2 and earlier versions do not support the certificate signed by RSASSA-PSS. If the certificate issued by the user is used for TLS communication, confirm the TLS version before configuring the CA signature algorithm. Otherwise, the TLS communication may fail. |
N/A |
|
Certificate SN Length |
Length of the unique number assigned by a CA to a certificate. |
The value is an integer ranging from 18 to 40. |
|
Max Validity Period |
Maximum validity period of a certificate. |
You can set the certificate validity period in units of day, month, or year. The maximum validity period is 18250 days. |
|
CRL Generation Interval |
Interval for generating a CRL. |
The value is an integer ranging from 1 to 60, in days. |
|
CRL Generation Time |
Time when the CRL is generated. |
N/A |
|
CRL Overlap Time |
Period during which a user can obtain a new CRL before the old CRL is considered unavailable. |
The value is an integer ranging from 1 to 60, in minutes. |
|
Include Revocation Reasons |
Whether to include the revocation reason. |
The default value is Yes. |
|
CRL Server |
Server to which a CRL is published. |
N/A |
|
Publication Mode |
Whether a CRL is published manually or automatically. If you select Automatic, you must configure the CRL server and the publication period. |
|
|
New self-signed certificate |
A certificate issued by a signing entity to itself, not by an authoritative CA. When creating a CA in self-signed mode, you need to select a root CA certificate profile and enter the user information configured in the profile. |
N/A |
|
Upload certificate file |
Certificate File |
You can create a CA by uploading a local certificate file. In this mode, you will create a subordinate CA of the organization that issues the certificate file. This subordinate CA is used to issue certificates to lower-level organizations. |
|
Certificate Password |
Password set for a certificate during certificate application. The password is contained in the .p12 file. You need to enter this password when uploading the certificate file. |
N/A |
|
Upload Certificate Chain |
Upload the corresponding certificate chain. You can select multiple files. For example, if a level-3 CA certificate is imported, upload the corresponding level-1 and level-2 CA certificates. |
|
|
Checking the CMP Protocol Information
Context
When configuring the built-in CA, you are advised to use the default Certificate Management Protocol (CMP) configuration. For details about the CMP configuration, see Configuring CMP Information.
Procedure
- Choose from the main menu.
- Choose Protocol Configuration > CMP from the navigation pane.
- Click the Protocol Configuration tab and click
![]()
next to the CA to check CMP parameters.![]()
next to the CA to check CMP parameters.
Configuring Request Verification
Request verification protects request messages send by terminals to a CA.
Procedure
- Choose from the main menu of the service plane.
- Choose from the navigation tree on the left.
- On the Requestor Configuration tab page, click New. On the Add Requestor Configuration page, set required parameters.
![]()
- Supplier mode: The request verification certificate is used to verify the trusted certificate chain in the request message.
- The request verification certificate file and supplier root certificate to be uploaded must be in .cer or .crt format. Only one file can be uploaded and the file size cannot exceed 10 KB.
- Click Submit.
Related Tasks
- Viewing request verification information
Choose . On the Requestor Configuration tab page, click a request verification name. On the page that is displayed, you can view the detailed information.
- Searching for request verification information
Choose . On the Requestor Configuration tab page, enter a request verification name in the name search box and click
![]()
to find the specified request verification and view the details. - Modification request verification
Choose . On the Requestor Configuration tab page, click Modify corresponding to the desired request verification. On the page that is displayed, modify request verification information.
![]()
The request verification name cannot be changed.
- Deleting request verification
Choose . On the Requestor Configuration tab page, click Delete corresponding to the desired request verification.
- Downloading a request verification certificate
Choose . On the Requestor Configuration tab page, click Download corresponding to the desired request verification to download the request verification certificate.
![]()
- The password is a string of 8 to 128 characters containing at least three of the following: digits, uppercase letters, lowercase letters, and special characters. In addition, the password cannot contain two or more of the same characters consecutively.
- The downloaded request verification certificate is in .p12 format. The password is contained in the .p12 file. Enter the password for verification when using a certificate file in .p12 format.
- You can download the request verification certificate only when the signature type is self-signed.
to find the specified request verification and view the details.Configuring CA Interconnection
Context
iMaster NCE-Campus can use the built-in CA server to authenticate terminal certificates. After the built-in CA server is configured, you need to configure the interconnection between iMaster NCE-Campus and the built-in CA server. After the configuration is complete, when a terminal accesses the network, the built-in CA server authenticates the terminal's certificate. If the authentication succeeds, the terminal is allowed to access the network. Otherwise, the terminal's network access request is denied.
Prerequisites
The CA server and CMP protocol have been configured. For details, see Configuring the CA Service.
Procedure
- Choose from the main menu and choose Online Certificate Management > CA Interconnection from the navigation pane.
- Click Create. On the page that is displayed, set interconnection parameters. Only one CA server can be configured.
![]()
- Click OK.
- Click
![]()
in the Operation column to test the connectivity of the CA server.![]()
in the Operation column to test the connectivity of the CA server.
Parameter description
Parameter |
Description |
Remarks |
|---|---|---|
Allas |
Name of the CA server to be interconnected with iMaster NCE-Campus. |
- |
Protocol |
Protocol used for interconnection with the CA server. Currently, only the CMPv2 protocol is supported. |
- |
CA address |
The CA address is divided into three segments:
|
For details about how to configure the CMP, see Configuring CMP. |
Public key file/Private key file |
After the CMP configuration is complete, upload the CMP certificate to the Linux operating system, generate a public key file and a private key file based on the CMP certificate, and download the key files to the local host. Run the following command to generate the public key file: openssl pkcs12 -in CCRequester.p12 -clcerts -nokeys -out public.pem Run the following command to generate the private key file: openssl pkcs12 -in CCRequester.p12 -nocerts -out private.pem NOTE:
In this example, CCRequester.p12 is the downloaded CMP certificate. |
|
Private key password |
The value must be the same as the password entered when the CMP certificate is downloaded. |
|
Certificate (chain) of trusted CA |
Format of the CMP request certificate. You need to change the file format to PEM. If Certificate (chain) of trusted CA is set to Self-signed, set this parameter value to the same as CA certificate chain. |
|
CA certificate chain |
Format of the CA certificate downloaded during CA configuration. You need to change the file format to PEM. |
For details about how to configure a CA server and download a CA certificate, see Configuring a CA. |
(Optional) Configuring a CRL Server
If you want to publish the CRL corresponding to a CA to a specified CRL server, you can configure information about the CRL server on the CRL management page.
Context
The Certificate Authority Service supports manual and automatic CRL publishing.
Procedure
- Choose from the main menu of the service plane.
- Choose from the navigation tree on the left.
- On the CRL Server tab page, click New and set parameters.
For detailed parameter descriptions, see Table 5-238.
Table 5-238 CRL server parametersParameter
Description
Value
Label
Name of a CRL server.
The name is a string of 1 to 45 characters containing letters, digits, underscores (_), and hyphens (-).
The name cannot be null or all (case insensitive).
Publication Mode
Type of the CRL server, which can be LDAP or FTP.
A maximum of five servers can be added regardless of the server type.
NOTICE:LDAP is recommended because of its higher security than FTP.
N/A
Server Address
IP address of the server.
N/A
Use TLS
Whether to publish the CRL to the LDAP server or FTP server using TLS.
NOTICE:- If you do not use the TLS protocol, a security risk may exist.
- LDAP is recommended when setting Release Type because of its higher security than FTP.
The default value is Yes.
Port Number
Port number of the server.
- The port number is an integer ranging from 1 to 65535.
- If the LDAP server is selected and the TLS protocol is not used, the default port number is 389.
- If the LDAP server is selected and the TLS protocol is used, the default port number is 636.
- When the FTP server is selected, the default port number is 21.NOTICE:
LDAP is recommended when setting Release Type because of its higher security than FTP.
Login Name
User name for logging in to the server.
The login name is a string 1 to 128 characters containing digits, uppercase letters, lowercase letters, underscores (_), hyphens (-), equal signs (=), and commas (,). The value cannot contain the following special characters: (/\: *?" <>|).
Password
Password for logging in to the server.
It is recommended that the password contain 6 to 64 characters, including at least three types of the following: digits, uppercase letters, lowercase letters, and special characters. The password cannot be the same as the login name or the reverse of the login name.
Publication Directory
Directory of the server to which the CRL is published.
N/A
Trust certificate
Local certificate file.
NOTICE:If the RSA key length is 1024 or the uploaded trust certificate uses the SHA1withRSA algorithm, security risks exist.
- The certificate file must be in .pem, .cer, or .crt format.
- Only one file can be uploaded and the file size cannot exceed 10 KB.
Related Tasks
- Viewing a CRL server
On the CRL Server tab page under , click the name of a CRL server to view detailed information about this CRL server.
- Modifying a CRL server
On the CRL Server tab page under , click Modify in the Operation column of a CRL server to modify the configuration of this CRL server.
- Deleting a CRL server
On the CRL Server tab page under , click Delete in the Operation column of a CRL server to delete this CRL server.
- Updating a CRL
On the CRL tab page under , click Update in the Operation column of a CRL to manually update the CRL.
- Manually publishing a CRL
On the CRL tab page under , click Publish in the Operation column of a CRL to manually publish the CRL.
- Automatically publishing a CRL
When configuring a CA on the page, you can set an interval for automatically publishing CRLs. Then the system automatically publishes CRLs at the specified interval.
- Searching for a CRL
On the CRL tab page under , enter a CR name, click
![]()
, and view CRL information of the CA that is searched out. - Downloading a CRL
On the CRL tab page under , click Download in the Operation column of a CRL to download the CRL to the local computer.
, and view CRL information of the CA that is searched out.(Optional) Interworking with a CRL Server
Context
You can set parameters for interconnecting iMaster NCE-Campus with a certificate revocation list (CRL) server so that certificates can be revoked online without the need to manually import the CRL file. Users using certificates in the CRL will fail to be authenticated.
Prerequisites
- An LDAP or FTP server has been prepared and the server can communicate with iMaster NCE-Campus. The IP address, username, password, port number, and certificate of the LDAP or FTP server have been obtained. To ensure file transfer security, the LDAP or FTP server must support the SSL+certificate encryption mode. Otherwise, the LDAP or FTP server cannot communicate with iMaster NCE-Campus. In addition, for security purposes, it is recommended that the username and password of the FTP server meet the complexity requirements.
- You have obtained the CRL server information, including IP address, port number, username, password, CRL file path, and the trust certificate trust.cer. For details, see (Optional) Configuring a CRL Server.
Procedure
- Choose from the main menu and choose Online Certificate Management > CRL Server Interconnection from the navigation pane.
- Click Create. On the displayed page for configuring CRL server interconnection, set required parameters. Only one CRL server can be configured.
![]()
- Click OK.
- Click
![]()
in the Operation column to test the connectivity of the CRL server.![]()
If the test fails, rectify the fault based on the detailed information and connect to the CRL server again.
![]()
in the Operation column to test the connectivity of the CRL server.
Configuring a CA Certificate Policy
Context
After the built-in CA server is configured, you need to configure a CA certificate policy and bind the built-in CA server to the policy.
To manage clients who use certificates to access iMaster NCE-Campus, you need to define mappings between client certificates and iMaster NCE-Campus user accounts when configuring certificate-based authentication. That is, you need to create user accounts and define mappings between the accounts and client certificates on iMaster iMaster NCE-Campus. In this case, administrators can manage the clients who use certificates to access iMaster NCE-Campus by managing the accounts associated with the certificates.
Procedure
- Choose from the main menu. The default CA management mode is third-party CA. Click
![]()
to the built-in CA mode.![]()
- Click Add to create a certificate policy.
![]()
- After the certificate policy is created, click
![]()
next to the certificate alias to configure mapping rules between certificates and users and between certificates and user groups![]()
to the built-in CA mode.
next to the certificate alias to configure mapping rules between certificates and users and between certificates and user groups
Parameter Description
Parameter |
Description |
|---|---|
Policy name |
Certificate policy name. After being connected to the built-in CA server, iMaster NCE-Campus obtains the policy name based on the URL of the built-in CA server. |
Key algorithm type/Key length |
Key algorithm type and key length used for applying for a terminal certificate. The two values must be the same as those configured in the certificate profile of the terminal entity type. |
Terminal Certificate Subject |
Fields supported in a certificate DN template used to apply for certificates. CN: Common name C: Country name O: Organization name OU: organization unit name ST: State L: Locality E: Email |
Parameter |
Description |
|
|---|---|---|
Theme |
Theme |
Theme based on which user name information is obtained from a user certificate. The options are as follows:
|
Verify the user |
Check whether the user name in the user certificate is the same as that configured on the local device or CA server. If the information is consistent, the user is authenticated. If the information is inconsistent, the user fails to be authenticated. |
|
Default user group |
Default user group specified when Verify the user is disabled. If a certificate user whose information is obtained based on the theme does not exist, the user is authorized based on the rules applied to the default user group. |
|
Advanced |
Mapping rule |
Advanced mapping rule based on which user name information is obtained from a user certificate. Rule based on which user name information is obtained from a user certificate. The rule format is Theme field variable+Specified character string. Multiple theme field variables and character strings can be contained. For example, if the mapping rule is CN + "@huawei.com" and CN=JSON, the parsed user name is JSON@huawei.com. If the mapping rule is CN + "at" + O + "@huawei.com", and CN=TER and O=BOB, the parsed user name is TERatBOB@huawei.com. If multiple duplicate fields exist in a user certificate, iMaster NCE-Campus obtains the value of the first field when the user name is parsed. |
Verify the user |
Check whether the user name in the user certificate is the same as that configured on the local device or CA server. If the information is consistent, the user is authenticated. If the information is inconsistent, the user fails to be authenticated. |
|
Default user group |
Default user group specified when Verify the user is disabled. If a certificate user whose information is obtained based on the advanced mapping rule does not exist, the user is authorized based on the rules applied to the default user group. |
|
Boarding Configuration
Application Scenarios and Fundamentals
Overview
The terminal configuration is complex when 802.1X authentication is used. Especially, when EAP-TLS is used, users need to download and install certificates.
The boarding function simplifies terminal configuration for network access through 802.1X. The network configuration tool provided for Android and Windows terminals and the configuration files provided for iOS terminals enable the terminals to complete 802.1X access configuration automatically. This function is available on iOS, Android, Windows wireless PCs, and Windows wired PCs.
The boarding function supports EAP-TLS and PEAP with MSCHAPV2. A Windows CA server is required to provide certificates for terminals only when EAP-TLS is used. Unless otherwise specified, EAP-TLS is used as an example in this section.
After the boarding function is configured, end users only need to enter usernames and passwords to access the Internet.
End users enter their usernames and passwords to initiate identity authentication to iMaster NCE-Campus. They can access any website after iMaster NCE-Campus verifies their identities. Then, iMaster NCE-Campus redirects the users to the corresponding portal authentication page. End users need to download and install the Boarding tool on the Portal authentication page to complete authentication. Users can only download and install the Boarding tool for authentication through the portal authentication page, but not in any other means.
The following functions are available in the single-SSID scenario:
- Network configuration tool for Android and Windows terminals and configuration files for iOS terminals
The administrator configures only one SSID for 802.1X authentication. This SSID is used for initial configuration and network access at the same time. When a user connects to the SSID and accesses any web page, the user is redirected to the portal authentication page.
The administrator has configured the link for downloading the network configuration tool or configuration file on the portal authentication page. The user can click the link to download the tool or configuration file.
- Automatic certificate application
iMaster NCE-Campus applies for a user certificate from the Windows CA server and issues the certificate to the terminal for installation.
- Automatic network access configuration
iMaster NCE-Campus automatically obtains the 802.1X network access configuration preconfigured by the administrator and configures network access based on the preconfigured parameters. In such cases, users can access the Internet by connecting to the SSID.
The Boarding deployment scheme provides the following functions:
Distribution of network configuration tools for terminals running the Android and Windows OSs, and configuration files for terminals running the iOS
The administrator deploys two service set identifiers (SSIDs). One is used for initializing the network and uses Portal authentication. The other one is used for service access and uses 802.1X authentication. If a user associates with the initialization SSID and accesses a web page, the user is redirected to the Portal authentication page.
The administrator has configured the download link of network configuration tools or configuration files on the Portal authentication page. The user can click the link to download a network configuration tool or configuration file.
Automatic application for certificates
A user enters the account and password on a terminal, and initiates a request for identity authentication to the iMaster NCE-Campus. After the identity authentication succeeds, the iMaster NCE-Campus applies for a user certificate from the Windows CA server and sends the certificate to the terminal.
Automatic configuration for the network access
A user can automatically obtain 802.1X access configurations predefined by the administrator. After 802.1X configuration is complete according to the predefined parameters, the user can associate with the service access SSID to access a network through 802.1X authentication.
Using a Wireless Android or Windows Terminal to Access the Internet
- A user uses an Android or Windows terminal to connect to the Internet in wireless mode and associates with the SSID.
- The user enters the account and password and sends an identity authentication request to the iMaster NCE-Campus server.
![]()
The Boarding client on a Windows PC supports authentication using a domain account.
- After the user identity is verified by iMaster NCE-Campus, the user can access any website. iMaster NCE-Campus determines that the user is using an Android or a Windows terminal based on the useragent parameter in the HTTP request and redirects the user to the target portal authentication page.
- On the portal authentication page, the user using an Android terminal downloads the network configuration tool in .apk format whereas the user using a Windows terminal downloads the tool in .exe format. Then, the user installs the downloaded tool.
The administrator needs to predefine a portal authentication page on the portal server and a portal page push policy on iMaster NCE-Campus, and provide download links of network configuration tools in .apk and .exe formats for Android and Windows terminals.
- iMaster NCE-Campus applies for a certificate from the Windows CA server using SCEP.
- iMaster NCE-Campus sends the obtained certificate and network access parameters predefined by the administrator to the terminal as a configuration file.
- After receiving the certificate, the terminal automatically installs the certificate, completes the 802.1X network access configuration using the configuration file, and automatically connects to the desired network. Then, the user can access the Internet.
- iMaster NCE-Campus queries whether certificates using by users are revoked using OCSP. If a user certificate has been revoked on the Windows CA server, the certificate becomes invalid and the user using this certificate cannot access the Internet.
In addition to OCSP, iMaster NCE-Campus can verify whether a user certificate has been revoked using the root certificate of the CA server along with the CRL.
A user uses a terminal running the Android or Windows OS to access a wireless network and associates with the initialization SSID.
The user accesses a web page. The iMaster NCE-Campus checks whether the terminal runs the Android or Windows OS based on the useragent parameter carried in the HTTP request packet, and then redirects the user to the Portal authentication page.
If the terminal runs the Android OS, the user can download the network configuration tool (in the format of *.apk) on the Portal authentication page and install the tool. If the terminal runs the Windows OS, the user can download the network configuration tool (in the format of *.exe) on the Portal authentication page and install the tool.
The administrator needs to define Portal authentication pages and page push policies on the server, providing download links of network configuration tools in formats of .apk and .exe for terminals running the Android and Windows OSs.
The administrator only needs to define a Portal authentication page for terminals running the Android and Windows OSs.
A user enters the account and password on the configuration tool and initiates a request for identity authentication to the iMaster NCE-Campus.
After the user identity authentication succeeds, the configuration tool automatically completes 802.1X certificate authentication and network access processes.
![]()
The Boarding client on a Windows PC supports authentication using a domain account.
After the user identity authentication succeeds, the iMaster NCE-Campus uses the Simple Certificate Enrollment Protocol (SCEP) to apply for a certificate from the Windows CA server.
The iMaster NCE-Campus sends the configuration file that contains the applied certificate and network access parameters defined by the administrator to the terminal.
The terminal automatically installs the received certificate and completes the 802.1X configuration based on the configuration file. After that, the terminal automatically associates with the service access SSID and can access the Internet.
The user can use the Online Certificate Status Protocol (OCSP) to check whether a user certificate is revoked. If a user certificate is revoked from the Windows CA server, the certificate is invalid and the user cannot not access the network.
The user can also check the root certificate and Certificate Revocation List (CRL) to verify whether a user certificate is revoked.
Using a Wireless iOS Terminal to Access the Network
- An end user uses an iOS terminal to access the Internet in wireless mode by connecting to the SSID.
- The user enters the account and password and sends an identity authentication request to the iMaster NCE-Campus server.
- After the user identity is verified by iMaster NCE-Campus, the user can access any website. iMaster NCE-Campus determines that the user is using an iOS terminal based on the useragent parameter in the HTTP request and redirects the user to the target portal authentication page.
The administrator needs to predefine a portal authentication page on the portal server and a portal page push policy for iOS terminals on iMaster NCE-Campus and provide a download link for the required configuration file.
![]()
The configuration file for iOS terminals must be in mobileconfig format which is officially defined by Apple and needs to comply with the security protocol defined by Apple.
- The user downloads the network configuration file from the portal authentication page and installs the file.
- iMaster NCE-Campus applies for a certificate from the Windows CA server using SCEP.
- iMaster NCE-Campus sends the obtained certificate and 802.1X network access parameters to the iOS terminal as a configuration file in *.mobileconfig format.
- iMaster NCE-Campus sends the configuration file to the end user.
- After the configuration file is installed on the iOS terminal, the user certificate is installed and 802.1X network access configuration is completed. The user can access the Internet by connecting to the SSID.
- iMaster NCE-Campus queries whether certificates using by users are revoked using OCSP. If a user certificate has been revoked on the Windows CA server, the certificate becomes invalid and the user using this certificate cannot access the Internet.
In addition to OCSP, iMaster NCE-Campus can verify whether a user certificate has been revoked using the root certificate of the CA server along with the CRL.
A user uses a terminal running the iOS to access a wireless network and associates with the initialization SSID.
The user accesses a web page. The iMaster NCE-Campus checks whether the terminal runs the iOS based on the useragent parameter carried in the HTTP request packet, and then redirects the user to the Portal authentication page.
The administrator needs to define a Portal authentication page and page push policies for terminals running the iOS, providing download links of configuration files for terminals running the iOS.
![]()
Configuration files of the iOS system use the mobileconfig format defined by Apple, which comply with Apple's security protocols.
The administrator needs to define a Portal authentication page and authentication success page for terminals running the iOS.
A user enters the account and password on the Portal authentication page and initiates a request for identity authentication to the iMaster NCE-Campus.
After the user identity authentication succeeds, the iMaster NCE-Campus uses SCEP to apply for a certificate from the Windows CA server.
The iMaster NCE-Campus integrates the applied certificate and configuration parameters for 802.1X network access into a configuration file (in the format of *.mobileconfig).
After the user passes identity authentication, the authentication success page is displayed, where the user can download the configuration file (in the format of *.mobileconfig).
After the configuration file is installed, the certificate is installed, and 802.1X network configurations are complete. The user can associate with the service access SSID to access the Internet.
The user can use the Online Certificate Status Protocol (OCSP) to check whether a user certificate is revoked. If a user certificate is revoked from the Windows CA server, the certificate is invalid and the user cannot not access the network.
The user can also check the root certificate and Certificate Revocation List (CRL) to verify whether a user certificate is revoked. For details, see Using a Mobile Certificate to Authenticate.
Using a Wired Windows Terminal to Access the Internet
- An end user uses a Windows terminal to access the Internet in wired mode.
- An end user accesses a website. iMaster NCE-Campus determines that the user is using a Windows terminal based on the useragent parameter in the HTTP request and redirects the user to the target portal authentication page.
- The user downloads the network configuration tool in *.exe format on the portal authentication page and installs the tool.
The administrator needs to predefine a portal authentication page on the portal server and a portal page push policy for Windows terminals on iMaster NCE-Campus and provide a download link for the required configuration tool.
For Windows terminals, the administrator needs to define a portal authentication page only. No other portal page is required.
- The user enters the account and password in the configuration tool to initiate identity authentication to the iMaster NCE-Campus server.
After the user identity is verified, the configuration tool automatically performs 802.1X network access configuration.
![]()
The Boarding client on a Windows PC supports authentication using a domain account.
- After the user identity is verified, iMaster NCE-Campus applies for a certificate from the Windows CA server using SCEP.
- iMaster NCE-Campus sends the obtained certificate and network access parameters predefined by the administrator to the terminal as a configuration file.
- After receiving the certificate, the terminal automatically installs the certificate, completes the 802.1X network access configuration based on the configuration file, and performs 802.1X authentication. After the authentication succeeds, the user can access the Internet.
- iMaster NCE-Campus queries whether certificates using by users are revoked using OCSP. If a user certificate has been revoked on the Windows CA server, the certificate becomes invalid and the user using this certificate cannot access the Internet.
In addition to OCSP, iMaster NCE-Campus can verify whether a user certificate has been revoked using the root certificate of the CA server along with the CRL.
Configuring the Boarding Function (Single-SSID Scenario)
To allow users to access the Internet using Android, Windows, or iOS terminals, the administrator needs to deploy a Windows CA server, configure WACs, and perform required configurations on iMaster NCE-Campus. When an end user accesses the Internet, the terminal automatically uses the network configuration tool or configuration file to complete 802.1X access configuration.
Configuration Process
To enable users to access the Internet using the boarding function, you need to configure the access authentication function, a CA server, an SCEP server, and network access parameters, as well as customize portal pages. The following figure shows the detailed configuration procedure.
Procedure
- (Optional) If EAP-TLS is used, configure CA management. For details, see Third-Party CA Management or Built-in CA Management.
- Customize a portal page.
- Choose from the main menu.
- On the Page Customization tab page, select User-defined template and click
![]()
to create a user-defined template. Select the username and password template. - Select the user notice page, add the boarding control, and delete unnecessary controls from the template. After all settings are complete, click Save and then Release.
![]()
![]()
- Create a user. For details, see Configuring a User Group and User.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to 802.1X authentication and set the access mode as needed. Set the authentication protocol to EAP-PEAP-MSCHAPv2 protocol(Local account, AD, and LDAP) or EAP-TLS protocol(Local account, AD, LDAP) as needed. For details about other parameters in authentication rules, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create and configure authorization result 1 to ensure that users can be redirected to the specified portal page. Enable Forcible redirection, set the service type to Boarding, and configure Forcible redirection ACL. Configure an ACL to deny access to the southbound IP address of the controller and allow access to other IP addresses. For example:
![]()
Select the customized portal page, and configure the page as the first portal page pushed to end users.
![]()
- Click Create and configure authorization result 2 to assign network access permissions to authorized users. Forcible redirection does not need to be configured. For details about other parameters in authorization results, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create and configure authorization rule 1. Set the authentication mode to 802.1X authentication and set the access mode as needed. Toggle Enable Customization Condition on, select a protocol other than EAP-TLS protocol(Local account, AD, LDAP), and select authorization result 1. For details about other parameters in authorization rules, see Configuring an Authorization Rule.
- Click Create and configure authorization rule 2. Set the authentication mode to 802.1X authentication and set the access mode as needed. Toggle Enable Customization Condition on and select EAP-TLS protocol(Local account, AD, LDAP). Select authorization result 2 or the default authorization result Permit Access.
- Configure an authentication point.
Configure 802.1X authentication on APs, WACs, or switches to allow users to access the Internet. For details, see Configuring an Authentication Point.
- Configure a network access policy. Choose from the main menu and click Create. Specify network access parameters, such as the security type, encryption mode, SSID, and protocol used for wireless access and the protocol used for wired access. You can obtain network access parameter settings through the network configuration tool or configuration file.
![]()
to create a user-defined template. Select the username and password template.
Parameter Description
Parameter |
Description |
|
|---|---|---|
Access user |
User group |
User group that matches the network access policy. If this parameter is not set, all user groups match this network access policy by default. |
Identified terminal type |
Type of identified terminals that will match this network access policy. You can specify a custom terminal group, a device type, or an operating system to match desired terminals. |
|
Local and synchronized AD/LDAP accounts |
Local and synchronized AD/LDAP accounts that match the network access policy. If this parameter is not specified, all user accounts will match this network access policy by default. |
|
Unsynchronized AD/LDAP account |
Unsynchronized AD/LDAP accounts that match the network access policy. If this parameter is not specified, all user accounts will match this network access policy by default. |
|
Role |
User roles that match the network access policy. If this parameter is not set, all user roles match this network access policy by default. |
|
Wireless configuration |
Security Type |
Security policy for wireless access. Currently, WPA-Enterprise and WPA2-Enterprise are supported. |
Encryption Type |
Encryption algorithm for wireless access. The TKIP and AES encryption algorithms are supported. |
|
SSID |
SSID for network access. |
|
SSID hiding |
Whether to allow wireless users to access hidden SSIDs. |
|
Automatic connection |
Whether to allow authenticated wireless users to automatically connect to the network upon next login. |
|
Android |
Protocol used for authentication on users using Android terminals when the boarding function is configured. PEAP with MSCHAPv2, PEAP with GTC, and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
|
iOS |
Protocol used for authentication on users using iOS terminals when the boarding function is configured. PEAP and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
|
Windows |
Protocol used for authentication on users using Windows terminals when the boarding function is configured. PEAP with MSCHAPv2 and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
|
Linux |
Protocol used for authentication on users using Linux terminals when the boarding function is configured. PEAP with MSCHAPv2 and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
|
Wired configuration |
Android |
Protocol used for authentication on users using Android terminals when the boarding function is configured. PEAP with MSCHAPv2, PEAP with GTC, and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
Windows |
Protocol used for authentication on users using Windows terminals when the boarding function is configured. PEAP with MSCHAPv2 and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
|
Linux |
Protocol used for authentication on users using Linux terminals when the boarding function is configured. PEAP with MSCHAPv2 and TLS are supported. The protocol must be the same as that configured in the corresponding authentication rule. |
|
Configuring the Boarding Function (Dual-SSID Scenario)
To allow users to access the Internet using Android, Windows, or iOS terminals, the administrator needs to deploy a Windows CA server, configure WACs, and perform required configurations on iMaster NCE-Campus. When an end user accesses the Internet, the terminal automatically uses the network configuration tool or configuration file to complete 802.1X access configuration.
Configuration Process
To enable users to access the Internet using the boarding function, you need to configure the access authentication function, a CA server, an SCEP server, and network access parameters, as well as customize portal pages. The following figure shows the detailed configuration procedure.
Procedure
- (Optional) If EAP-TLS is used, configure CA management. For details, see Third-Party CA Management or Built-in CA Management.
- Customize a portal page.
- Choose from the main menu.
- On the Page Customization tab page, select User-defined template and click
![]()
to create a user-defined template. Select the username and password template. - Select the user notice page, add the boarding control, and delete unnecessary controls from the template. After all settings are complete, click Save and then Release.
![]()
![]()
- Create a user. For details, see Configuring a User Group and User.
- Configure a portal authentication rule.
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to User access authentication and set the access mode as needed.
For details about other parameters in authentication rules, see Configuring an Authentication Rule.
- Configure a portal authorization result.
- Choose from the main menu.
- Click Create and configure authorization result 1 to ensure that users can be redirected to the specified portal page. Enable Forcible redirection, set the service type to Boarding, and configure Forcible redirection ACL. Configure an ACL to deny access to the southbound IP address of the controller and allow access to other IP addresses. For example:
![]()
Select the customized portal page, and configure the page as the first portal page pushed to end users.
![]()
- Configure a portal authorization rule
- Choose from the main menu.
- Click Create and configure authorization rule. Set the authentication mode to User access authentication and set the access mode as needed. Toggle Enable Customization Condition on, select a protocol other than EAP-TLS protocol(Local account, AD, LDAP), and select authorization result. For details about other parameters in authorization rules, see Configuring an Authorization Rule.
- Configure a 802.1X authentication rule.
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to 802.1X authentication and set the access mode as needed.
For details about other parameters in authentication rules, see Configuring an Authentication Rule.
- Configure a 802.1X authorization result.
- Choose from the main menu.
- Click Create and configure authorization result to assign network access permissions to authorized users. Forcible redirection does not need to be configured. For details about other parameters in authorization results, see Configuring an Authorization Result.
- Configure a 802.1X authorization rule.
- Choose from the main menu.
- Click Create and configure authorization rule. Set the authentication mode to 802.1X authentication and set the access mode as needed. Toggle Enable Customization Condition on and select EAP-TLS protocol(Local account, AD, LDAP). Select authorization result or the default authorization result Permit Access.
- Configure an authentication point.
Configure 802.1X authentication on APs, WACs, or switches to allow users to access the Internet. For details, see Configuring an Authentication Point.
- Configure a network access policy. Specifically, choose from the main menu and click Create. Specify network access parameters, such as the security type, encryption mode, SSID, and protocol used for wireless access and the protocol used for wired access. You can obtain network access parameter settings through the network configuration tool or configuration file.
![]()
to create a user-defined template. Select the username and password template.
AD/LDAP Synchronization
Overview
iMaster NCE-Campus can synchronize user groups and accounts from AD servers. Multiple synchronization modes are available for different storage structures on AD/LDAP servers.
Basic Concepts
Concept |
Description |
|---|---|
DC |
Domain controller which stores AD/LDAP data and identifies an AD/LDAP server. Generally, one AD/LDAP server is a domain controller. |
DN |
Distinguished name (DN) which identifies the location of an object on an AD/LDAP server. You can find the storage location of an object based on its DN. A DN includes the information about the object, its upper-layers, and the root node. In Figure 5-37, the DN of the user Lucas is CN=Lucas,OU=Accounting Dept,OU=Company,OU=Mode1,DC=example,DC=huawei,DC=com. |
Base DN |
DN of the root node. For example, the base DN in Figure 5-37 is DC=example,DC=huawei,DC=com. |
AD domain name |
Identifier of an AD server. An LDAP server has no domain name. You can log in to an AD server and access Active Directory Users and Computers to view the AD domain name. |
CN |
Common name of a group or user. For example, in Figure 5-37, CN=Lucas indicates that the user name is Lucas, and CN=VIP_Group indicates that the group name is VIP_Group. |
OU |
Organization unit (OU) that stores data in a tree structure. As a container, an OU can contain objects such as OUs, groups, and users. For example, in Figure 5-37, the user Lucas belongs to the OU Accounting Dept. |
Group |
Groups are classified into permission groups and communication groups.
A group is a logical mapping unit, but not a container. Therefore, objects such as groups or users cannot be stored in a group. |
Synchronization Mode
User groups and accounts for user management are stored on iMaster NCE-Campus in a tree structure. Similar to an enterprise organization structure, one account belongs to only one user group.
To match diversified storage structures of OUs, groups, and users on an AD/LDAP server, iMaster NCE-Campus provides multiple synchronization modes. Assume that an enterprise has an organization structure shown in Figure 5-39, you need to select a proper synchronization mode based on the storage structure.
- If an LDAP server has accounts with the same username, subsequent accounts will overwrite the account with the same username that has been synchronized successfully. That is, only the account synchronized last can be synchronized successfully.
- If different AD/LDAP servers have accounts with the same username, subsequent accounts will fail to be synchronized after an account with the same username has been synchronized successfully. That is, only the account synchronized first can be synchronized successfully.
- Mode 1: Synchronization by OU
AD/LDAP storage structure
![]()
Applicable scenarios: The OU structure on the AD/LDAP server is the same as the enterprise organization structure, so accounts are stored under the OUs to which they belong. You can directly synchronize the OU structure and users to iMaster NCE-Campus as user groups and accounts, respectively.
- Mode 2: Synchronization by group for an AD server if the organization structure is described by OU
AD storage structure
![]()
Applicable scenarios: The AD server uses OUs to indicate organization units. The OU structure on the AD server is different from the enterprise organization structure, and accounts are not stored under the OUs to which they belong. For example, OUs are stored in OU=Dept, and users are stored in OU=User.
- Mode 3: Synchronization by group for an AD server if organization structure is described by groups
AD storage structure
![]()
Applicable scenarios: Both organization units and users are stored on the AD server as groups in a flattened structure. Organization units are stored in one OU, and users are stored in another OU.
Groups cannot store data in a tree structure; so attributes are used to determine the relationships between groups. For example, the member attribute identifies a sub-group or user, and the memberOf attribute identifies a parent group.
Attributes can also determine the group to which a user belongs. For example, the memberOf attribute identifies the group to which a user belongs.
- Mode 4: Synchronization by group for an LDAP server
LDAP storage structure
![]()
Applicable scenarios: The LDAP server stores data by OUs/groups based on the enterprise organization structure, or data is not stored based on the enterprise organization structure, but the relationships can be determined by attributes.
Users are not stored in the OU/group to which they belong, but the relationships between users and the OU/group are determined by attributes.
- Mode 5: Synchronization by plane structure or customized synchronization
AD/LDAP storage structure
The data storage structure on the AD/LDAP server does not meet any of the previous requirements. Data is stored in a flattened structure, but the relationships can be determined by attributes and a calculation formula.
Applicable scenarios: Mode 5 or customized mode determines the relationships between OUs/groups as well as the OU to which users belong based on specific attributes and a calculation formula.
The difference between mode 5 and customized mode is that mode 5 provides default attributes and a calculation formula, while the customized mode does not.
- Non-synchronization
Applicable scenarios: If an enterprise has high security requirements and does not want to synchronize the enterprise organization structure and user data to iMaster NCE-Campus, user accounts and passwords are verified by an AD/LDAP server.
In non-synchronization mode, all accounts on an AD/LDAP server are synchronized to a specific user group on iMaster NCE-Campus. All authenticated accounts have permission for this user group.
Using the non-synchronization mode, iMaster NCE-Campus cannot perform precise authorization for each account.
- Synchronization by conditions
AD/LDAP storage structure
Accounts are stored in disorder, but specific attributes are used to determine the OU to which accounts belong. The data type of the attributes must be Directory String.
Applicable scenarios: In this mode, only accounts meeting the conditions can be synchronized to iMaster NCE-Campus. You need to create or import user groups on iMaster NCE-Campus based on the enterprise organization structure. These user groups are the target user groups to which accounts are synchronized. The attribute value of the OU to which an account belongs determines the mapping between the account and its target user group.
AD/LDAP Account Authentication Process
In account synchronization scenarios:
- If an account has been synchronized to iMaster NCE-Campus, the process is as follows:
- A user enters a user account and the password for authentication.
- iMaster NCE-Campus verifies the account. If the account exists, iMaster NCE-Campus sends the account and password to the AD/LDAP server to verify the password.
- If the password passes the verification, iMaster NCE-Campus authorizes the user based on the configured authorization rules.
- If an account has not been synchronized to iMaster NCE-Campus but quick synchronization is enabled, the process is as follows:
- If iMaster NCE-Campus verifies that the account does not exist, it sends the account to the AD/LDAP server.
- If the account exists on the AD/LDAP server, the account is synchronized to iMaster NCE-Campus in incremental mode. After successful account synchronization, iMaster NCE-Campus sends the account to the AD/LDAP server for password verification. The account passes authentication if password verification succeeds.
If the user group to which the unsynchronized account belongs does not exist on iMaster NCE-Campus, the corresponding user group is synchronized to iMaster NCE-Campus in incremental mode. The time required depends on the number of accounts in the user group. Authentication fails if user group synchronization is not completed. The account passes authentication when user group synchronization is completed.
- If an account has not been synchronized to iMaster NCE-Campus and quick synchronization is disabled, the user fails to be authenticated.
In non-synchronization scenarios:
After a user enters a user account and the password, iMaster NCE-Campus sends the account and password to the AD/LDAP server for verification. If the verification succeeds, iMaster NCE-Campus authorizes the user based on the mapped target user group.
Synchronization by OU for the AD/LDAP Server
Mode 1 is recommended when the storage structure of OUs and users on the AD/LDAP server is the same as the organization structure of an enterprise.
Application Scenarios
The OU structure on the AD/LDAP server is the same as the enterprise organization structure, so accounts are stored under the OUs to which they belong. You can directly synchronize the OU structure and users to iMaster NCE-Campus as user groups and accounts.
For example, Figure 5-41 shows the organization structure of an enterprise and Figure 5-42 shows the storage structure of OUs and users on the AD/LDAP server.
Procedure
- (Optional) Create a user group to which OUs and user accounts on the AD server are synchronized. If no user group is created, the root node is used as the target user group.
Choose from the main menu.
Click
![]()
to create a user group.![]()
- Configure interconnection between iMaster NCE-Campus and an AD/LDAP server. For details about how to obtain AD or LDAP server parameters, see Table1 Obtaining AD server parameters or Table2 Obtaining LDAP server parameters. Choose from the main menu. After all settings are complete, if the icon before the server address is
![]()
, the server is connected to iMaster NCE-Campus successfully. If the icon is ![]()
, the server is disconnected.![]()
- Select Mode 1 (by OU) from the Select a synchronization mode drop-down list.
![]()
- On the Configure the attributes of the user & user group page, set the mappings between object attributes on the AD/LDAP server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
In this step, attribute mappings are configured for user groups, users, extended users, and CRLs. In addition, default account attributes are synchronized from the AD server.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- Extended users refer to non-user objects (such as PCs) on the AD server. They are synchronized to iMaster NCE-Campus as users and are generally used to verify accounts during PC certificate-based authentication.
![]()
- CRLs are used for mobile certificate authentication. Objects with certain attributes are mapped to CRLs and synchronized to iMaster NCE-Campus.
![]()
- Synchronize default account attributes.
![]()
- Configure mapping attributes for user groups and users.
- Configure the synchronization range.
Set Source OU/group storage directory and Root node to be synchronized to the OU created by the AD server administrator based on the enterprise organization structure. During the synchronization, the OUs with the same structure as the enterprise organization structure are synchronized to iMaster NCE-Campus as user groups, and then the members in each OU are synchronized to user accounts in the corresponding user group on iMaster NCE-Campus.
![]()
After the synchronization, the storage structure of user groups and users on the user management page of iMaster NCE-Campus is the same as the enterprise organization structure.
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain as the system administrator. For detail, see Configuring an AD Domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
to create a user group.
, the server is connected to 
, the server is disconnected.
to synchronize user groups and accounts immediately.Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click 
, and configure the authentication component that uses the data source.
Parameter Description
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active AD server. |
Obtain the value from the AD server administrator. |
Secondary server address |
IP address of the standby AD server. |
Obtain the value from the AD server administrator. |
Authentication port |
Port used for communication between the AD server and iMaster NCE-Campus. Retain the default value. |
N/A |
AD domain name |
Domain name of an AD server. |
How Do I Obtain an AD Domain Name? |
AD short domain name |
Short domain name of the AD server. The default value is the characters before the period (.) in the AD domain name. For example, if the AD server domain name is test.com, the short domain name is test. If a short domain name is configured on the AD server, the value of this parameter must be the same as that configured on the AD server. You need to set this parameter when the username is in the format of Short domain name\Username. |
Obtain the value from the AD server administrator. |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on a subnode or the parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the AD server to iMaster NCE-Campus. |
You can obtain an existing account and password from the AD server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The Source Sockets Layer (SSL) protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the AD server. The TLS version needs to be specified if TLS is enabled, and TLS v1.2 is used by default. NOTE:
TLSv1.2 is recommended because it is more secure than TLSv1.1. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
Authentication account (SPN account)/Authentication password |
Account with the Service Principal Name (SPN) on the AD server. If the Kerberos protocol is used during AD authentication, an authentication account and password need to be entered. You are not advised to use the Kerberos protocol unless otherwise specified. |
You can obtain an existing account and password from the AD server administrator, or create an authentication account. For details, see How Do I Create an Authentication Account. |
AD server administrator configuration: Administrator account Password Port |
If an AD user who passes portal authentication needs to change the password, the AD server administrator information needs to be set on the controller. The AD server administrator rights are required when the password of an AD user needs to be changed. The SSL protocol is used when an AD user changes the password. Therefore, you must upload the AD server root certificate on iMaster NCE-Campus. |
You can obtain a username and password from the AD server administrator. |
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active LDAP server. |
Obtain the value from the LDAP server administrator. |
Secondary server address |
IP address of the standby LADP server. |
Obtain the value from the LDAP server administrator. |
Authentication port |
Port used for communication between the LDAP server and iMaster NCE-Campus. Retain the default value. |
N/A |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on the subnode or parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the LDAP server to iMaster NCE-Campus. |
You can obtain an existing account and password from the LDAP server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The SSL protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the LDAP server. Common LDAP servers and JIT Galaxy server do not support SSL, and have security risks. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
MSCHAPv2 authentication |
Only the LDAP server that stores passwords in plaintext or hexadecimal format after MD4 encryption supports EAP-PEAP-MSCHAPv2. This parameter must be the same as that for user password encryption configured on an LDAP server. Otherwise, user authentication fails. Password mapping field: The attribute (for example, userPassword of the person object) of a user object on the LDAP server is mapped to a system password. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Add domain name suffix |
Domain name suffix added to synchronized accounts. |
N/A |
Authentication password encryption |
Encryption for authentication passwords. This function is supported in PortalServer authentication, AuthServer authentication, RadiusServer authentication (PAP protocol, EAP-PEAP-GTC protocol, and EAP-TTLS-PAP protocol). If password encryption has been configured on a remote server, enable and configure password encryption. The following modes are supported: encryption, key, and encoding. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Enable extended user |
Extended user |
Object of the extended users on the AD/LDAP server to be mapped to users on iMaster NCE-Campus, for example, computer. |
User name |
Object of the extended users on the AD/LDAP server to be mapped to usernames on iMaster NCE-Campus. In most cases, usernames and accounts of extended users are the same. |
|
Account |
Object of the extended users on the AD/LDAP server to be mapped to accounts on iMaster NCE-Campus. In most cases, usernames and accounts of extended users are the same. |
|
User Group NOTE:
This parameter is unavailable in mode 5. |
OU/group ID |
Object of the extended users on the AD/LDAP server to be mapped to user groups on iMaster NCE-Campus. |
OU/group calculation formula |
OU or group to which a user belongs. For example, the memberOf attribute stores the DN of the OU or group to which a user belongs. The SUBSTRING("dn",",", 1, "START") formula is used to calculate the user group to which synchronized users belong on the controller. In the formula, commas (,) are used as separators and the first segment is deleted. For example, if the DN of an extended user object on the AD/LDAP server is OU=test,OU=autotest,DC=autotest,DC=com, the user will be synchronized to the user group OU=autotest,DC=autotest,DC=com based on the formula. If the DN of an OU is OU=autotest,DC=autotest,DC=com, synchronized extended users belong to the autotest user group on iMaster NCE-Campus. |
|
Certificate revocation list mapping |
CRL type |
Object on the AD/LDAP server to be mapped to the CRL type on iMaster NCE-Campus. |
CRL |
CRLs to be mapped from the AD/LDAP server to iMaster NCE-Campus. |
|
Synchronizing Default Account Attributes |
Available login mode |
Authentication mode used by synchronized accounts for login. |
Use only mobile certificates for authentication |
Whether to enable user authentication only through the EAP-TLS protocol. If a user uses an authentication protocol other than EAP-TLS, the user fails to be authenticated. This function can be enabled only when Available login mode is set to 802.1X. |
|
Overwrite the configuration modified by the administrator |
Whether administrators can modify synchronized accounts. If this function is enabled, when administrators modify synchronized accounts and then perform a synchronization again, the synchronized accounts overwrite the administrator configurations. |
|
Parameter |
Description |
|---|---|
Name |
Name of the profile that defines the data synchronization scope. |
Destination User Group |
Target user group for data synchronization. |
User groups have been synchronized |
If this function is enabled, user groups have been synchronized to the system. In this case, you only need to synchronize users. In addition, the parameters Source OU/group storage directory and Source root node cannot be set when this function is enabled. |
Source OU/group storage directory |
Directory for storing OUs/groups to be synchronized on the AD/LDAP server. |
Source root node |
Root node of the data to be synchronized. |
Source user storage directory |
Directory for storing the data synchronized to AD server. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Synchronization by Group for the AD Server (Organization Structure Is Described by OU)
Mode 2 is recommended when users and user groups are stored separately on the AD server, while the enterprise organization structure is described by OUs.
Application Scenarios
The AD server uses OUs to indicate organization units. The OU structure on the AD server is different from the enterprise organization structure, and accounts are not stored under the OUs to which they belong. For example, OUs are stored in OU=Dept, and users are stored in OU=User.
For example, Figure 5-43 shows the organization structure of an enterprise and Figure 5-44 shows the storage structure of OUs and users on the AD server.
Preparing for Synchronization
If OUs and users are stored on the AD server in this way, you need to complete the following operations on the AD server before synchronization to achieve the following purposes:
- OUs are stored based on the enterprise organization structure.
- Relationships between users and OUs are established by groups.
- Create OUs in a tree structure based on the enterprise organization structure. No data is stored in the OUs.
![]()
- Create groups in each OU that stores users and is to be synchronized to iMaster NCE-Campus.
![]()
- Add users in OUs to groups based on the enterprise organization structure. As shown in Figure 5-43, Iris belongs to Human Resource Dept.
![]()
![]()
Procedure
- (Optional) Create a user group to which OUs and user accounts on the AD server are synchronized. If no user group is created, the root node is used as the target user group.
Choose from the main menu.
Click
![]()
to create a user group.![]()
- Configure interconnection between iMaster NCE-Campus and an AD server. For details about how to obtain AD server parameters, see Table1 Obtaining AD server parameters. Choose from the main menu. After all settings are complete, if the icon before the server address is
![]()
, the server is connected to iMaster NCE-Campus successfully. If the icon is ![]()
, the server is disconnected.![]()
- Select Mode 2 (The AD is synchronized by group, and the OU describes the organizational structure.) from the Select a synchronization mode drop-down list.
![]()
- On the Configure the attributes of the user & user group page page, set the mappings between object attributes on the AD server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
In this step, attribute mappings are configured for user groups, users, extended users, group objects, and CRLs.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- Extended users refer to non-user objects (such as PCs) on the AD server. They are synchronized to iMaster NCE-Campus as users and are generally used to verify accounts during PC certificate-based authentication.
![]()
- On the Group Object Mappings page, set mappings between user groups and objects with specific attributes.
![]()
- CRLs are used for mobile certificate authentication. Objects with certain attributes are mapped to CRLs and synchronized to iMaster NCE-Campus.
![]()
- Synchronize default account attributes.
![]()
- Configure mapping attributes for user groups and users.
- Configure the synchronization range.
Set Source OU/group storage directory and Root node to be synchronized to the OU created by the AD server administrator based on the enterprise organization structure. During the synchronization, the OUs with the same structure as the enterprise organization structure are synchronized to iMaster NCE-Campus as user groups, and then the members in each OU are synchronized to user accounts in the corresponding user group on iMaster NCE-Campus.
![]()
After the synchronization, the storage structure of user groups and users on the user management page of iMaster NCE-Campus is the same as the enterprise organization structure.
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain as the system administrator. For detail, see Configuring an AD Domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
, the server is connected to 
, the server is disconnected.
Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click , and configure the authentication component that uses the data source.
Parameter Description
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active AD server. |
Obtain the value from the AD server administrator. |
Secondary server address |
IP address of the standby AD server. |
Obtain the value from the AD server administrator. |
Authentication port |
Port used for communication between the AD server and iMaster NCE-Campus. Retain the default value. |
N/A |
AD domain name |
Domain name of an AD server. |
How Do I Obtain an AD Domain Name? |
AD short domain name |
Short domain name of the AD server. The default value is the characters before the period (.) in the AD domain name. For example, if the AD server domain name is test.com, the short domain name is test. If a short domain name is configured on the AD server, the value of this parameter must be the same as that configured on the AD server. You need to set this parameter when the username is in the format of Short domain name\Username. |
Obtain the value from the AD server administrator. |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on a subnode or the parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the AD server to iMaster NCE-Campus. |
You can obtain an existing account and password from the AD server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The Source Sockets Layer (SSL) protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the AD server. The TLS version needs to be specified if TLS is enabled, and TLS v1.2 is used by default. NOTE:
TLSv1.2 is recommended because it is more secure than TLSv1.1. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
Authentication account (SPN account)/Authentication password |
Account with the Service Principal Name (SPN) on the AD server. If the Kerberos protocol is used during AD authentication, an authentication account and password need to be entered. You are not advised to use the Kerberos protocol unless otherwise specified. |
You can obtain an existing account and password from the AD server administrator, or create an authentication account. For details, see How Do I Create an Authentication Account. |
AD server administrator configuration: Administrator account Password Port |
If an AD user who passes portal authentication needs to change the password, the AD server administrator information needs to be set on the controller. The AD server administrator rights are required when the password of an AD user needs to be changed. The SSL protocol is used when an AD user changes the password. Therefore, you must upload the AD server root certificate on iMaster NCE-Campus. |
You can obtain a username and password from the AD server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Group object mapping |
Group object |
Group object of the CRL corresponding to users on the AD server in the mobile certificate authentication scenario. |
Group name |
Name of the group of the CRL of corresponding to users on the AD server in the mobile certificate authentication scenario. |
|
Parameter |
Description |
|---|---|
Name |
Name of the profile that defines the data synchronization scope. |
Destination User Group |
Target user group for data synchronization. |
User groups have been synchronized |
If this function is enabled, user groups have been synchronized to the system. In this case, you only need to synchronize users. In addition, the parameters Source OU/group storage directory and Source root node cannot be set when this function is enabled. |
Source OU/group storage directory |
Directory for storing OUs/groups to be synchronized on the AD/LDAP server. |
Source root node |
Root node of the data to be synchronized. |
Source user storage directory |
Directory for storing the data synchronized to AD server. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Synchronization by Group for the AD Server (Organization Structure Is Described by Group)
Mode 3 is recommended when users and user groups are stored separately on the AD server, while the enterprise organization structure is described by groups.
Application Scenarios
Both organization units and users are stored on the AD server as groups in a flattened structure. Organization units are stored in one OU, and users are stored in another OU.
Groups cannot store data in a tree structure; so attributes are used to determine the relationships between groups. For example, the member attribute identifies a sub-group or user, and the memberOf attribute identifies a parent group.
Attributes can also determine the group to which a user belongs. For example, the memberOf attribute identifies the group to which a user belongs.
For example, Figure 5-45 shows the organization structure of an enterprise and Figure 5-46 shows the storage structure of groups and users on the AD server.
Procedure
- (Optional) Create a user group to which OUs and user accounts on the AD server are synchronized. If no user group is created, the root node is used as the target user group.
Choose from the main menu.
Click
![]()
to create a user group.![]()
- Configure interconnection between iMaster NCE-Campus and an AD server. For details about how to obtain AD server parameters, see Table1 Obtaining AD server parameters. Choose from the main menu. After all settings are complete, if the icon before the server address is
![]()
, the server is connected to iMaster NCE-Campus successfully. If the icon is ![]()
, the server is disconnected.![]()
- Select Mode 3 (The AD is synchronized by group, and the group describes the organizational structure.) from the Select a synchronization mode drop-down list.
![]()
- On the Configure the attributes of the user & user group page page, set the mappings between object attributes on the AD server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
In this step, attribute mappings are configured for user groups, users, extended users, and CRLs. In addition, default account attributes are synchronized from the AD server.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- Extended users refer to non-user objects (such as PCs) on the AD server. They are synchronized to iMaster NCE-Campus as users and are used to verify accounts in computer certificate authentication scenarios.
![]()
- On the Group Object Mappings page, set mappings between user groups and objects with specific attributes.
![]()
- CRLs are used for mobile certificate authentication. Objects with certain attributes are mapped to CRLs and synchronized to iMaster NCE-Campus.
![]()
- Synchronize default account attributes.
![]()
- Configure mapping attributes for user groups and users.
- Configure the synchronization range.
Set Source OU/group storage directory to the OU created by the AD server administrator based on the enterprise organization structure, Set Root node to be synchronized to the group created by the AD server administrator based on the enterprise organization structure. During the synchronization, the OUs with the same structure as the enterprise organization structure are synchronized to iMaster NCE-Campus as user groups, and then the members in each OU are synchronized to user accounts in the corresponding user group on iMaster NCE-Campus.
![]()
After the synchronization, the storage structure of user groups and users on the user management page of iMaster NCE-Campus is the same as the enterprise organization structure.
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain as the system administrator. For detail, see Configuring an AD Domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click , and configure the authentication component that uses the data source.
Parameter Description
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active AD server. |
Obtain the value from the AD server administrator. |
Secondary server address |
IP address of the standby AD server. |
Obtain the value from the AD server administrator. |
Authentication port |
Port used for communication between the AD server and iMaster NCE-Campus. Retain the default value. |
N/A |
AD domain name |
Domain name of an AD server. |
How Do I Obtain an AD Domain Name? |
AD short domain name |
Short domain name of the AD server. The default value is the characters before the period (.) in the AD domain name. For example, if the AD server domain name is test.com, the short domain name is test. If a short domain name is configured on the AD server, the value of this parameter must be the same as that configured on the AD server. You need to set this parameter when the username is in the format of Short domain name\Username. |
Obtain the value from the AD server administrator. |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on a subnode or the parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the AD server to iMaster NCE-Campus. |
You can obtain an existing account and password from the AD server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The Source Sockets Layer (SSL) protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the AD server. The TLS version needs to be specified if TLS is enabled, and TLS v1.2 is used by default. NOTE:
TLSv1.2 is recommended because it is more secure than TLSv1.1. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
Authentication account (SPN account)/Authentication password |
Account with the Service Principal Name (SPN) on the AD server. If the Kerberos protocol is used during AD authentication, an authentication account and password need to be entered. You are not advised to use the Kerberos protocol unless otherwise specified. |
You can obtain an existing account and password from the AD server administrator, or create an authentication account. For details, see How Do I Create an Authentication Account. |
AD server administrator configuration: Administrator account Password Port |
If an AD user who passes portal authentication needs to change the password, the AD server administrator information needs to be set on the controller. The AD server administrator rights are required when the password of an AD user needs to be changed. The SSL protocol is used when an AD user changes the password. Therefore, you must upload the AD server root certificate on iMaster NCE-Campus. |
You can obtain a username and password from the AD server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Group object mapping |
Group object |
Group object of the CRL corresponding to users on the AD server in the mobile certificate authentication scenario. |
Group name |
Name of the group of the CRL of corresponding to users on the AD server in the mobile certificate authentication scenario. |
|
Parameter |
Description |
|---|---|
Name |
Name of the profile that defines the data synchronization scope. |
Destination User Group |
Target user group for data synchronization. |
User groups have been synchronized |
If this function is enabled, user groups have been synchronized to the system. In this case, you only need to synchronize users. In addition, the parameters Source OU/group storage directory and Source root node cannot be set when this function is enabled. |
Source OU/group storage directory |
Directory for storing OUs/groups to be synchronized on the AD/LDAP server. |
Source root node |
Root node of the data to be synchronized. |
Source user storage directory |
Directory for storing the data synchronized to AD server. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Synchronization by Group for the LDAP Server
Mode 4 is recommended when users and user groups are stored separately on the LDAP server.
Application Scenarios
The LDAP server stores data by OUs/groups based on the enterprise organization structure, or data is not stored based on the enterprise organization structure, but the relationships can be determined by attributes.
Users are not stored in the OU/group to which they belong, but the relationships between users and the OU/group are determined by attributes.
For example, Figure 5-47 shows the organization structure of an enterprise and Figure 5-48/Figure 5-49 shows the storage structure of OUs/groups and users on the LDAP server.
Procedure
- (Optional) Create a user group to which OUs and user accounts on the LDAP server are synchronized. If no user group is created, the root node is used as the target user group.
Choose from the main menu.
Click
![]()
to create a user group.![]()
- Configure interconnection between iMaster NCE-Campus and an LDAP server. For details about how to obtain LDAP server parameters, see Table1 Obtaining LDAP server parameters. Choose from the main menu. After all settings are complete, if the icon before the server address is
![]()
, the server is connected to iMaster NCE-Campus successfully. If the icon is ![]()
, the server is disconnected.![]()
- Select Mode 4 (LDAP synchronization by group) from the Select a synchronization mode drop-down list.
![]()
If the Parent group ID (such as the dn value) of group A is the same as the value of group B Parent group calculation formula, group A is the parent group of group B.
The calculation formula is SUBSTRING("dn", ",", 1, "START"), indicating that the first attribute is removed to obtain the parent group ID. For example, if the DN of group B is ou=Testing Dept,ou=R&D Dept,ou=Dept,ou=Company,dc=solo,dc=local, its parent group DN is ou=R&D Dept,ou=Dept,ou=Company,dc=solo,dc=local according to this formula. If the DN of group A is ou=R&D Dept,ou=Dept,ou=Company,dc=solo,dc=local, group A is the parent group of group B.
If User group ID (such as the sn attribute) of user C is the same as the ID of group B calculated using the User group calculation formula such as EQUAL("dn"), user C belongs to group B.
The calculation formula is EQUAL("dn"), indicating that iMaster NCE-Campus compares the group DN with the User group ID to determine the group to which a user belongs.
- On the Configure the attributes of the user & user group page page, set the mappings between object attributes on the LDAP server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
In this step, attribute mappings are configured for user groups, users, extended users, and CRLs. In addition, default account attributes are synchronized from the AD server.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- Extended users refer to non-user objects (such as PCs) on the LDAP server. They are synchronized to iMaster NCE-Campus as users and are used to verify accounts in computer certificate authentication scenarios.
![]()
- On the Group Object Mappings page, set mappings between user groups and objects with specific attributes.
![]()
- CRLs are used for mobile certificate authentication. Objects with certain attributes are mapped to CRLs and synchronized to iMaster NCE-Campus.
![]()
- Synchronize default account attributes.
![]()
- Configure mapping attributes for user groups and users.
- Configure the synchronization range.
Set Source OU/group storage directory and Root node to be synchronized to the OU created by the AD server administrator based on the enterprise organization structure. During the synchronization, the OUs with the same structure as the enterprise organization structure are synchronized to iMaster NCE-Campus as user groups, and then the members in each OU are synchronized to user accounts in the corresponding user group on iMaster NCE-Campus.
![]()
After the synchronization, the storage structure of user groups and users on the user management page of iMaster NCE-Campus is the same as the enterprise organization structure.
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during RADIUS authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
to create a user group.
, the server is connected to 
, the server is disconnected.
to synchronize user groups and accounts immediately.Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click , and configure the authentication component that uses the data source.
Parameter Description
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active LDAP server. |
Obtain the value from the LDAP server administrator. |
Secondary server address |
IP address of the standby LADP server. |
Obtain the value from the LDAP server administrator. |
Authentication port |
Port used for communication between the LDAP server and iMaster NCE-Campus. Retain the default value. |
N/A |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on the subnode or parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the LDAP server to iMaster NCE-Campus. |
You can obtain an existing account and password from the LDAP server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The SSL protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the LDAP server. Common LDAP servers and JIT Galaxy server do not support SSL, and have security risks. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
MSCHAPv2 authentication |
Only the LDAP server that stores passwords in plaintext or hexadecimal format after MD4 encryption supports EAP-PEAP-MSCHAPv2. This parameter must be the same as that for user password encryption configured on an LDAP server. Otherwise, user authentication fails. Password mapping field: The attribute (for example, userPassword of the person object) of a user object on the LDAP server is mapped to a system password. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Add domain name suffix |
Domain name suffix added to synchronized accounts. |
N/A |
Authentication password encryption |
Encryption for authentication passwords. This function is supported in PortalServer authentication, AuthServer authentication, RadiusServer authentication (PAP protocol, EAP-PEAP-GTC protocol, and EAP-TTLS-PAP protocol). If password encryption has been configured on a remote server, enable and configure password encryption. The following modes are supported: encryption, key, and encoding. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Group object mapping |
Group object |
Group object of the CRL corresponding to users on the AD server in the mobile certificate authentication scenario. |
Group name |
Name of the group of the CRL of corresponding to users on the AD server in the mobile certificate authentication scenario. |
|
Parameter |
Description |
|---|---|
Name |
Name of the profile that defines the data synchronization scope. |
Destination User Group |
Target user group for data synchronization. |
User groups have been synchronized |
If this function is enabled, user groups have been synchronized to the system. In this case, you only need to synchronize users. In addition, the parameters Source OU/group storage directory and Source root node cannot be set when this function is enabled. |
Source OU/group storage directory |
Directory for storing OUs/groups to be synchronized on the AD/LDAP server. |
Source root node |
Root node of the data to be synchronized. |
Source user storage directory |
Directory for storing the data synchronized to AD server. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Synchronization by Plane Structure or User-defined Synchronization
Mode 5 is recommended when OUs and users are stored on the AD/LDAP server in a flattened structure in an unordered state.
Application Scenarios
This mode applies to scenarios where OUs and users are stored disorderly in a flat structure on the AD/LDAP server. Each OU has one attribute as the only identifier and another attribute to identify its upper-level OU. Each user has an attribute to identify the OU that the user belongs to. During the synchronization, you need to confirm the OU hierarchy based on IDs of upper-level OUs, and add users to corresponding OUs based on IDs of the OUs that the users belong to.
The difference between synchronization by plane structure and user-defined synchronization is as follows: the synchronization by plane structure provides a default mapping formula but the user-defined synchronization requires that the iMaster NCE-Campus administrator works together with the AD/LDAP server administrator to set a mapping formula.
For example, Figure 5-50 shows the organization structure of an enterprise and Figure 5-51 shows the storage structure of OUs and users on the AD server.
Although OUs and users are stored disorderly on the AD server, you can specify attributes to determine the parent-child relationship between OUs and the OU to which a user belongs.
For example, as shown in Figure 5-52, the OU has the l attribute as the unique identifier, and the st attribute identifies its parent OU. The sn attribute identifies the OU to which the user belongs.
Procedure
- (Optional) Create a user group to which OUs and user accounts on the AD server are synchronized. If no user group is created, the root node is used as the target user group.
Choose from the main menu.
Click
![]()
to create a user group.![]()
- Configure interconnection between iMaster NCE-Campus and an AD/LDAP server. For details about how to obtain AD or LDAP server parameters, see Table1 Obtaining AD server parameters or Table2 Obtaining LDAP server parameters. Choose from the main menu. After all settings are complete, if the icon before the server address is
![]()
, the server is connected to iMaster NCE-Campus successfully. If the icon is ![]()
, the server is disconnected.![]()
- Select Mode 5 (plane isolation synchronization) from the Select a synchronization mode drop-down list.
![]()
- On the Configure the attributes of the user & user group page page, set the mappings between object attributes on the AD server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
In this step, attribute mappings are configured for user groups, users, extended users, group objects, and CRLs.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- Extended users refer to non-user objects (such as PCs) on the AD server. They are synchronized to iMaster NCE-Campus as users and are generally used to verify accounts during PC certificate-based authentication.
![]()
- On the Group Object Mappings page, set mappings between user groups and objects with specific attributes.
![]()
- CRLs are used for mobile certificate authentication. Objects with certain attributes are mapped to CRLs and synchronized to iMaster NCE-Campus.
![]()
- Synchronize default account attributes.
![]()
- Configure mapping attributes for user groups and users.
- Configure the synchronization range.
Set Source OU/group storage directory and Root node to be synchronized to the OU created by the AD server administrator based on the enterprise organization structure. During the synchronization, the OUs with the same structure as the enterprise organization structure are synchronized to iMaster NCE-Campus as user groups, and then the members in each OU are synchronized to user accounts in the corresponding user group on iMaster NCE-Campus.
![]()
After the synchronization, the storage structure of user groups and users on the user management page of iMaster NCE-Campus is the same as the enterprise organization structure.
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain as the system administrator. For detail, see Configuring an AD Domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click , and configure the authentication component that uses the data source.
Parameter Description
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active AD server. |
Obtain the value from the AD server administrator. |
Secondary server address |
IP address of the standby AD server. |
Obtain the value from the AD server administrator. |
Authentication port |
Port used for communication between the AD server and iMaster NCE-Campus. Retain the default value. |
N/A |
AD domain name |
Domain name of an AD server. |
How Do I Obtain an AD Domain Name? |
AD short domain name |
Short domain name of the AD server. The default value is the characters before the period (.) in the AD domain name. For example, if the AD server domain name is test.com, the short domain name is test. If a short domain name is configured on the AD server, the value of this parameter must be the same as that configured on the AD server. You need to set this parameter when the username is in the format of Short domain name\Username. |
Obtain the value from the AD server administrator. |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on a subnode or the parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the AD server to iMaster NCE-Campus. |
You can obtain an existing account and password from the AD server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The Source Sockets Layer (SSL) protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the AD server. The TLS version needs to be specified if TLS is enabled, and TLS v1.2 is used by default. NOTE:
TLSv1.2 is recommended because it is more secure than TLSv1.1. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
Authentication account (SPN account)/Authentication password |
Account with the Service Principal Name (SPN) on the AD server. If the Kerberos protocol is used during AD authentication, an authentication account and password need to be entered. You are not advised to use the Kerberos protocol unless otherwise specified. |
You can obtain an existing account and password from the AD server administrator, or create an authentication account. For details, see How Do I Create an Authentication Account. |
AD server administrator configuration: Administrator account Password Port |
If an AD user who passes portal authentication needs to change the password, the AD server administrator information needs to be set on the controller. The AD server administrator rights are required when the password of an AD user needs to be changed. The SSL protocol is used when an AD user changes the password. Therefore, you must upload the AD server root certificate on iMaster NCE-Campus. |
You can obtain a username and password from the AD server administrator. |
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active LDAP server. |
Obtain the value from the LDAP server administrator. |
Secondary server address |
IP address of the standby LADP server. |
Obtain the value from the LDAP server administrator. |
Authentication port |
Port used for communication between the LDAP server and iMaster NCE-Campus. Retain the default value. |
N/A |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on the subnode or parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the LDAP server to iMaster NCE-Campus. |
You can obtain an existing account and password from the LDAP server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The SSL protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the LDAP server. Common LDAP servers and JIT Galaxy server do not support SSL, and have security risks. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
MSCHAPv2 authentication |
Only the LDAP server that stores passwords in plaintext or hexadecimal format after MD4 encryption supports EAP-PEAP-MSCHAPv2. This parameter must be the same as that for user password encryption configured on an LDAP server. Otherwise, user authentication fails. Password mapping field: The attribute (for example, userPassword of the person object) of a user object on the LDAP server is mapped to a system password. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Add domain name suffix |
Domain name suffix added to synchronized accounts. |
N/A |
Authentication password encryption |
Encryption for authentication passwords. This function is supported in PortalServer authentication, AuthServer authentication, RadiusServer authentication (PAP protocol, EAP-PEAP-GTC protocol, and EAP-TTLS-PAP protocol). If password encryption has been configured on a remote server, enable and configure password encryption. The following modes are supported: encryption, key, and encoding. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Group object mapping |
Group object |
Group object of the CRL corresponding to users on the AD server in the mobile certificate authentication scenario. |
Group name |
Name of the group of the CRL of corresponding to users on the AD server in the mobile certificate authentication scenario. |
|
Parameter |
Description |
|---|---|
Name |
Name of the profile that defines the data synchronization scope. |
Destination User Group |
Target user group for data synchronization. |
User groups have been synchronized |
If this function is enabled, user groups have been synchronized to the system. In this case, you only need to synchronize users. In addition, the parameters Source OU/group storage directory and Source root node cannot be set when this function is enabled. |
Source OU/group storage directory |
Directory for storing OUs/groups to be synchronized on the AD/LDAP server. |
Source root node |
Root node of the data to be synchronized. |
Source user storage directory |
Directory for storing the data synchronized to AD server. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Synchronization by Conditions
This mode applies when you want to synchronize accounts meeting specified conditions only. In this mode, only user accounts are synchronized and user groups are not synchronized.
Application Scenarios
This mode applies to scenarios where accounts are stored in a disorderly manner on the AD/LDAP server, and the OUs that these accounts belong to are identified by a specific attribute of the accounts. The data type of the attribute must be a directory string.
In this mode, only accounts are synchronized. You need to create or import user groups on iMaster NCE-Campus based on the organization structure of an enterprise to function as target user groups for account synchronization. When an account is synchronized to iMaster NCE-Campus, you need to confirm the target user group of this account based on the attribute value of the OU that the account belongs to. Only accounts meeting conditions are synchronized to iMaster NCE-Campus.
Procedure
- Specify an attribute of a user to identify the OU or group that the user belongs to. The following takes the cn attribute as an example. You can use Apache Directory Studio to check whether the cn attribute is a directory string. iMaster NCE-Campus only supports synchronization of attributes in the directory string format by conditions.
![]()
- (Optional) Create a user group to which OUs and user accounts on the AD server are synchronized. If no user group is created, the root node is used as the target user group.
Choose from the main menu.
Click
![]()
to create a user group.![]()
- Configure interconnection between iMaster NCE-Campus and an AD/LDAP server. For details about how to obtain AD or LDAP server parameters, see Table1 Obtaining AD server parameters or Table2 Obtaining LDAP server parameters. Choose from the main menu. After all settings are complete, if the icon before the server address is
![]()
, the server is connected to iMaster NCE-Campus successfully. If the icon is ![]()
, the server is disconnected.![]()
- Select Condition-based synchronization from the Select a synchronization mode drop-down list.
![]()
- On the Configure the attributes of the user & user group page page, set the mappings between object attributes on the AD server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
In this step, attribute mappings are configured for user groups, users, extended users, group objects, and CRLs.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- Extended users refer to non-user objects (such as PCs) on the AD server. They are synchronized to iMaster NCE-Campus as users and are generally used to verify accounts during PC certificate-based authentication.
![]()
- On the Group Object Mappings page, set mappings between user groups and objects with specific attributes.
![]()
- CRLs are used for mobile certificate authentication. Objects with certain attributes are mapped to CRLs and synchronized to iMaster NCE-Campus.
![]()
- Synchronize default account attributes.
![]()
- Configure mapping attributes for user groups and users.
- Set filter conditions on the Add Sync Scope tab page to synchronize users who match filter conditions to the target user group.
For example, you can synchronize users the cn attribute value of which is Andy to the target user group ROOT. You can also set OU and Group to specify a source OU or group for synchronizing users. If OU and Group are not set, users who match the filter conditions in the base DN are synchronized.
![]()
Click Add to add a filter condition.
![]()
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain as the system administrator. For detail, see Configuring an AD Domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click , and configure the authentication component that uses the data source.
Parameter Description
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active AD server. |
Obtain the value from the AD server administrator. |
Secondary server address |
IP address of the standby AD server. |
Obtain the value from the AD server administrator. |
Authentication port |
Port used for communication between the AD server and iMaster NCE-Campus. Retain the default value. |
N/A |
AD domain name |
Domain name of an AD server. |
How Do I Obtain an AD Domain Name? |
AD short domain name |
Short domain name of the AD server. The default value is the characters before the period (.) in the AD domain name. For example, if the AD server domain name is test.com, the short domain name is test. If a short domain name is configured on the AD server, the value of this parameter must be the same as that configured on the AD server. You need to set this parameter when the username is in the format of Short domain name\Username. |
Obtain the value from the AD server administrator. |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on a subnode or the parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the AD server to iMaster NCE-Campus. |
You can obtain an existing account and password from the AD server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The Source Sockets Layer (SSL) protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the AD server. The TLS version needs to be specified if TLS is enabled, and TLS v1.2 is used by default. NOTE:
TLSv1.2 is recommended because it is more secure than TLSv1.1. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
Authentication account (SPN account)/Authentication password |
Account with the Service Principal Name (SPN) on the AD server. If the Kerberos protocol is used during AD authentication, an authentication account and password need to be entered. You are not advised to use the Kerberos protocol unless otherwise specified. |
You can obtain an existing account and password from the AD server administrator, or create an authentication account. For details, see How Do I Create an Authentication Account. |
AD server administrator configuration: Administrator account Password Port |
If an AD user who passes portal authentication needs to change the password, the AD server administrator information needs to be set on the controller. The AD server administrator rights are required when the password of an AD user needs to be changed. The SSL protocol is used when an AD user changes the password. Therefore, you must upload the AD server root certificate on iMaster NCE-Campus. |
You can obtain a username and password from the AD server administrator. |
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active LDAP server. |
Obtain the value from the LDAP server administrator. |
Secondary server address |
IP address of the standby LADP server. |
Obtain the value from the LDAP server administrator. |
Authentication port |
Port used for communication between the LDAP server and iMaster NCE-Campus. Retain the default value. |
N/A |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on the subnode or parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the LDAP server to iMaster NCE-Campus. |
You can obtain an existing account and password from the LDAP server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The SSL protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the LDAP server. Common LDAP servers and JIT Galaxy server do not support SSL, and have security risks. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
MSCHAPv2 authentication |
Only the LDAP server that stores passwords in plaintext or hexadecimal format after MD4 encryption supports EAP-PEAP-MSCHAPv2. This parameter must be the same as that for user password encryption configured on an LDAP server. Otherwise, user authentication fails. Password mapping field: The attribute (for example, userPassword of the person object) of a user object on the LDAP server is mapped to a system password. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Add domain name suffix |
Domain name suffix added to synchronized accounts. |
N/A |
Authentication password encryption |
Encryption for authentication passwords. This function is supported in PortalServer authentication, AuthServer authentication, RadiusServer authentication (PAP protocol, EAP-PEAP-GTC protocol, and EAP-TTLS-PAP protocol). If password encryption has been configured on a remote server, enable and configure password encryption. The following modes are supported: encryption, key, and encoding. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Group object mapping |
Group object |
Group object of the CRL corresponding to users on the AD server in the mobile certificate authentication scenario. |
Group name |
Name of the group of the CRL of corresponding to users on the AD server in the mobile certificate authentication scenario. |
|
Parameter |
Description |
|---|---|
Name |
Name of the profile that defines the data synchronization scope. |
Target User Group |
Target user group for data synchronization. |
The OU/ group can be manually entered |
Whether to manually enter the OU and group to which the data to be synchronized belongs. |
OU |
OU to which the data to be synchronized belongs. |
Group |
Group to which the data to be synchronized belongs. |
Filter Condition |
Filter conditions for synchronizing user data, including Attribute, Relationship, and Value. You can click Add to define more filter conditions. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Configuring Non-Synchronization
Application Scenarios
If an enterprise has high security requirements, iMaster NCE-Campus can directly send accounts and passwords to an AD/LDAP server for authentication. The accounts and organization structure on the AD/LDAP server do not need to be synchronized to iMaster NCE-Campus.
When using a third-party AD/LDAP server for data synchronization, ensure that the third-party server, account policies, and password complexity meet the default security requirements and the anti-brute force cracking and anti-DoS mechanisms are complete.
Configuring Non-Synchronization
- Create a user group as the target user group to which the data of the AD/LDAP server is mapped. Alternatively, map all accounts to the root user group if you do not create a user group.
Choose from the main menu, and click
![]()
to create a user group.![]()
- Set parameters for connection with the AD/LDAP server. For details about how to obtain AD/LDAP parameter settings, see Table 5-282.
Choose from the main menu, and set parameters.
![]()
- Select Unsynchronized account/organization structure from the Select a synchronization mode drop-down list.
![]()
- On the Configure the attributes of the user & user group page, set the mappings between object attributes on the AD server and attributes on iMaster NCE-Campus.
![]()
You are advised to retain the default values.
This step defines mapping attributes for users groups and users, account expiration time, and mappings between user groups and objects with specific attributes.
- Configure mapping attributes for user groups and users.
![]()
After the configuration of the interconnected server is deleted, the synchronized users and user groups will be deleted from iMaster NCE-Campus. Therefore, do not manually create user or user groups under the synchronized user groups. Otherwise, data may be deleted by mistake.
![]()
![]()
- The expiration time is a customized field on the AD or LDAP server. After the expiration time is enabled, iMaster NCE-Campus determines whether to synchronize expired users based on configuration during user synchronization and verifies the customized expiration time during user authentication.
![]()
- On the Group Object Mappings page, set mappings between user groups and objects with specific attributes.
![]()
- Configure mapping attributes for user groups and users.
- Click Next. On the external group configuration page, click Add and select user groups on the AD/LDAP server.
![]()
- (Optional) Configure an account filtering rule. Based on the account filtering rule, desired user accounts can be synchronized from an external data source to iMaster NCE-Campus.
![]()
- (Optional) Define mappings between user accounts and user roles.
Define mappings between user accounts and user roles. Users accounts will be attached to desired roles if they meet specific conditions, and can be managed by user role.
A user on the AD server belongs to multiple OUs. However, a user account on iMaster NCE-Campus can belong to only one user group. In this case, an account will be mapped to multiple roles.
If user data is obtained from the AD/LDAP server and the administrator wants to manage user accounts by user role, configure mappings between user accounts and user roles so that accounts that meet specific conditions will be attached to desired user roles.
If user accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus, user accounts will be attached to roles during synchronization based on role mapping rules. If user accounts are not synchronized from the AD/LDAP server, they will be attached to roles during authentication based on role mapping rules.
Administrators can change the user roles attached to the user accounts synchronized to iMaster NCE-Campus. The manually configured user roles take precedence over those automatically assigned.
![]()
- (Optional) Synchronize user groups. Select an AD data source in the list and click Synchronize User Group in the upper right corner to synchronize only user groups but not accounts.
- (Optional) Click
![]()
to synchronize user groups and accounts immediately. - (Optional) Add iMaster NCE-Campus to an AD domain as the system administrator. For detail, see Configuring an AD Domain.
If AD domain accounts are required for 802.1X authentication with MSCHAPV2, you need to add iMaster NCE-Campus to an AD domain. In other cases, skip this step. By default, the built-in Windows 802.1X client and EasyAccess use MSCHAPV2.
- Configure authentication using an AD/LDAP server as a third-party data source. If 802.1X or portal authentication is set, select an AD/LDAP server as the authentication data source when configuring authentication rules.
to create a user group.
Related Operations
Configuring an authentication component
Select the AD/LDAP server to be configured, click , and configure the authentication component that uses the data source.
Parameters
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active AD server. |
Obtain the value from the AD server administrator. |
Secondary server address |
IP address of the standby AD server. |
Obtain the value from the AD server administrator. |
Authentication port |
Port used for communication between the AD server and iMaster NCE-Campus. Retain the default value. |
N/A |
AD domain name |
Domain name of an AD server. |
How Do I Obtain an AD Domain Name? |
AD short domain name |
Short domain name of the AD server. The default value is the characters before the period (.) in the AD domain name. For example, if the AD server domain name is test.com, the short domain name is test. If a short domain name is configured on the AD server, the value of this parameter must be the same as that configured on the AD server. You need to set this parameter when the username is in the format of Short domain name\Username. |
Obtain the value from the AD server administrator. |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on a subnode or the parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the AD server to iMaster NCE-Campus. |
You can obtain an existing account and password from the AD server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The Source Sockets Layer (SSL) protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the AD server. The TLS version needs to be specified if TLS is enabled, and TLS v1.2 is used by default. NOTE:
TLSv1.2 is recommended because it is more secure than TLSv1.1. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
Authentication account (SPN account)/Authentication password |
Account with the Service Principal Name (SPN) on the AD server. If the Kerberos protocol is used during AD authentication, an authentication account and password need to be entered. You are not advised to use the Kerberos protocol unless otherwise specified. |
You can obtain an existing account and password from the AD server administrator, or create an authentication account. For details, see How Do I Create an Authentication Account. |
AD server administrator configuration: Administrator account Password Port |
If an AD user who passes portal authentication needs to change the password, the AD server administrator information needs to be set on the controller. The AD server administrator rights are required when the password of an AD user needs to be changed. The SSL protocol is used when an AD user changes the password. Therefore, you must upload the AD server root certificate on iMaster NCE-Campus. |
You can obtain a username and password from the AD server administrator. |
Parameter |
Description |
Obtaining Method |
|---|---|---|
Data source name |
Name of an external authentication source. |
N/A |
Primary server address |
IP address of the active LDAP server. |
Obtain the value from the LDAP server administrator. |
Secondary server address |
IP address of the standby LADP server. |
Obtain the value from the LDAP server administrator. |
Authentication port |
Port used for communication between the LDAP server and iMaster NCE-Campus. Retain the default value. |
N/A |
Base DN |
DN of the root node. If the base DN is a subnode but not the root node, you need to create synchronization and authentication accounts on the base DN node. Creating these accounts on the subnode or parent node of the base DN node may result in synchronization failures due to incorrect permissions. |
How Do I Obtain the Base DN? |
Synchronize accounts/Synchronize password |
Account and password used to synchronize OUs, groups and users from the LDAP server to iMaster NCE-Campus. |
You can obtain an existing account and password from the LDAP server administrator, or create an account to perform synchronization. For details, see How Do I Create an Account to Perform Synchronization. |
TLS |
The SSL protocol is recommended to encrypt data exchanged between the AD server and iMaster NCE-Campus, depending on whether SSL is enabled on the LDAP server. Common LDAP servers and JIT Galaxy server do not support SSL, and have security risks. |
After SSL is enabled, the port number is 636. You can run the telnet AD/LDAP_IP 636 command to check whether SSL has been enabled. If Could not open connection to the host, on port 636: Connect failed is displayed, SSL is not enabled. |
Certificate verification |
Whether to verify certificates. If this function is enabled, you need to upload certificates on the page. |
Certificate Management |
Bypass |
Bypass access. If a network fault occurs, users can access specific resources using this function. |
N/A |
MSCHAPv2 authentication |
Only the LDAP server that stores passwords in plaintext or hexadecimal format after MD4 encryption supports EAP-PEAP-MSCHAPv2. This parameter must be the same as that for user password encryption configured on an LDAP server. Otherwise, user authentication fails. Password mapping field: The attribute (for example, userPassword of the person object) of a user object on the LDAP server is mapped to a system password. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Add domain name suffix |
Domain name suffix added to synchronized accounts. |
N/A |
Authentication password encryption |
Encryption for authentication passwords. This function is supported in PortalServer authentication, AuthServer authentication, RadiusServer authentication (PAP protocol, EAP-PEAP-GTC protocol, and EAP-TTLS-PAP protocol). If password encryption has been configured on a remote server, enable and configure password encryption. The following modes are supported: encryption, key, and encoding. NOTE:
LDAP servers support weak password encryption algorithms. You are advised to enable TLS and certificate verification. |
Obtain the value from the LDAP server administrator. |
Parameter |
Description |
|---|---|
Fast synchronization |
This mode applies when accounts are synchronized from the AD/LDAP server to iMaster NCE-Campus. If the account to be authenticated does not exist on iMaster NCE-Campus but exists on the AD/LDAP server, iMaster NCE-Campus synchronizes the account from the AD/LDAP server and authenticates the account again. |
Periodic synchronization |
Synchronization period. Currently, data can be synchronized once a day. You can set the start time of data synchronization as needed. |
Periodic user synchronization |
Whether to enable iMaster NCE-Campus to periodically synchronize users from the AD/LDAP server. If this function is enabled, only users on the AD/LDAP server are synchronized to iMaster NCE-Campus periodically. If this function is disabled, only user groups on the AD/LDAP server are synchronized. |
Parameter |
Description |
|
|---|---|---|
User group attribute mapping |
User group object |
Object on the AD/LDAP server to be mapped to a user group on iMaster NCE-Campus, for example, organizationalUnit. |
User group name |
Object on the AD/LDAP server to be mapped to a user group name on iMaster NCE-Campus, for example, name of an organizationalUnit object. |
|
Administrator mailbox |
Object on the AD/LDAP server to be mapped to an administrator email address on iMaster NCE-Campus. |
|
User group ID |
Unique ID of a user group synchronized to iMaster NCE-Campus, for example, objectGuid. The data is stored only in the database and is not displayed on the User Management page on the iMaster NCE-Campus web UI. |
|
User group description |
Description of a user group synchronized to iMaster NCE-Campus. |
|
User attribute mapping |
User object |
Object on the AD/LDAP server to be mapped to a user on iMaster NCE-Campus, for example, person. |
Username |
Object on the AD/LDAP server to be mapped to a user name on iMaster NCE-Campus, for example, cn of a person object. |
|
Account |
Object on the AD/LDAP server to be mapped to a user account on iMaster NCE-Campus, for example, AM of a person object. |
|
User group ID |
OU or group to which a user belongs after being synchronized to iMaster NCE-Campus. For example, the memberOf attribute defines the DN of the OU or group to which a user belongs. After the information is synchronized to iMaster NCE-Campus, the user is stored in the user group to which the user belongs. |
|
Title |
Object on the AD/LDAP server to be mapped to a job title on iMaster NCE-Campus. |
|
Office number |
Object on the AD/LDAP server to be mapped to an office phone number on iMaster NCE-Campus. |
|
Mobile number |
Object on the AD/LDAP server to be mapped to a mobile number on iMaster NCE-Campus. |
|
Object on the AD/LDAP server to be mapped to an email address on iMaster NCE-Campus. |
||
User description |
Description of a user synchronized to iMaster NCE-Campus. |
|
Enable the expiration time |
Expiration time |
User expiration time defined on the AD/LDAP server. |
Time type |
Expiration time type defined on the AD/LDAP server. |
|
Time character string format |
Character string format of the expiration time defined on the AD/LDAP server. Example: yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH:mm:ss, yyyy/MM/dd, yyyy-MM-dd, or dd MMMyyyy. |
|
Time string language |
Character string language defined on the AD/LDAP server. The following languages are supported: Chinese English French German Traditional Chinese |
|
Group object mapping |
Group object |
Group object of the CRL corresponding to users on the AD server in the mobile certificate authentication scenario. |
Group name |
Name of the group of the CRL of corresponding to users on the AD server in the mobile certificate authentication scenario. |
|
Parameter |
Description |
|---|---|
External group |
Data on an AD server belongs to different AD groups, and the AD groups are nested. When iMaster NCE-Campus interconnects with an AD server and the non-synchronization mode is configured, you can select an external group on the AD server as the synchronization scope. In this case, iMaster NCE-Campus can authorize users based on the external group. |
Parameter |
Description |
|---|---|
Rule Name |
Name of a role mapping rule. |
Role |
Role to which users are mapped. |
Rule Matching Mode |
Action performed if multiple filter conditions are defined in a role mapping rule:
Automatically creating a role. Match all rules. One account maps multiple roles. (supported only in mode 3) |
Current filter criteria |
Filter criteria for role mapping, including attribute, relationship, and value. |
Parameter |
Description |
|---|---|
Filter criteria |
Whether to exclude or include the specified OUs. Exclude the following OUs The following OUs are included |
OU list |
OUs to be excluded or included. |
Authentication Using a RADIUS Token Server
Context
A token is a dynamic password and a token server is used to save user accounts and dynamic passwords. A RADIUS token server can only use the RADIUS protocol to initiate authentication requests to the RADIUS server. After receiving user authentication requests, iMaster NCE-Campus matches authentication rules against the requests. If the data source specified in the authentication rules is a RADIUS token server, iMaster NCE-Campus sends user accounts and passwords to the RADIUS token server for verification. After the user accounts and passwords are verified, iMaster NCE-Campus authorizes users based on the matched authorization rules.
Authentication Process
The following describes the 802.1X authentication process as an example. Interactions between iMaster NCE-Campus and the RADIUS token server in the 802.1X authentication process and HACA authentication process are the same.
When iMaster NCE-Campus interacts with the RADIUS token server, a network problem may occur and affect terminal authentication. In this case, packets will be retransmitted if the connection between iMaster NCE-Campus and the RADIUS token server times out. That is, iMaster NCE-Campus will retransmit an authentication request packet to the RADIUS token server if the RADIUS token server does not respond to the previous authentication request within the specified period. When the number of retransmissions exceeds the limit and iMaster NCE-Campus does not receive a response, iMaster NCE-Campus considers that the RADIUS token server is unavailable. Active and standby RADIUS token servers can be configured. When the active RADIUS token server is unavailable, the standby RADIUS token server is used for authentication. Both the active and standby RADIUS token servers can support the retransmission mechanism. In addition, you can configure reconnection between iMaster NCE-Campus and the active RADIUS token server. If the active RADIUS token server is unavailable, after a specified time period, services are forcibly switched back to the active RADIUS token server.
If both the active and standby token servers are unavailable during authentication, you can set a silence period during which all authentication requests are denied.
Procedure
- Choose from the main menu and click Create to configure a RADIUS token server interconnected with iMaster NCE-Campus. After all settings are complete, click OK.
![]()
- (Optional) If portal authentication is configured, customize a portal page to be pushed to end users.
- Choose from the main menu.
- On the Page Customization tab page, click
![]()
to create a customized portal page template.![]()
- Customize a portal authentication page and an authentication success page for mobile phones and PCs. After the pages are customized, click Save and then Release.
![]()
- (Optional) If portal authentication is configured, configure a portal page pushing rule.
- Choose from the main menu.
- On the Portal Page Push Policy tab page, click Create to configure a portal page pushing rule. Select the customized portal pages, and set the portal authentication page to the first page pushed to end users. For details about other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to user access authentication, and select the wireless or wired access mode. Set the configured RADIUS token server as the data source. Configure PAP or EAP-PEAP-GTC as the authentication protocol. For details about other parameters, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to configure an authorization rule. Set the user group to the one specified in the RADIUS token server configuration. Set the authentication mode to HACA portal authentication or user access authentication, and select the wireless or wired access mode. Select the created authorization result. For details about other parameters, see Configuring an Authorization Rule.
to create a customized portal page template.
Parameter Description
Parameter |
Description |
|---|---|
Primary Server IP Address/ Secondary server IP address |
IP address of the active or standby RADIUS token server. |
Shared key |
Shared key used by iMaster NCE-Campus to communicate with the RADIUS token server. The parameter value must be the same as that configured on the RADIUS token server. |
Authentication port |
Port used by iMaster NCE-Campus to communicate with the RADIUS token server. The parameter value must be the same as that configured on the RADIUS token server. |
Timeout Interval (s) |
If iMaster NCE-Campus does not receive any response from the RADIUS token server within the timeout interval, iMaster NCE-Campus retransmits the request packet to the RADIUS token server. The value is in the range from 3 to 120, in seconds. The default value is 5. The parameter value must be the same as that configured on the RADIUS token server. NOTE:
The access device also has a timeout interval for RADIUS request packets. The timeout interval for the RADIUS token server must be smaller than that for the access device. Otherwise, the authentication process times out on iMaster NCE-Campus before packet processing is completed on the access device, causing an authentication failure. |
Resend tries |
Number of retransmission times. iMaster NCE-Campus will retransmit an authentication request packet to the RADIUS token server if the RADIUS token server does not respond to the previous authentication request within the specified period. When the number of retransmissions exceeds the limit and iMaster NCE-Campus does not receive a response, iMaster NCE-Campus considers that the RADIUS token server is unavailable. The value is in the range from 0 to 9. The default value is 2. |
Silence duration (min) |
Time period during which all authentication requests are denied if the RADIUS token server is unavailable. The value is in the range from 1 to 1440, in minutes. The default value is 5. |
Domain name in AD username |
Whether the AD account sent to the RADIUS token server carries a domain name when the RADIUS token server connects to an AD server. The parameter value must be the same as that configured on the RADIUS token server. The options are as follows:
|
User group |
User group to which user accounts on the RADIUS token server belong. |
Other parameters |
Time period after which services are forcibly switched to the active RADIUS token server. To set this parameter, select If the primary server fails, wait for a period of time and try to connect to the primary server again.. The value is in the range from 5 to 1440, in minutes. The default value is 1440. |
Authentication Using a Third-Party HTTP Server
Context
User accounts and passwords of enterprise users can be stored and maintained on a third-party HTTP server. The network administrator requires that iMaster NCE-Campus use the third-party HTTP server as an external data source so that iMaster NCE-Campus can automatically connect to the HTTP server to authenticate end users based on user accounts and passwords on the HTTP server.
To configure authentication using a third-party HTTP server, set the following parameters on iMaster NCE-Campus: HTTP server URL, HTTP request sending method, encoding format, encryption mode, test account, test password, and connection success flag. The success flag can be matched using a regular expression. The get attribute or body of the request can be customized in the URL of the HTTP server. The preceding settings on iMaster NCE-Campus must be the same as those on the third-party HTTP server.
Interconnection with a third-party HTTP server is supported for HACA authentication and Portal2.0 authentication only.
Procedure
- Choose from the main menu, switch on Authentication based on a third-party HTTP server, and configure the HTTP server interconnected with iMaster NCE-Campus.
![]()
- After all settings are complete and the test is successful, click OK.
- (Optional) If portal authentication is configured, customize a portal page to be pushed to end users.
- Choose from the main menu.
- On the Page Customization tab page, click
![]()
to create a customized portal page template.![]()
- Customize a portal authentication page and an authentication success page for mobile phones and PCs. After the pages are customized, click Save and then Release.
![]()
- (Optional) If portal authentication is configured, configure a portal page pushing rule.
- Choose from the main menu.
- On the Portal Page Push Policy tab page, click Create to configure a portal page pushing rule. Select the customized portal pages, and set the portal authentication page to the first page pushed to end users. For details about other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to user access authentication, and select the wireless or wired access mode. Select the configured third-party HTTP server as the data source. If the authentication mode is user access authentication, configure PAP as the authentication protocol. For details about other parameters, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to configure an authorization rule. Select the user group specified when configuring the third-party HTTP server as the data source. Set the authentication mode to HACA portal authentication or user access authentication, and select the wireless or wired access mode. Select the created authorization result. For details about other parameters, see Configuring an Authorization Rule.
Parameter Description
Parameter |
Description |
|---|---|
Sending Mode |
Method in which iMaster NCE-Campus sends HTTP requests. Currently, the POST and GET methods are supported. The parameter value must be the same as that configured on the HTTP server. |
Coding format |
Encoding format of the HTTP requests sent by iMaster NCE-Campus. Currently, the UTF-8 and GBK formats are supported. The parameter value must be the same as that configured on the HTTP server. |
TLS |
Whether to enable TLS. TLS1.1 and TLS1.2 are supported. NOTE:
TLS1.2 is recommended because it is more secure than TLS1.1. |
Whether to perform certificate verification |
Whether to verify certificates. To enable this function, import a security certificate on the page. |
Authentication URL |
URL of the third-party HTTP server. |
Encryption mode/Key |
Encryption mode for communication between iMaster NCE-Campus and the HTTP server. The options are None, MD5, and SHA256. When Encryption mode is set to SHA256, you need to configure a key. |
Property |
Dynamic attributes supported on iMaster NCE-Campus:
The attribute format is Attribute name=Attribute value. Multiple attributes are separated by line breaks. For example, the following attributes are required by the third-party HTTP server administrator:
You need to add the attributes as follows:
When an end user sends an authentication request, iMaster NCE-Campus automatically replaces the values in {USERNAME} and {PASSWORD}. |
Success Flag |
Connection success identifier returned by the third-party HTTP server to iMaster NCE-Campus. Regular expressions are supported. |
Test Account/Test Password |
Account and password used to test the connection between iMaster NCE-Campus and the third-party HTTP server. |
User Groups |
User group to which users authenticated by the third-party HTTP server belongs. |
Bypass |
Whether to enable bypass authentication. When this function is enabled and iMaster NCE-Campus fails to connect to the third-party HTTP server, iMaster NCE-Campus allows all HTTP accounts to pass authentication to ensure service continuity. |
Authentication Using a Third-Party Database
Context
User accounts and passwords of enterprise users can be stored and maintained on a third-party database. The network administrator requires that iMaster NCE-Campus use the third-party database as an external data source so that iMaster NCE-Campus can automatically connect to the database to authenticate end users based on user accounts and passwords.
When a third-party database is configured as a data source, the database administrator needs to provide the database connection parameter settings and structure of the account information table.
A third-party database can function as an external data source in HACA, Portal2.0, and 802.1X authentication.
Authentication Process
The following describes the Portal2.0 authentication process as an example. Interactions between iMaster NCE-Campus and the third-party database in the Portal2.0, 802.1X, HACA authentication processes are the same.
Procedure
- Choose from the main menu, switch on Enable the third-party database, and configure the third-party database interconnected with iMaster NCE-Campus.
![]()
- After all settings are complete and the test is successful, click Save.
- If you want to authorize users by role, click Configure a Role Mapping Rule and click Create. Multiple role mapping rules are matched based on the priority. A smaller priority value indicates a higher priority.
![]()
![]()
- (Optional) If portal authentication is configured, customize a portal page to be pushed to end users.
- Choose from the main menu.
- On the Page Customization tab page, click
![]()
to create a customized portal page template.![]()
- Customize a portal authentication page and an authentication success page for mobile phones and PCs. After the pages are customized, click Save and then Release.
![]()
- (Optional) If portal authentication is configured, configure a portal page pushing rule.
- Choose from the main menu.
- On the Portal Page Push Policy tab page, click Create to configure a portal page pushing rule. Select the customized portal pages, and set the portal authentication page to the first page pushed to end users. For details about other parameters, see Configuring a Portal Page Pushing Policy.
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to configure an authentication rule. Set the authentication mode to user access authentication, and select the wireless or wired access mode. Select the configured third-party database as the data source. When the authentication mode is user access authentication, set CHAP or PAP as the authentication protocol if Portal 2.0 authentication is configured, whereas set CHAP, PAP, EAP-MD5, PEAP-MSCHAPV2, EAP-PEAP-GTC, or EAP-TTLS-PAP as the authentication protocol if 802.1X authentication is configured. For details about other parameters, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to configure an authorization rule. Set the authentication mode to HACA portal authentication or user access authentication, and select the wireless or wired access mode. Select the created authorization result. For details about other parameters, see Configuring an Authorization Rule.
Parameter Description
Parameter |
Description |
|---|---|
Database type |
Type of the database that interconnected with iMaster NCE-Campus. The options are as follows:
|
Database IP address |
IP address of the database that interconnects with iMaster NCE-Campus. |
Database port |
Port used by the database to interconnect with iMaster NCE-Campus. The value range is from 1 to 65535. The default value is 1433 for MS SQL Server databases and 1521 for Oracle databases. |
Database name |
Name of the database that interconnects with iMaster NCE-Campus. |
Database account/Database password |
Database account and password that have the permission to access the account information table. |
Enable the SSL connection |
Whether to enable the SSL connection. For security purposes, you are advised to enable encrypted SSL connection. After encrypted SSL connection is enabled, iMaster NCE-Campus and the third-party database are connected in encrypted mode. NOTE:
For security purposes, you are advised to set the communication mode on the SQL Server to Force Encryption.
|
Table name |
Name of the account information table. |
Account name field |
Name of the column that lists user accounts. |
Password field |
Name of the column that lists account passwords. |
Encryption mode |
NOTE:
SHA256 and AES256 algorithms are recommended, because they are more secure than MD5, SHA1, and AES128 algorithms. For details about how to select a password encryption mode, contact database development personnel. |
Key |
For details, contact the database R&D personnel. It is recommended that the parameter value meets complexity requirements. |
Salt value |
Salt key. When Encryption mode is set to None, AES128, or AES256, this parameter is not required. When Encryption mode is set to another value, this parameter is mandatory. |
Encoding mode |
Encoding mode of passwords. This parameter must be specified if Encryption mode is set to MD5, SHA1, or SHA256.
The preceding methods for determining the encoding mode are not applicable to all scenarios. For details, contact the database R&D personnel. |
Mapped user group |
User group to which users authenticated using the third-party database belong. |
Bypass |
If iMaster NCE-Campus fails to connect to the third-party database, iMaster NCE-Campus authenticates all users using accounts synchronized from the database to ensure service continuity. |
Parameter |
Description |
|---|---|
Rule name |
Name of a role mapping rule. |
Role |
Role attached to users. |
Rule matching mode |
|
Filter condition |
A filter condition consists of the following three fields:
|
SSO Through Interconnection with AD FS
Context
Security Assertion Markup Language (SAML) defines a framework for implementing secure information exchange. It realizes unified identity authentication among multiple applications.
Typically, a federation environment consists of three roles:
- Users who provide identity information
- Service provider (SP): The SP determines access permissions based on users' identity information. iMaster NCE-Campus can function as the SP.
- Identity Provider (IdP): The IdP provides an assertion on the correctness of identity information for a specific topic. It is similar to a notarial institution. The Active Directory Federation Services (AD FS) server can function as the IdP.
Assertions provide information such as the verification performed by the subject, the attributes of the subject, and authorization decisions that whether the subject is allowed to access specific resources. Assertion diagnosis is mainly achieved by certificate signing. The IdP signs on assertions, and the SP verifies the signature to confirm that they come from the IdP. The IdP and SP trust each other in this way.
The IdP and SP servers communicate through the SAML protocol to share authentication information. SAML is not responsible for authentication. Instead, it only transmits verified authentication information.
AD FS interconnects with iMaster NCE-Campus through the SAML 2.0 protocol to implement the single sign-on (SSO) function. In this interconnection, AD FS functions as the SSO authentication server, which is the IdP. iMaster NCE-Campus functions as the SP. The IdP and SP import the metadata file of each other to trust each other. The metadata file contains the signature certificate, encryption certificate, and redirection URL.
Authentication Process
After the SAML module and AD FS are interconnected, a portal page is pushed during the portal authentication process. The pushed page determines whether the access request is redirected to AD FS for verification. After redirection to the AD FS page is configured, the request is redirected to the AD FS page. Then, the AD FS pushes a login page on which the user is asked to enter the username and password to pass identity authentication. After successful authentication, the SAML module authorizes the user based on authentication rules to grant network access permissions. The following figure shows the configuration process.
- The network administrator completes interconnection configuration for AD FS on and imports the metadata file of each other to both and AD FS.
- An end user initiates a network access request in the browser.
- The portal server queries the AD FS configuration.
- AD FS sends its configuration to the portal server.
- The portal server redirects the network access request to the AD FS based on the received AD FS configuration and pushed page.
- AD FS pushes a login page to the browser of the end user.
- The end user enters the username and password on the login page.
- AD FS completes identity authentication and sends the verification pass result to the portal server.
- The portal server completes the follow-up authentication process. The authenticated end user can access the network.
Procedure
- Customize a portal page on iMaster NCE-Campus.
- Choose from the main menu.
- On the Page Customization tab, click
![]()
to create a customization template.![]()
- Choose from the main menu and click Create to configure an SAML IdP. Select a portal page from the custom page list. After the settings are complete, click OK.
![]()
- Configure an authentication rule.
- Choose from the main menu.
- Click Create to create an authentication rule. Set the authentication method to user access authentication and select a wireless or wired access mode. For details about other parameters in the authentication rule, see Configuring an Authentication Rule.
- Configure an authorization result.
- Choose from the main menu.
- Click Create to configure an authorization result. For details about parameters in the authorization result, see Configuring an Authorization Result.
- Configure an authorization rule.
- Choose from the main menu.
- Click Create to create an authorization rule. In the authorization rule, select the user group configured for the SAML IdP. Set the authentication method to HACA portal authentication or user access authentication and select a wireless or wired access mode. Apply the authorization result configured in the previous step in the authorization rule. For details about other parameters in the authorization rule, see Configuring an Authorization Rule.
- On the server running AD FS, start AD FS Management.
- Create a relying party:
In the upper right corner of the AD FS page, click Add Relying Party Trust..., and click Start.
![]()
Select Import data about the relying party from a file, click Browse..., select the SP configuration file exported before, and click Next.
![]()
Enter the name of the relying party, and click Next. The name of the new relying party must be different from existing ones.
![]()
Select I do not want to configure multi-factor authentication settings for this relying party trust at this time. and click Next.
![]()
Select Permit all users to access this relying party and click Next.
![]()
Retain the default settings and click Next.
![]()
Select Open the Edit Claim Rules dialog for this relying party trust when the wizard closes and click Close.
![]()
- Add relying rules for the relying party:
On the Edit Claim Rules for sp_157 page, click Add Rule....
![]()
Select Send LDAP Attributes as Claims and click Next.
![]()
Set Claim rule name, select a value for Attribute store, configure data under Mapping of LDAP attributes to outgoing claim types, and click Finish.
![]()
Click OK.
![]()
- Enable Forms Authentication:
In the AD FS page, click Authentication Policies.
Under Primary Authentication > Global Settings > Authentication Methods, click Edit.
![]()
Under Intranet, select Forms Authentication, click OK.
![]()
- Create a relying party:
to create a customization template.
Parameter Description
Parameter |
Description |
|---|---|
Protocol |
Protocol used. The value is SAML 2.0. |
Status |
Status of the SAML IdP. The SAML IdP settings take effect only after the status is On. |
Bound customized page |
Customized page to bind. Customized pages support the HTTP and HTTPS protocols. The selected customized page must use a protocol the same as that specified by the IdP. For example, if AD FS supports HTTPS, the page selected here must use HTTPS. |
User group |
User group to which users who need to be verified by the AD FS server belong. |
Export metadata |
Action of exporting a metadata file. The file is to be imported to AD FS interconnected with iMaster NCE-Campus . |
Identity provider |
IdP of the metadata. The values are AD FS and NetIQ. |
SLO deregistration URL |
Deregistration URL of the SAML. |
Metadata file |
Metadata file of the IdP to be imported. Use the following method to obtain the file:
|
in the upper-right corner of the browser and choose File > Save to download the IdP file to a local directory.Configuring Online Behavior Management
Context
When both iMaster NCE-Campus and ASG are deployed on a network, you can configure single sign-on (SSO) for associated login to iMaster NCE-Campus and ASG, to authenticate and authorize users on iMaster NCE-Campus while managing users' online behavior on ASG.
This networking can achieve the following purposes:
Network access permission management
Assigns network access permissions by department or user to prevent unauthorized access and privilege abuse.
Outgoing data management
Manages the web visit and email sending behavior to effectively prevent information leakage.
Outbound bandwidth management
Blocks or rate-limits applications with high bandwidth consumption, such as network games, web videos, and P2P videos, to improve the outbound bandwidth utilization. Provides bandwidth assurance measures to ensure sufficient bandwidth for key applications and internal VIPs.
Threat filtering
Blocks malicious website visits such as phishing, Trojan horse injecting, and malicious software downloads, and automatically filters viruses and threatening traffic to ensure network access security.
Violation information management
Filters web pages with illegal content and disallows users to post violation information on web pages.
Auditing and supervision
Audits behavior logs and saves data sent to external networks to meet supervision requirements.
Associated deployment with iMaster NCE-Campus
Deploys iMaster NCE-Campus with ASG in associated mode to implement SSO. ASG automatically synchronizes user information from iMaster NCE-Campus and prevents users who are not authorized by iMaster NCE-Campus from accessing the Internet, ensuring security of network access terminals.
Implementation
User login and logout on ASG (using the 802.1X client built in the operating system for authentication)
![]()
A user uses the 802.1X client built in the operating system to initiate an authentication request. After successful login on the RADIUS server, the server notifies the ASG device that the user has gone online. The ASG device then manages online behavior of the user.
When the user deregisters to log out from the RADIUS server, the user also deregisters on the ASG device.
When the administrator forces the user to go offline, the RADIUS server logs the user out and instructs the ASG device to log the user out.
User login and logout on ASG (using web Portal authentication)
Figure 5-59 Login process![]()
A user initiates a web authentication request. After successful login on the portal server, the server notifies the ASG device that the user has gone online. The ASG device then manages online behavior of the user.
Figure 5-60 User disconnection process![]()
When the user deregisters to log out from portal server, the user also deregisters on the ASG device.
Procedure
In this section, an NGFW is used as the online behavior management device. This section only describes the iMaster NCE-Campus and NGFW configurations after NGFW deployment, which are required to implement SSO and user behavior management. For details about other iMaster NCE-Campus and NGFW configurations before NGFW deployment, see the product documentations of iMaster NCE-Campus and NGFW.
NGFW does not provide a separate entry for switching to iMaster NCE-Campus. The SSO settings are configured on the TSM server. The TSM server or Policy Center connects to NGFW through port 8080. However, iMaster NCE-Campus connects to NGFW through port 8445. By default, port 8445 of iMaster NCE-Campus is disabled. To enable port 8445, see Enabling the HTTP Port.
- Choose from the main menu. On the page that is displayed, click Create to add an online behavior management device.
![]()
- Log in to the online behavior management device and add iMaster NCE-Campus.
Add iMaster NCE-Campus to NGFW to implement association.
Choose Object > Authentication Server > TSM. Click Add, set parameters and click OK.
![]()
Click Detection to check the connectivity between NGFW and iMaster NCE-Campus.
If the connection between NGFW and iMaster NCE-Campus is normal, the system displays Server detection succeeded.
Create a user import policy for importing users and the organizational structure on iMaster NCE-Campus automatically.
Choose Object > User > User Import.
Click the Server Import tab and click Add.
Set parameters and click OK.
![]()
Select import, click Import Now, and click Yes in the dialog box that is displayed to execute the policy immediately and import the departments or users on iMaster NCE-Campus to NGFW.
Configure security policies to grant corresponding Internet access permission to authenticated users.
Choose Policy > Security Policy > Security Policy and click Add to configure security policies.
Configure a security policy for control traffic from the trust zone where users reside to the DMZ where the iMaster NCE-Campus server resides, so that users are authenticated on iMaster NCE-Campus.
Configure a security policy to control the DMZ where iMaster NCE-Campus resides to the local domain, so that iMaster NCE-Campus can communicate with NGFW.
Configure security policies for users to access the Internet.
Configure TSM SSO and enable the NGFW to implement online behavior management.
Choose Object > User > default, configure TSM SSO, and click Apply. Configure new users as temporary users and grant network access permission of the newuser user to the users.
![]()
Choose Object > User > Authentication Policy, click Add to configure authentication policies. Configure the action in the authentication policy for users to access the iMaster NCE-Campus server as no-authentication so that the users' authentication packets can go through NGFW to the iMaster NCE-Campus server. Configure the action in the authentication policy for users' service traffic to authentication exemption so that NGFW can obtain user information through SSO.
![]()
![]()
Parameter Description
Parameter |
Description |
|---|---|
IP address |
IP address of the online behavior management device. Find the outbound interface connecting to iMaster NCE-Campus in the routing table of NGFW. The IP address of this outbound interface is the IP address of NGFW. iMaster NCE-Campus locates and communicates with NGFW through this IP address. |
Device name |
Name of the online behavior management device. The name identifies a device and facilitates device management. |
Port |
Port used for communication between iMaster NCE-Campus and NGFW. The default value is 8001. |
Encryption algorithm |
Encryption algorithm used for communication between iMaster NCE-Campus and NGFW. The options are AES128 and AES128(Reinforced). |
Access Key |
Access key. The value must be the same as that configured on NGFW. It is recommended that the value meet password complexity requirements. |
IPv4 address pool |
IPv4 addresses or segments of terminals that require online behavior management. iMaster NCE-Campus sends the login and logout messages of terminals whose IP addresses are within this range to NGFW. One IP address or IP segment occupies one line. The IP segment is in the IP1-IP2 or IP/mask length format. When you specify IP segments, comply with the minimal and accurate principle, because a large number of IP addresses will lower the NGFW's operational efficiency. For example, if you want to include only ten terminals in the IP segment 192.168.10.1/24, enter 192.168.10.1-192.168.10.10. |
IPv6 Switch |
Whether to enable IPv6. |
IPv6 address pool |
IPv6 addresses or segments of terminals that require online behavior management after IPv6 is enabled. iMaster NCE-Campus sends the login and logout messages of terminals whose IP addresses are within this range to NGFW. One IP address or IP segment occupies one line. The IP segment is in the IP/mask length format. When you specify IP segments, comply with the minimal and accurate principle, because a large number of IP addresses will lower the NGFW's operational efficiency. |
Protocol version configuration item flag |
Version of the private protocol used by iMaster NCE-Campus to synchronize online user information to the online behavior management device. The options are 1.0, 2.0, 3.0, 4.0, and 5.0. 1.0: The user login messages include the MAC address, IP address, username, and user group in the dc=root,ou=subgroup format. 2.0: Compared with the 1.0 version, this version also supports the effective date and expiration date of receptionist and guest accounts. 3.0: Compared with the 1.0 version, this version changes the user group field to the role field in the ou=xxxx format. 4.0: Compared with the 2.0 version, this version changes the user group field to the role field in the ou=xxxx format. 5.0: Compared with the 1.0 version, this version also supports the terminal type, AD domain authentication (yes/no), and access type, and changes the user group format to ou=root,ou=subgroup. |
Configuring a RADIUS Accounting Device
Context
When iMaster NCE-Campus associates with a RADIUS accounting device, iMaster NCE-Campus sends accounting packets to the RADIUS accounting device that collects data such as the username and IP address.
Procedure
- Choose and click Create to create a RADIUS accounting device.
![]()
Parameter Description
Parameter |
Description |
|---|---|
RADIUS accounting device name |
Name of the RADIUS accounting device. |
RADIUS accounting device IP address |
IP address of the RADIUS accounting device. |
Shared key |
Shared key. It must be the same as the private key configured on the RADIUS accounting device. |
Accounting port |
Accounting port. It must be the same as the port configured on the RADIUS accounting device. |
Real-time forwarding |
Whether to enable real-time forwarding.
|
Packet response |
Whether to send response packets.
|
Timeout Interval (s) |
Timeout interval of accounting packets, in seconds. This parameter is valid only when Packet response is enabled. The value range is from 3 to 120. The default value is 5. |
Resend tries |
Number of retransmissions of accounting packets. This parameter is valid only when Packet response is enabled. The value range is from 0 to 9. The default value is 2. |
Region |
Region to which accounting packets belong. After a region is configured, only accounting packets in this region are forwarded. |
Managing Admission Devices
Context
Access control devices, also called admission devices, refer to network devices such as switches and WACs supporting the RADIUS protocol.
When used in HWTACACS authentication, 802.1X authentication, portal authentication, MAC address authentication, and relay authentication, such devices must be added to iMaster NCE-Campus for unified management. They function as RADIUS clients to associate with iMaster NCE-Campus to control end users and terminals.
Procedure
- Choose from the main menu.
- Click
![]()
on the left side and create a device group. Device groups are displayed in a tree structure. A maximum of 128 device groups can be created, nested in up to four levels.![]()
- (Optional) When iMaster NCE-Campus interworks with a third-party device for authentication, to configure RADIUS attributes to implement the Change of Authorization (CoA) function, click the Access Device Template tab, click Create, and create a CoA template. Currently, the CoA packet attributes that can be configured include Port bounce, Shut down, and Re-authentication. After the configuration is complete, click OK.
![]()
- Select a created device group, click the Admission device tab, and click Create to add devices to the device group.
![]()
- To add cloud managed devices to a device group, click the Cloud-based Device tab, click Add, select a desired cloud managed device, and then click
![]()
. To remove a cloud managed device from a device group, select the device and click Moving to Group. iMaster NCE-Campus cannot deliver configurations to cloud managed devices added to a device group or modify the configurations. - (Optional) When a third-party device needs to be configured as an admission device or portal authentication-free needs to be configured on fabric networks, choose from the main menu.
- On the page that is displayed, click the Portal Authentication-Free Policy tab and click Create to create a portal address authentication-free control policy. This portal address authentication-free control policy takes effect only when the third-party device serves as the authentication point.
![]()
- After the portal address authentication-free control policy is configured, click
![]()
to apply the policy to a user groups or user. A user group or user can be bound to only one portal address authentication-free control policy. If Portal authentication-free extension is enabled on the Advanced Parameters tab page under , this function takes effect in the portal address authentication-free control policy. That is, the portal address authentication-free validity period is extended as configured.![]()
- On the page that is displayed, click the Portal Authentication-Free Policy tab and click Create to create a portal address authentication-free control policy. This portal address authentication-free control policy takes effect only when the third-party device serves as the authentication point.
- After device groups are created, select a device group when you create an authentication or authorization rule to authenticate and authorize users based on this user group.
- Select the desired device and click Transfer to move the device to another device group.
- Select a device list to export and click Export to export device information in a batch.
- Click Import to import information of batch devices by using a template.
on the left side and create a device group. Device groups are displayed in a tree structure. A maximum of 128 device groups can be created, nested in up to four levels.
. To remove a cloud managed device from a device group, select the device and click 
to apply the policy to a user groups or user. A user group or user can be bound to only one portal address authentication-free control policy. If Portal authentication-free extension is enabled on the 
Follow-up Procedure
- Select the desired device group and click
![]()
above it to modify the name and description of this device group. - Select the desired device group and click
![]()
above it to delete the device group. After a device group is deleted, sub-device groups of this group as well as information about all devices in them are deleted. - Select an admission device and click
![]()
to modify the device configuration. - Select an admission device and click
![]()
to delete the admission device.
above it to modify the name and description of this device group.
above it to delete the device group. After a device group is deleted, sub-device groups of this group as well as information about all devices in them are deleted.
to modify the device configuration.
to delete the admission device.Parameter Description
Parameter |
Description |
|---|---|
Name |
Name of a device group. |
Description |
Description of the device group. |
Parameter |
Description |
|
|---|---|---|
Device name |
Name of an admission device. |
|
IP address |
IP address of the admission device. |
|
Backup IP address |
Secondary IP address of the admission device. This parameter is required when each managed device is dual-linked to two switches or WACs. |
|
Device series |
Series of the admission device. The options are Aruba OS, Cisco Crystal, Cisco WLC, H3C S, Huawei Engine, Huawei NAC, and Other. |
|
RADIUS authentication parameters |
CoA Type |
Change of Authorization (CoA) type of the authentication device. CoA allows the administrator change the rights of online users or re-authenticate them through RADIUS. The options are as follows: Default CoA: CoA packets are forwarded between the authentication device and authentication server to update user authorization information periodically. No CoA: User authorization information cannot be updated. Port Bounce: The authorization information of an online user is updated when you alternate the interface to which the user connects between Up and Down. Reauth: An online user is re-authenticated to update the user's authorization information. |
Admission device template |
When iMaster NCE-Campus interconnects with a third-party device for authentication, you need to configure an admission device template to define RADIUS attributes to implement the CoA function. You can choose from the main menu and click the Admission Device Template tab to create an admission device template. |
|
Accounting key/Confirm accounting key |
Accounting key. The value is a string of 1 to 128 characters, without spaces, single quotation marks ('), and question marks (?). The value must be the same as the private key on the access control device configured by using the radius-server shared-key command. |
|
Authorization key/Confirm authorization key |
Authorization key. The value is a string of 1 to 128 characters, without spaces, single quotation marks ('), and question marks (?). The value must be the same as the private key on the access control device configured by using the radius-server authorization command. |
|
Accounting interval (min) |
Accounting interval. After real-time accounting is enabled, the access control device sends real-time accounting packets to the accounting server at intervals. The accounting server starts accounting only after receiving real-time accounting packets. If the access control device detects that the charged user has gone offline, it stops sending real-time accounting packets to the accounting server. Then, the accounting server stops accounting. If the access control device does not receive any accounting update packets at three accounting intervals, it forces the charged user to go offline. The value must be the same as the value of accounting realtime in the accounting scheme. The value range is from 0 to 65535, in minutes. |
|
Portal authentication parameter |
Portal protocol |
Protocol used for portal authentication. The options are Huawei Portal(Portal2.0) and CMCC Portal. |
Online portal user synchronization |
Synchronizes online Portal users from the access control device. You must run the user-sync command in the portal server template view to enable user information synchronization on the access control device. You are advised not to set this parameter for switches and WACs. |
|
Portal heartbeat verification |
Enables portal heartbeat detection. After you enable this function, iMaster NCE-Campus sends Portal heartbeat detection packets to the access control device at intervals of 1 minute. You must run the server-detect command in the portal server template view to enable portal heartbeat detection on the access control device. If the access control device does not receive any responses for portal heartbeat detection packets at three intervals, it determines that the current portal server fails and triggers a primary/secondary switchover between the Portal servers. After you enable this function, you can select an IAE component that sends Portal heartbeat detection packets to the access control device. |
|
Portal key/Confirm the portal key |
Portal key. The key is a string of 1 to 16 characters. The value cannot contain spaces, single quotation marks ('), or question marks (?). You are advised to set a value that contains more than 6 characters, including digits and uppercase and lowercase letters. The value must be the same as the value of shared-key cipher in the portal template of switches or WACs. |
|
URL key/Confirm URL key |
Custom parameter used to encrypt the portal page push URL. The key is a string of 1 to 16 characters. The value cannot contain spaces, single quotation marks ('), or question marks (?). You are advised to set a value that contains more than 6 characters, including digits and uppercase and lowercase letters. The value must be the same as that configured by using the url-template command in the portal server template on the access control device. For details, seeHow Do I Configure URL Parameter Encryption for Portal Authentication. Do not set this parameter if NAT is deployed between terminals and the portal server. |
|
Terminal IP address list |
List of IPv4 or IPv6 addresses of terminals that access networks through portal authentication. iMaster NCE-Campus determines the access control device to which it redirects terminals' authentication requests based on this list, when the redirection packets do not contain terminal IP addresses. |
|
Portal authentication port |
Portal authentication port. The default value is 200 for switches and WACs. The value must be the same as that configured by using the web-auth-server listening-port port-number command on the access control device. |
|
HWTACACS authentication parameter |
HWTACACS key/ Confirm the HWTACACS key |
HWTACACS key. The value must be the same as that configured by using the hwtacacs-server shared-key command on the access control device. The key is a string of 1 to 255 characters, without spaces or question marks (?). |
Region Management
Configuring a Region and Binding Devices to the Region
Context
The tenant administrator can configure a region and bind devices to the region to implement region-based authentication and authorization. Only devices of specific types can be bound to a region. Currently, the following device types are supported: AP MAC, AP Location, VLAN, Terminal IP Address Range, Access Device, and Egress Gateway. The region to which a device belongs is determined by the device type with the highest priority.
Procedure
- Choose from the main menu. On the page that is displayed, click the Admission Region Management tab.
- Click
![]()
on the left side and create a region. Regions are displayed in a tree structure. The default region is the root region. A maximum of four levels of regions, including the root region, can be configured, and a maximum of 128 regions can be created in total.![]()
Click
![]()
on the left side and import regions in a batch by using the template.![]()
- Select a created region and click Create bind devices to the region. A maximum of 100 devices can be bound to a region.
![]()
on the left side and create a region. Regions are displayed in a tree structure. The default region is the root region. A maximum of four levels of regions, including the root region, can be configured, and a maximum of 128 regions can be created in total.
on the left side and import regions in a batch by using the template.
Follow-Up Procedure
- Select a region and click
![]()
on the top to view the region configuration. Click Modify on the Region Details page to modify the region name. - Select a region and click
![]()
to delete the region. After a region is deleted, its sub-regions and devices in this region are also deleted. - Select a regional device and click
![]()
to modify the device configuration. - Select a regional device and click
![]()
or Delete to delete the device.
on the top to view the region configuration. Click Modify on the Region Details page to modify the region name.
to delete the region. After a region is deleted, its sub-regions and devices in this region are also deleted.
to modify the device configuration.
or Parameter Description
Parameter |
Description |
|---|---|
Name |
Name of a regional device. |
Device type |
Device type and matching priority of the regional device. The region to which a device belongs is determined by the device type with the highest priority. The options are as follows: Priority 1: AP Location Priority 2: AP MAC Priority 3: VLAN Priority 4: Terminal IP Address Range Priority 5: Access Device Priority 6: Egress Gateway After you select a device type, you need to enter the corresponding device information, such as the location, MAC address, and VLAN ID. |
Configuring a Regional Roaming Policy
Context
A regional roaming policy elevates guest permissions flexibly. You have created multiple regions and configured different authorization policies for these regions. In this case, you can configure a regional roaming policy, in which you can specify the source and destination regions and enable user group switching. After a user roams from the source region to the destination region, the user will be switched to the target user group with a higher privilege level and the user's permissions will be elevated.
Pre-configuration Tasks
A source region and a destination region have been created. For detail, see Configuring a Region and Binding Devices to the Region.
A target user group has been created. For detail, see Configuring a User Group and User.
Procedure
- Choose from the main menu. On the page that is displayed, click the User Group Priority tab. Click Create and set a priority for the target user group. The priority of the target user group created first is 1. The priority is incremented by 1 each time a new user group is created. A smaller priority value indicates a higher priority. After multiple target user groups are created, you can adjust their priorities. The source user group has the lowest priority by default. You can adjust this priority as required. To trigger user group switching after the roaming, ensure that the target user group has a higher priority than the source user group.
![]()
- Choose from the main menu. On the page that is displayed, click the Regional Roaming Policy tab. Click Create and create a regional roaming policy. If you toggle Switch User Group on in this regional roaming policy, the user will be switched to the target user group with a higher priority after the user roams from the source region to the destination region. If you toggle Enable MAC prioritized portal authentication on, MAC address-based re-authentication will be performed for this user. If the authentication region changes after roaming, iMaster NCE-Campus will match this regional roaming policy.
![]()
Parameter Description
Parameter |
Description |
|---|---|
Name |
Name of the regional roaming policy. |
Source Area |
Source region before roaming. |
Target Area |
Destination region after roaming. |
Switch user groups |
Switches the user to the Destination user group if it has a higher priority than source user group. |
MAC address-prioritized portal authentication |
Performs MAC address-based re-authentication for this user. If the authentication region changes after roaming, iMaster NCE-Campus will match this regional roaming policy. |
Terminal Management
Overview
Context
Terminal identification is a basic network management task. The terminal identification feature identifies terminal information such as the terminal type, IP address, MAC address, vendor, and operating system in active or passive mode. It allows administrators to group terminals by their types and authenticates and authorizes terminals accordingly.
iMaster NCE-Campus identifies terminals to authorize them by type and grant different network access permissions based on the type.
Terminal Identification Policy
A terminal identification policy defines methods used to identify terminals based on the information such as the terminal type, IP address, MAC address, vendor, and operating system.
The terminal identification policy is unique for each terminal type.
Terminal Identification Methods
By User-Agent
A User-Agent is the identifier of a web browser. The web server sends the most appropriate web page content based on the User-Agent of a terminal's web browser, ensuring content compatibility among different browsers. User-Agent information includes the operating system name, operating system version, and CPU type. After an end user initiates a web authentication request to the Service Controller (SC), the SC analyzes the browser's User-Agent information to identify the operating system name and operating system version.
For example, if the User-Agent of a web browser contains "Windows NT 5.1", the kernel version of Microsoft Windows is Windows NT 5.1.
By DHCP Option
IP addresses are automatically allocated by the DHCP server. A DHCP client applies for relevant parameters when it receives an IP address from the DHCP server. Different terminals obtain different parameters from the DHCP server, forming unique characteristics of each terminal.
DHCP Option 55 is a list of parameters that DHCP clients obtain from the DHCP server. If DHCP Option 55 for a terminal is "43,60", it is highly possible that this terminal is an Apple PC using macOS. The value 43 in DHCP Option 55 specifies device and vendor information reported by the DHCP client.
To allow access control devices to report device and vendor information, DHCP Snooping must be configured.
By MAC OUI
A MAC address consists of six bytes. A MAC OUI is the leftmost three bytes in a MAC address that uniquely identifies an organization. MAC OUIs are allocated to organizations by Institute for Electrical and Electronic Engineers (IEEE). It has a one-to-one mapping with the NIC manufacturer. You can know the manufacturer of a terminal based on the MAC OUI allocated by IEEE.
- By mDNS
multicast DNS (mDNS) allows hosts in a LAN to discover and communicate with each other without a traditional DNS server.
The mDNS service uses port 5353 by default. When the mDNS service is enabled, each host joining a LAN multicasts a message to all hosts in the LAN to obtain the mDNS information.
To allow access control devices to report mDNS information, mDNS Snooping must be configured.
- LLDP
LLDP can detect status of Layer 2 links between devices on the network and analyze the network topology. After a device discovers the neighbor type for the first time or discovers changes in the neighbor type using LLDP, the device reports LLDP neighbor information to iMaster NCE-Campus so that iMaster NCE-Campus can obtain terminal characteristics. This method applies to scenarios where LLDP-supporting terminals are directly connected to Huawei access switches. By default, LLDP is enabled on Huawei access switches. Enable LLDP on Huawei access switches if this function is disabled.
By SNMP
Many device manufacturers apply the SNMP protocol to their developed devices to allow iMaster NCE-Campus to query the device running status through SNMP. SNMP applies to devices such as switches, routers, IP phones, and printers. These devices report the device name, device type, device manufacturer, and device running status to iMaster NCE-Campus. iMaster NCE-Campus can identify these devices by querying and analyzing the received information.
For example, if iMaster NCE-Campus finds that the value of the hrDeviceDescr property is HP Color LaserJet CP5520 Series through SNMP, the information indicates that the device is an HP CP5520 laser printer.
SNMP can be used to identify devices when the following conditions are met:
The target device runs SNMP and allows third-party software to query its running status.
iMaster NCE-Campus has been configured with matching rules for the target device.
- Nmap
Network Mapper (Nmap) is an open-source network scanner and security audit tool. It is mainly used for host discovery, port scanning and service version and OS detection. By default, iMaster NCE-Campus does not support Nmap. After the Nmap plug-in is loaded, iMaster NCE-Campus can use Nmap to identify terminals. You can browse and obtain the Nmap plug-in and related documents from the Huawei technical support website. Search for the desired plug-in usage guide based on the iMaster NCE-Campus version. If you do not have the permission, contact technical support personnel.
Only Huawei WLAN devices support terminal identification by User-Agent and DHCP Option. Huawei switches and WACs from other vendors do not support terminal identification by User-Agent and DHCP Option.
Nmap provides proactive terminal identification. After being enabled, Nmap automatically scans the ports, operating systems, and services of terminals in the configured network segments to obtain information such as the type and operating system of the terminals. Exercise caution when using Nmap.
Terminal Identification Triggering Conditions
iMaster NCE-Campus triggers terminal identification in the following conditions:
An administrator performs SNMP scanning manually.
- An administrator performs Nmap scanning manually.
A new device has initiated an authentication process.
The device information such as the LLDP neighbor information, MAC address, or operating system type has changed.
Terminal Identification Process
The terminal identification process is as follows:
Analyze the obtained terminal information, such as the User-Agent information generated during interaction between iMaster NCE-Campus and a web browser.
The terminal is unidentified at this moment.
Re-match and evaluate the terminal information based on a terminal identification policy.
Sort the policy-based evaluation scores in descending order, and use the result with the highest score as the final result.
Add a terminal to a terminal group based on the final result.
If you find that the final identification result for a terminal is incorrect, you can modify the result manually. iMaster NCE-Campus does not automatically identify this terminal later. The manually modified result prevails for this terminal.
Configuring Terminal Identification
Context
Terminal identification can be implemented in active and passive modes. After the terminal identification feature is enabled, authenticated new devices are identified automatically. You can add identified devices to a specific terminal group and configure authentication and authorization rules for the terminal group.
Procedure
- (Optional) Choose from the main menu. Click Create to create a custom rule.
This step is required if you want to customize a terminal identification rule. When iMaster NCE-Campus identifies terminals, the custom rule is used preferentially for matching. If this custom rule contains multiple matching conditions, the custom rule hits when the sum of the scores for all the hit matching conditions reaches this minimum score.
![]()
Click Create to create a matching condition.
![]()
If you need to define large number of custom rules, click Import, download the rule template, define rules in this template, and upload the template to iMaster NCE-Campus.
![]()
- Choose from the main menu. On the page that is displayed, toggle on Terminal identification.
- Enable switches and APs to report terminal identification information.
- On a traditional campus network:
Choose from the main menu. Choose HTTP from the navigation pane. On the page that is displayed, toggle on Reporting terminal identification information. Switches and APs proactively report terminal information to improve the terminal identification accuracy. If iMaster NCE-Campus identifies terminals based on the DHCP option or mDNS, you also need to configure DHCP snooping or mDNS snooping on the switches and APs.
![]()
(Optional) In the wireless authentication scenario, choose from the main menu, choose or from the navigation pane, and click Create. When configuring MAC address authentication, enable Automatic re-authentication. With this function enabled, if a terminal fails to be authenticated before it is successfully identified, the terminal will be automatically re-authenticated by iMaster NCE-Campus. As such, the terminal can be automatically authenticated and go online after it is successfully identified by iMaster NCE-Campus.
- On a fabric network:
Choose from the main menu, click Create, and toggle on Reporting terminal identification information when creating a fabric network.
![]()
Choose from the main menu and click Create. When creating a VN, toggle on DHCP Snooping or mDNS Snooping. When creating a VN, you can toggle on DHCP snooping and mDNS snooping for all gateways in batches.
![]()
(Optional) Choose from the main menu, choose Authentication Template from the navigation pane, click Create to create an authentication template. Enable Automatic re-authentication in the template. If a terminal fails to be authenticated before being successfully identified, re-authentication is automatically performed on the terminal to ensure that the terminal can be automatically authenticated and go online after it is successfully identified.
![]()
- On a traditional campus network:
- (Optional) In wired authentication scenarios, choose from the main menu and choose from the navigation pane to authorize VLANs to end users. Click the Authentication Device Global Configuration tab, enable Close pre-connection, and set relevant parameters. After the configuration is complete, end users are added to authorized VLANs immediately after being authenticated successfully.
- (Optional) Choose from the main menu. On the page that is displayed, toggle SNMP scanning, set SNMP parameters and scanning parameters, and click Save the configuration. If dumb terminals such as printers cannot pass web authentication, identify them through SNMP. Ensure that the terminals to be identified have SNMP configured, so that they can send their status information to the NMS. If SNMP is not configured, configure SNMP on the target terminals first. The SNMP parameter settings on iMaster NCE-Campus must be the same as those on the terminals to be identified. To automatically scan terminals, ensure that iMaster NCE-Campus has the permission to access the terminals to be identified and the terminals have been authenticated.
![]()
Click Start task. The scanning status is as follows:
If no information is displayed under Scanning status, scanning is not started.
If scanning has completed, the result of the last scan and the start time of the last scan are displayed under Scanning status.
Follow-up Procedure
Choose from the main menu. On the page that is displayed, click Endpoint Profile Report to view Online Terminal Report, Last 30 Days Terminal Statistic Report, and Terminal Statistic Report.
Parameter Description
Parameter |
Description |
|
|---|---|---|
Name |
Name of the custom rule. |
|
Terminal group |
Terminal group to which devices matching this custom rule belong. |
|
Minimum score |
Minimum score for matching this custom rule. If this custom rule contains multiple matching rules, the custom rule hits when the sum of the scores for all the hit matching rules reaches this minimum score. |
|
Match rule |
Property |
Property of a matching rule. The options are as follows:
|
Matching mode |
Matching mode between the property value and the score for matching. The options are as follows:
|
|
Match value |
Score for matching a property in a matching rule. The value is a character string that can contain 1 to 256 characters. For example, if Property is DHCP Option 55, Matching mode is Equal, and Match value is 43, when the value of DHCP Option 55 reported by a terminal is 43, the terminal matches this rule. If Property is set to MAC OUI, the matching value is the first six bits of a MAC address. |
|
Score |
Score of a matching rule. The value is an integer in the range from 1 to 100. |
|
Parameter |
Description |
|---|---|
Protocol |
Version number of the SNMP protocol. |
Read community |
Read community of the SNMP protocol. This parameter is supported for SNMPv1 and SNMPv2c only. The value must be the same as that configured on the terminal. NOTE:
SNMPv3 is recommended because it is more secure than SNMPv1 and SNMPv2c. |
Username |
Username, authentication password, and encryption password for SNMPv3 users. |
Authentication password |
|
Encryption password |
|
Task Period |
Period of an SNMP scanning task. The options are Single, Every day, Weekly, and Monthly. |
Execution time |
Time taken to execute an SNMP scanning task. |
IP address set |
IP address set that can be scanned through SNMP. |
Configuring Terminal Management
Context
- iMaster NCE-Campus provides the terminal management capability. Currently, the following types of terminal groups are supported.
- Self-defined: Terminal information obtained from Intelligent Access Control can be viewed in the user-defined group.
- Identified: Information about terminals managed through terminal identification can be viewed in the identified group.
- Unidentified: Information about unidentified terminals can be viewed in the unidentified group.
- When viewing terminal information, you can filter terminals by type, vendor, model, operating system, blacklist status, approval status, and self-registration status.
- Pending Approval: The terminal has completed MAC address authentication by iMaster NCE-Campus but Intelligent Access Platform does not approve this terminal.
- Approved: The terminal has been approved by Intelligent Access Platform.
- Self-registration: The terminal has completed self-registration after the Boarding or MDM authentication succeeds.
- Blacklist: It lists terminals that are not allowed to be authenticated, for example, terminals that have been claimed missing. Terminals can be migrated from other groups to the blacklist group.
- Based on the authentication capability of iMaster NCE-Campus, cellular networks allow mobile terminals to access enterprises' campus networks without being restricted by physical boundaries.
Procedure
Campus Network Terminal
- Manage terminals and terminal groups.
- Choose from the main menu. On the page that is displayed, choose Self-defined or Identified and click
![]()
to create a terminal group.![]()
- Choose from the main menu. On the page that is displayed, select the target terminal group and click Create to create a terminal.
![]()
If a large number of terminals need to be added, you can import them in batches. Specially, choose More > Import, download the template, enter terminal information, and upload the template.
![]()
- Choose from the main menu. On the page that is displayed, choose Self-defined or Identified and click
- (Optional) After a terminal is added, you can delete or modify the terminal.
- Choose More > Export to export terminal information. The system automatically switches to the page and you can download the corresponding file to the local host to view terminal information.
- Select a terminal and click Delete to delete the terminal.
- Click
![]()
next to a terminal and modify the terminal information. - Select a terminal and click More > Add to Blacklist to blacklist the terminal.
- Select a terminal and choose More > Unblacklist to remove the terminal from the blacklist.
- Select a terminal and choose More > Mark to Unidentified to mark the terminal as unidentified.
- Select multiple terminals and choose More > Batch Modify Custom Terminal Group to modify terminal groups to which the terminals belong in batches.
- Select multiple terminals and choose More > Batch Modify Type/Vendor/Model to modify terminal types, vendors, and models in batches.
- Select multiple terminals and choose More > Batch Modify Operation System to modify terminal operating systems in batches.
- Click the Terminal Configuration tab and enable other functions as needed. The following functions are configurable:
- Terminal approval: When authentication is configured for IoT terminals and this function enabled, terminals can access the network through MAC address authentication only after being approved by Intelligent Access Platform.
- Allow identified terminals to automatically access the network through MAC address authentication: With this function enabled, identified terminals can be auto-authenticated without the need of entering MAC accounts.
- Allow registered terminals to automatically access the network through MAC address authentication: With this function enabled, terminals registered on MDM servers can be auto-authenticated without the need of entering MAC accounts.
![]()
to create a terminal group.
next to a terminal and modify the terminal information.
Carrier's Wireless Network Terminal
- Choose from the main menu, click the Carrier's Wireless Network Terminal tab, select a custom category from the left pane, and click
![]()
to create a terminal group. On the page that is displayed, configure a terminal group name and an APN default account.![]()
![]()
The APN, username, and password are carried in the Internet access request sent by a terminal. The username and password set here must be the same as those carried in the request. Otherwise, terminal access will be denied.
- Select the created terminal group, click the Carrier's Wireless Network Terminal tab, and click Create to create a terminal.
![]()
![]()
- Either IMSI or IMEI, or both, in the basic information must be set. If both parameters are set, iMaster NCE-Campus will verify the two parameters during terminal authentication. If the IMSI or IMEI does not match, terminal access is denied.
- The MSISDN and terminal IP addresses are optional.
To import terminals in batches, choose More > Import, download the template, enter terminal information in the template, and then import the template to iMaster NCE-Campus.
![]()
- (Optional) After a terminal is added, you can delete or modify the terminal.
- Choose More > Export to export terminal information. The system automatically switches to the page and you can download the corresponding file to the local host to view terminal information.
- Select a terminal and click Delete to delete the terminal.
- Click
![]()
next to a terminal and modify the terminal information. - Select a terminal and click More > Add to Blacklist to blacklist the terminal.
- Select a terminal and choose More > Unblacklist to remove the terminal from the blacklist.
- Select multiple terminals and choose More > Batch Modify Custom Terminal Group to modify terminal groups to which the terminals belong in batches.
Follow-up Procedure
- Select a group and click
![]()
to delete the group. After a group is deleted, terminals in the group are also deleted. - Select a group and click
![]()
to change the group name.
to delete the group. After a group is deleted, terminals in the group are also deleted.
to change the group name.Parameter Description
Parameter |
Description |
|---|---|
MAC address |
MAC address of a terminal. |
Terminal type/vendor/model |
Terminal type, vendor, or model. |
Operating system |
Operating system of the terminal. |
Custom terminal group |
Custom terminal group to which a terminal belongs. |
Description |
Terminal description. |
Parameter |
Description |
|---|---|
IMSI |
Either IMSI or IMEI, or both, in the basic information must be set. If both parameters are set, will verify the two parameters during terminal authentication. If the IMSI or IMEI does not match, terminal access is denied. |
IMEI |
|
Description |
Terminal description. |
MSISDN |
Indicates the mobile station international ISDN number (MSISDN) of a terminal. |
Terminal IP address |
If a terminal IP address is configured, the IP address is delivered during authentication and authorization. |
MDM Interconnection
Overview
This section describes how iMaster NCE-Campus interconnects with an MDM system to authorize mobile devices based on their status.
Context
With emergence of the bring your own device (BYOD) solution, increasing mobile devices need to connect to networks. iMaster NCE-Campus allows mobile devices to connect to networks after passing wireless 802.1X or portal authentication, but cannot detect devices' security status.
An MDM system can check the security status of registered mobile devices based on the compliance, jailbreaking, and data encryption information. After interconnecting with an MDM system, iMaster NCE-Campus obtains the device status from the MDM system and authorizes mobile devices accordingly. This prevents insecure mobile devices from connecting to networks.
Many vendors provide the MDM system. Currently, iMaster NCE-Campus can interconnect with MDM systems provided by Ivanti, Qi An Xin, and other vendors using the standard protocol to authorize mobile devices that are authenticated through wireless 802.1X or portal authentication.
Implementation
The authorization principle for interconnection between iMaster NCE-Campus and an MDM system is that the mobile device status is used as an authorization condition.
The authentication process is the same as that in wireless 802.1X or portal authentication when iMaster NCE-Campus is not interconnected with an MDM system. During user authorization, iMaster NCE-Campus matches authorization rules based on the mobile device status obtained from the MDM system.
If MDM check is enabled in authorization rules, iMaster NCE-Campus uses the mobile device status as an authorization condition when matching authorization rules. If only MDM check is set as the authorization condition, the matching process is as follows:
- After MDM check is enabled, iMaster NCE-Campus checks whether it can connect to the MDM system to obtain the mobile device status check result.
The administrator can select one of the following processing policies on iMaster NCE-Campus, if connecting to the MDM system fails or querying the mobile device status times out:
- Proceed to the next rule if this authorization rule does not match.
- Ignore MDM condition and disable query in the background: iMaster NCE-Campus determines that authorization rule matching succeeds without checking the authorization condition, and uses the authorization result defined in the rule. After authorization, iMaster NCE-Campus no longer obtains the mobile device status from the MDM system.
- Ignore MDM condition and enable query in the background: iMaster NCE-Campus determines that authorization rule matching succeeds without checking the authorization condition, and uses the authorization result defined in the rule. After authorization, iMaster NCE-Campus still obtains the mobile device status from the MDM system.
If iMaster NCE-Campus succeeds in obtaining the mobile device status in three attempts, it re-matches authorization rules based on the mobile device status. If it fails to obtain the mobile device status in three attempts, the current authorization rule will not match, and iMaster NCE-Campus continues to match the next authorization rule.
- If iMaster NCE-Campus is successfully connected to the MDM system, iMaster NCE-Campus checks whether the mobile device requesting authorization is registered with the MDM system.
The administrator can define different authorization rules on iMaster NCE-Campus to authorize registered and unregistered mobile devices.
For a mobile device that has registered with the MDM system, if the authorization rule Not registered on MDM server is configured, the mobile device matches this rule. If authorization rule Registered on MDM server is configured, the mobile device does not match this rule. In this case, iMaster NCE-Campus continues to match the next authorization rule.
- If a mobile device that has registered with the MDM system requests for authorization, iMaster NCE-Campus matches the MDM condition specified in an authorization rule with the mobile device status.
If the mobile device status is consistent with the MDM attribute defined in an MDM condition, the authorization rule matches.
If the mobile device status is inconsistent with the MDM attribute defined in an MDM condition, the authorization rule does not match, and iMaster NCE-Campus continues to match the next authorization rule.
Interconnecting with an MDM System (Ivanti)
To connect Ivanti that functions as the MDM system to iMaster NCE-Campus, in the system of Ivanti, add a compliance policy as well as a user name and the password for interconnection with iMaster NCE-Campus.
Logging In to the System of Ivanti
Log in to the system of Ivanti. The values of User name and Password on the login page are the same as the user name and password entered for interconnecting with iMaster NCE-Campus.
Installing the Client
- Choose Configuration from the navigation pane and then click Agent configuration and Myconfiguration.
![]()
- Click
![]()
and Agent Configuration. Then, select an agent based on the operating system. - Right-click the created agent and choose Create self-contained client installation package.
![]()
- Copy the new client installation package to the terminal and install the client. To install the client, you must possess the super administrator right. That is, log in to the terminal using an account with the super administrator right or right-click Run as administrator.
and Agent Configuration. Then, select an agent based on the operating system.
Configuring a Compliance Policy in the System of Ivanti
A terminal check tool needs to be installed in the system of Ivanti.
- Log in to the system of Ivanti. Choose Security and Compliance from the navigation pane, click All types, and select Custom definition from the drop-down list box.
![]()
- Click
![]()
to add an attribute.![]()
- Click Add to add a check rule.
![]()
- Specify affected platforms as required.
![]()
- Configure the check logic and then click Update. In this example, the logic is that the text.txt file must exist in disk C.
![]()
- After configuring the attributes of the check rule, click OK.
- Click OK. A compliance policy is added.
![]()
- Drag the check rule to the Compliance folder to make it take effect. The red exclamation mark before the check rule indicates that the check rule is enabled.
![]()
to add an attribute.
Interconnecting with the Ivanti Server
- Modify the file on the server and set the interconnection parameters. The file path is as follows: %programdata%\landesk\ServiceDesk\My.IdentityServer\IdentityServer3.Core.Models.Client.json
Add the following code in green. This is for your reference, and the specific configuration needs to be confirmed with Ivanti.
![]()
- Log in to iMaster NCE-Campus and choose from the main menu to configure an MDM server.
- Set Client ID, Client secret, and Scope to the same values as those in step 1.
- Set MDM server URL to https://Ivanti_IP address:port number of the Ivanti server.
![]()
Follow-up Procedure
After the interconnection is complete, configure terminal authorization based on the terminal status in the MDM system. For details, see Authorizing Mobile Devices by the MDM Status. To view the terminals that have been registered with the MDM system, choose and select Filter > Self-registration.
Authorizing Mobile Devices by the MDM Status
This section describes operations performed by the administrator and end user in MDM status-enabled mobile device authorization.
Task Overview
Prerequisites
- The administrator has completed preparations for interconnection. For details, see Interconnecting with an MDM System (Ivanti).
- The end user has the MDM client installed and registered with the MDM system.
Procedure
- Choose from the main menu.
- Click the MDM Condition tab and configure an MDM condition.
![]()
- Choose and configure authorization results.
You are advised to configure two authorization results, for unregistered devices and devices complying with MDM conditions, respectively. The default authorization result Deny access can be used for devices that do not comply with MDM conditions.
- Choose to configure authorization rules, and enable MDM check in the rules.
You are advised to configure two authorization rules, for unregistered devices and devices complying with MDM conditions, respectively. The default authorization rule Deny access can be used for devices that do not comply with any MDM condition.
- Choose to check the MDM status of the mobile device after an end user goes online.
Appendix
Configuring the Standard 802.1X client Provided by the Operating System
About This Chapter
Before a terminal can be authenticated and connect to a network, you need to configure the Standard 802.1X client provided by the operating system (Windows 7, Windows 8, MAC, Android, or iOS) of the terminal.
Configuring Wireless 802.1X Authentication
Before a terminal can be authenticated and connect to a wireless network, you need to configure the Standard 802.1X client provided by the operating system (Windows 7, Windows 8, MAC, Android, or iOS) of the terminal.
Microsoft Windows 7
This topic describes how to configure 802.1X authentication parameters on a terminal running the Windows 7 operating system before the first wireless 802.1X authentication for the terminal.
Prerequisites
- Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
- By default, iMaster NCE-Campus uses TLSv1.2 as the RADIUS authentication transmission protocol. If the built-in client of Microsoft Windows 7 is used for 802.1X authentication, you need to perform the following operations to set the transmission protocol to TLSv1 or TLSv1.1:
- Log in to the controller as the system administrator, choose from the main menu, and click TLS Protocol Configuration.
- Select TLSv1-0 or TLSv1-1, and click Enable.
- Log in to iMaster NCE-Campus, choose from the main menu, enable RADIUS Authentication Transmission Protocol, select TLSv1 and TLSv1.1, and click OK.
Procedure
- Choose Start > Control Panel.
- On Control Panel, choose Network and Internet > Manage Wireless Networks. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
- Click Add.
- Click Manually create a network profile. Set Network name to employee, Security type to WPA-Enterprise, Encryption type to AES, and select Start this connection automatically.
![]()
You must set Encryption type to the value the same as that on the device.
- Click Next.
- Click Change connection settings.
- Click the Security tab, select Microsoft: Protected EAP (PEAP) from the drop-down list below Choose a network authentication method, and click Settings.
- Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
If a RADIUS server certificate has been uploaded on the System > Terminal > Global Parameters > Access Management page, you can implement automatic certificate enrollment for terminals by referring to Configuring Group Policies on a AD server to Enable a Client to Automatically Obtain the Server Certificate. Alternatively, you can manually install the RADIUS server certificate on terminals, during which you can select Validate server certificate and then set Trusted Root Certification Authorities as required.
- Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
- Click OK to return to the page in Step 7, and then click Advanced settings.
- Select User or computer authentication from the drop-down list below Specify authentication mode.
- Click OK.
- When the confirm dialog box is displayed, enter the user name and password for authentication.
Microsoft Windows 8
This topic describes how to configure 802.1X authentication parameters on a terminal running the Windows 8 operating system before the first wireless 802.1X authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
- Choose Start > Control Panel.
- Click Network and Sharing Center on Control Panel.
- Click Set up a new connection or network.
- In the dialog box that is displayed, double-click Manually connect to a wireless network.
- Enter a network name, set Security type and Encryption type, click Start this connection automatically, and click Next.
![]()
You must set Encryption type to the value the same as that on the device.
- Click Next, and click Change connection settings.
- On the Security tab page, click Advanced settings.
- On the 802.1X settings tab page, select User or computer authentication from the drop-down list below Specify authentication mode, and click OK.
- Select Microsoft: Protected EAP (PEAP) from the drop-down list below Choose a network authentication method, and click Settings.
- Deselect Verify the server's identity by validating the certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
If a RADIUS server certificate has been uploaded on the System > Terminal > Global Parameters > Access Management page, you can implement automatic certificate enrollment for terminals by referring to Configuring Group Policies on an AD server to Enable a Client to Automatically Obtain the Server Certificate. Alternatively, you can manually install the RADIUS server certificate on terminals, during which you can select Verify the server's identity by validating the certificate and then set Trusted Root Certification Authorities as required.
![]()
- Deselect Automatically use my Windows logon name and password, and then click OK.
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
- Double-click the SSID to start 802.1X authentication.
Microsoft Windows 10
This topic describes how to configure 802.1X authentication parameters on a terminal running the Windows 10 operating system before the first wireless 802.1X authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
- Choose Start > Control Panel.
- Click Network and Sharing Center on Control Panel.
- Click Set up a new connection or network.
- In the dialog box that is displayed, double-click Manually connect to a wireless network.
- Enter a network name, set Security type and Encryption type, click Start this connection automatically, and click Next.
![]()
You must set Encryption type to the value the same as that on the device.
- Click Next, and click Change connection settings.
- On the Security tab page, click Advanced settings.
- On the 802.1X settings tab page, select User authentication from the drop-down list below Specify authentication mode, and click OK.
- Select Microsoft: Protected EAP (PEAP) from the drop-down list below Choose a network authentication method, and click Settings.
- Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
If a RADIUS server certificate has been uploaded on the System > Terminal > Global Parameters > Access Management page, you can implement automatic certificate enrollment for terminals by referring to Configuring Group Policies on an AD server to Enable a Client to Automatically Obtain the Server Certificate. Alternatively, you can manually install the RADIUS server certificate on terminals, during which you can select Verify the server's identity by validating the certificate and then set Trusted Root Certification Authorities as required.
- Deselect Automatically use my Windows logon name and password, and then click OK.
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
- Double-click the SSID to start 802.1X authentication.
MAC
This topic describes how to configure 802.1X authentication parameters on a terminal running the MAC operating system before the first wireless 802.1X authentication for the terminal.
Procedure
- Click the Wi-Fi icon
![]()
on the upper right corner of the desktop. - Double-click the SSID that requires 802.1X authentication.
- Enter the user name and password, and select Remember login info.
- Click OK.
on the upper right corner of the desktop.iOS
This topic describes how to configure 802.1X authentication parameters on a terminal running the iOS operating system before the first wireless 802.1X authentication for the terminal.
Procedure
- Touch Settings.
- Touch Wi-Fi.
- Turn Wi-Fi on to enable the terminal to discover available wireless networks.
- Touch the wireless SSID that requires 802.1X authentication from the SSID list.
- Enter the user name and password, and then click Join.
The Certificate dialog box is displayed, asking you whether to accept the RADIUS certificate.
- Click Accept to complete the authentication.
Android
This topic describes how to configure 802.1X authentication parameters on a terminal running the Android operating system before the first wireless 802.1X authentication for the terminal.
Procedure
- Touch Settings.
- Touch WLAN and WLAN Settings. (WLAN is displayed as Wi-Fi on some mobile phones.)
The WLAN Settings page is displayed.
- Touch the wireless SSID that requires 802.1X authentication from the SSID list.
- Set the access mode.
- Set EAP method to PEAP.
- Set Phase 2 authentication to MSCHAPV2.
- Set Identity to the user name used for 802.1X authentication.
- Set Password to the password used for 802.1X authentication.
- Click Connect.
After the authentication succeeds, the Wi-Fi status changes to connected.
Configuring Wired 802.1X Authentication
Before a terminal can be authenticated and connect to a wired network, you need to configure the Standard 802.1X client provided by the operating system (Windows XP, Windows 7, or Windows 8) of the terminal.
Microsoft Windows 7
This topic describes how to configure 802.1X authentication parameters on a terminal running the Windows 7 operating system before the first wired 802.1X authentication for the terminal.
Prerequisites
- Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wired AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
- By default, iMaster NCE-Campus uses TLSv1.2 as the RADIUS authentication transmission protocol. If the built-in client of Microsoft Windows 7 is used for 802.1X authentication, you need to perform the following operations to set the transmission protocol to TLSv1 or TLSv1.1:
- Log in to the controller as the system administrator, choose from the main menu, and click TLS Protocol Configuration.
- Select TLSv1-0 or TLSv1-1, and click Enable.
- Log in to iMaster NCE-Campus, choose from the main menu, enable RADIUS Authentication Transmission Protocol, select TLSv1 and TLSv1.1, and click OK.
Procedure
- Choose Start > Control Panel.
- On Control Panel, choose Network and Internet > Network and Sharing Center. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
- Click the local connection and choose Properties.
- Click the Authentication tab.
- Select Enable IEEE 802.1X authentication, set the network authentication method to PEAP, and click Settings.
![]()
- Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
If a RADIUS server certificate has been uploaded on the System > Terminal > Global Parameters > Access Management page, you can implement automatic certificate enrollment for terminals by referring to Configuring Group Policies on a AD server to Enable a Client to Automatically Obtain the Server Certificate. Alternatively, you can manually install the RADIUS server certificate on terminals, during which you can select Validate server certificate and then set Trusted Root Certification Authorities as required.
![]()
- Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
- When the confirm dialog box is displayed, enter the user name and password for authentication.
Microsoft Windows 8
This topic describes how to configure 802.1X authentication parameters on a terminal running the Windows 8 operating system before the first wired 802.1X authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wired AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
- Choose Start > Control Panel.
- On Control Panel, choose Network and Internet > Network and Sharing Center. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
- Click the local connection and choose Properties.
- Click the Authentication tab, select Enable IEEE 802.1X authentication, set the network authentication method to PEAP, and click Settings.
- Deselect Verify the server's identity by validating the certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
If a RADIUS server certificate has been uploaded on the System > Terminal > Global Parameters > Access Management page, you can implement automatic certificate enrollment for terminals by referring to Configuring Group Policies on an AD server to Enable a Client to Automatically Obtain the Server Certificate. Alternatively, you can manually install the RADIUS server certificate on terminals, during which you can select Verify the server's identity by validating the certificate and then set Trusted Root Certification Authorities as required.
- Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
- Return to the page in Step 4, and then click Additional settings.
- Select User authentication from the drop-down list below Specify authentication mode.
Microsoft Windows 10
This topic describes how to configure 802.1X authentication parameters on a terminal running the Windows 10 operating system before the first wired 802.1X authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wired AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
- Choose Start > Control Panel.
- On Control Panel, choose Network and Internet > Network and Sharing Center > View your active networks. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
- Click the local connection and choose Properties.
- Click the Authentication tab, select Enable IEEE 802.1X authentication, select Microsoft: Protected EAP (PEAP) from the drop-down list below Choose a network authentication method, select Fallback to unauthorized network access, and click Settings.
- Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
If a RADIUS server certificate has been uploaded on the System > Terminal > Global Parameters > Access Management page, you can implement automatic certificate enrollment for terminals by referring to Configuring Group Policies on an AD server to Enable a Client to Automatically Obtain the Server Certificate. Alternatively, you can manually install the RADIUS server certificate on terminals, during which you can select Verify the server's identity by validating the certificate and then set Trusted Root Certification Authorities as required.
- Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
- Return to the page in Step 4, and then click Additional settings.
Check the Specify authentication mode checkbox and select User authentication from the drop-down list box.
![]()
If Automatically use my Windows logon name and password (and domain if any) is selected in step 6, you can click Replace credentials to change the username and password for 802.1X authentication.
EAP-GTC Plug-In
About This Chapter
This document describes how to install the EAP-GTC plug-in on a terminal and use this plug-in to perform 802.1X authentication.
Overview
This section describes background information about the EAP-GTC plug-in.
The built-in 802.1X client of the Windows operating system does not support EAP-GTC. However, when iMaster NCE-Campus interconnects with the LDAP server or a third-party data source, the EAP-EAP-GTC protocol must be used.
The EAP-GTC plug-in is supported in the Windows 7, 8, and 10 operating systems.
End users are advised to update the Windows system security patch timely and scan for viruses and Trojan horses periodically to ensure terminal security.
Installing the EAP-GTC Plug-In
This section describes how to obtain and install the EAP-GTC plug-in.
Procedure
- Obtain the EAP-GTC plug-in.
- Visit http://support.huawei.com/enterprise, enter iMaster NCE-Campus in the search box under the Product Support tab, and click the Software & Tools tab on the displayed page.
- Choose the version number of the product and then click the corresponding software download link to download iMasterNCE-Campus_{version}_EAP-GTC-Tool_windows.zip to the local computer. Then, decompress the downloaded package.
- Double-click the obtained .exe file.
- Select the installation language and click OK.
![]()
- Click Next.
![]()
- Read the agreements, select I accept the terms in the License Agreement, and click Install.
![]()
- Restart the operating system after installation is complete.
![]()
Using EAP-GTC for 802.1X Authentication
The configuration of using EAP-GTC for 802.1X authentication is similar to that of the built-in 802.1X client authentication of the Windows operating system. The only difference is that you need to select Huawei EAP-GTC when configuring the PEAP protocol.
Context
For details on how to configure the built-in 802.1X client authentication of the Windows operating system, see Configuring the Standard 802.1X client Provided by the Operating System. This section uses the wireless authentication in the Windows 7 operating system as an example.
Procedure
- Choose Start > Control Panel, click Administrative Tools and Services.
Verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
- Choose Start > Control Panel.
- On Control Panel, choose Network and Internet > Manage Wireless Networks. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
- Click Add.
- Click Manually create a network profile. Set Network name to employee, Security type to WPA2-Enterprise, Encryption type to TKIP, and select Start this connection automatically.
![]()
- Click Next.
- Click Change connection settings.
- Click the Security tab, select Microsoft: Protected EAP (PEAP) from the drop-down list box of Choose a network authentication method, and click Settings.
![]()
- Set protected EAP attributes and click OK.
This step differs from the built-in 802.1X client authentication of the Windows operating system.
- (Optional) Select Validate server certificate and Trusted Root Certification Authorities. By default, the root certificate authority of the iMaster NCE-Campus is TSM. If you have replaced the RADIUS server certificate, select the root certificate authority accordingly.
Server certificate verification is recommended to ensure terminal access security.
- Select Huawei EAP-GTC from the drop-down list box of Select Authentication Method.
![]()
- (Optional) Select Validate server certificate and Trusted Root Certification Authorities. By default, the root certificate authority of the iMaster NCE-Campus is TSM. If you have replaced the RADIUS server certificate, select the root certificate authority accordingly.
- Click OK to return to the page in Step 8, and then click Advanced settings.
- Select User or computer authentication from the drop-down list box of Specify authentication mode.
![]()
- Select the SSID to be connected for 802.1X authentication and click Connect. In the displayed dialog box, enter the user name and password.
![]()
If authentication succeeds, the terminal connects to the network successfully and obtains an IP address. If authentication fails, a dialog box is displayed again, asking you to enter the user name and password. You can locate the fault according to Log. If you cannot locate the fault based on collected logs, contact technical support personnel.
Log
If authentication using EAP-GTC fails, you can locate the fault based on log files.
Logs of the EAP-GTC plug-in are saved in C:\Program Files\Huawei\EapGtcModule\log\eap-gtc.log.
The log format is as follows:
If authentication fails, find the fault cause in the log description.
Example:
- The following log indicates that the user passes the authentication.
INFOR 2015-09-17 10:18:55[11600|12168] : HandleRecvEapPacket :: Got EAPCODE_Success INFOR 2015-09-17 10:18:55[11600|12168] : HandleRecvEapPacket :: Authentication succeeded
- The following log indicates that the user fails the authentication because the password is incorrect.
INFOR 2015-09-17 10:18:55[11600|12168] : HandleRecvEapPacket :: Got EAPCODE_failure ERROR 2015-09-17 10:18:55[11600|12168] : HandleRecvEapPacket :: Authentication failed. Wrong password.
Uninstalling the EAP-GTC Plug-In
This section describes how to uninstall the EAP-GTC plug-in.
Procedure
- Choose Start > All Programs > EAP-GTC Module > Uninstall EAP-GTC Module.
![]()
- Click Yes.
![]()
- Click Next.
![]()
- Click Uninstall.
![]()
- Choose Reboot now and click Finish.
Restart the operating system after uninstallation is complete to completely delete related EAP-GTC plug-in information.
Association Between the iMaster NCE-Campus and a Third-Party Online Behavior Management Device to Implement SSO
SSO Overview
Single sign-on (SSO) indicates that end users can authenticated by both the Service Controller (SC) of the iMaster NCE-Campusand a third-party online behavior management device simultaneously. After an end user passes identity authentication and security check by the client of the iMaster NCE-Campus, the SC sends a login packet to the online behavior management device to complete authentication. After receiving this packet, the online behavior management device starts to manage the online behavior of the end user. When an end user deregisters on the client, the SC sends a logout packet to the online behavior management device to deregister on the device. After deregistration, the end user cannot access network resources.
To realize SSO, ensure that accounts are managed by the AD domain controller and have been synchronized to the iMaster NCE-Campus and online behavior management device.
The SC can send three types of packets to the online behavior management device: login packet, logout packet, and security status change packet.
- Login packet: When an end user passes identity authentication and security check by the client of the iMaster NCE-Campus, the SC sends a login packet to the online behavior management device. This packet contains basic user information, the IP address of the user terminal, and security check result. The online behavior management device determines whether to allow the end user to go online on it based on configured policies and information in the received login packet. If authentication succeeds on the online behavior management device, it grants network access permissions to the end user according to the identity authentication or security check result.
- Logout packet: When an end user deregisters on the client or an administrator forces the end user to go offline, the SC sends a logout packet to the online behavior management device. This packet contains the user name and IP address of the user terminal. After receiving this packet, the online behavior management device logs the user out and reclaims network access permissions.
- Security status change packet: When the client detects that the security status of an end user changes, it reports the event to the SC. The SC sends a security status change packet to the online behavior management device. This packet contains the user name, IP address of the user terminal, and security status. The online behavior management device grants network access permissions to the end user according to the configured policies and new security status.
- A security status change packet can also be regarded as a login packet because a user needs to be re-authenticated if its security status changes.
Packet Exchange Process Between the iMaster NCE-Campus and a Third-Party Online Behavior Management Device
The SC of the iMaster NCE-Campus exchanges packets with a third-party online behavior management device using the user datagram protocol/Internet Protocol (UDP/IP). UDP has low reliability, so the retransmission mechanism is used to ensure reliability. If the online behavior management device becomes faulty, the SC will attempt to send the login, logout, or security status change packet to the device multiple times, degrading the SC performance. To prevent this problem, the SC retransmits a UDP packet if it does not receive a UDP response packet within 3s. The SC can retransmit a UDP packet three times at most.
Packet Format
During the SSO implementation process, the SC of the iMaster NCE-Campus exchanges packets with a third-party online behavior management device using the UDP/IP protocol. Five types of packets can be exchanged between the SC and the online behavior management device, including the authentication success packet, deregistration success packet, authentication response packet, deregistration response packet, and online status query packet. The packet content and data organization mode vary with the packet type. The packet content is expressed in the Unicode character set, while characters are encoded using GBK.
Authentication Success (Login) Packet
This section describes the format of an authentication success (login) packet.
An authentication success packet is a login packet sent by the SC to the third-party online behavior management device after an end user passes authentication on the SC. The packet contains the packet type, version number, packet serial number, user IP address, user name, and user group. A login packet is triggered by authentication success or security status change. If the online behavior management device receives multiple packets from the same user, the latest packet takes effect.
Data Packet Format
Parameter Description
Parameter |
Type |
Description |
|---|---|---|
ucMsgType |
byte |
Message type. The length is 1 byte.
|
ucVersion |
byte |
Version number of the protocol. The length is 1 byte.
|
MAC |
string |
Terminal MAC address, consisting of six groups of hexadecimal numbers. The length is 48 bits. The default value is 000000000000. |
ulDataSerNumber |
int |
Packet serial number. The length is 4 bytes. |
ulUserIp |
int |
IP address of an end user. The length is 4 bytes. |
ulUserIpv6Number |
byte |
Number of IPv6 addresses of an end user in packets. The maximum value is 10 and the length is 1 byte. |
ulUserIpv6 |
string |
IPv6 address of an end user. The length is 16 bytes. |
szUserName |
string |
User name. The maximum length is 64 bytes. The value ends with \0. If the value contains more than 64 bytes, it will be intercepted. |
receiver |
string |
Name of the receptionist. The maximum length is 64 bytes. The value ends with \0. If the value contains more than 64 bytes, it will be intercepted. The default value is #\0. |
effectiveDate |
long |
Time when an account becomes effective. The length is 8 bytes. The default value is 0. |
expirationDate |
long |
Time when an account expires. The length is 8 bytes. The default value is 0. |
szGroupName |
string |
Role or department/user group. The length is not fixed. The value ends with \0.
|
Deregistration Success (Logout) Packet
This section describes the format of a deregistration success (logout) packet.
A deregistration success packet is a logout packet sent by the SC to the third-party online behavior management device after an end user deregisters on the SC. The packet contains the packet type, version number, packet serial number, user IP address, and user name.
Data Packet Format
Parameter Description
Parameter |
Type |
Description |
|---|---|---|
ucMsgType |
byte |
Message type. The length is 1 byte.
|
ucVersion |
byte |
Version number of the protocol. The length is 1 byte.
|
MAC |
string |
Terminal MAC address, consisting of six groups of hexadecimal numbers. The length is 48 bits. The default value is 000000000000. |
ulDataSerNumber |
int |
Packet serial number. The length is 4 bytes. |
ulUserIp |
int |
IP address of an end user. The length is 4 bytes. |
ulUserIpv6Number |
byte |
Number of IPv6 addresses of an end user in packets. The maximum value is 10 and the length is 1 byte. |
ulUserIpv6 |
string |
IPv6 address of an end user. The length is 16 bytes. |
szUserName |
string |
User name. The maximum length is 64 bytes. The value ends with \0. If the value contains more than 64 bytes, it will be intercepted. |
receiver |
string |
Name of the receptionist. The maximum length is 64 bytes. The value ends with \0. If the value contains more than 64 bytes, it will be intercepted. The default value is #\0. |
effectiveDate |
long |
Time when an account becomes effective. The length is 8 bytes. The default value is 0. |
expirationDate |
long |
Time when an account expires. The length is 8 bytes. The default value is 0. |
Authentication Response Packet
This section describes the format of an authentication response packet.
An authentication response packet is sent by the third-party online behavior management device to the SC to respond to the received authentication success packet.
This packet consists of a packet serial number and fixed character string "login OK", for example, 120102,"login OK".
If the third-party online behavior management device fails to process the authentication success packet received from the SC, the authentication response packet also contains an error code next to login OK with the delimiter | between them. Error code describes error code information.
Data Packet Format
Parameter Description
Parameter |
Type |
Description |
|---|---|---|
ulDataSerNumber |
int |
Packet serial number. The length is 4 bytes. NOTE:
The value must be the same as that of a login or logout packet. |
message |
string |
Printable message in the "login OK|2" format. The content before | is the message, and after | is the error code. NOTE:
The iMaster NCE-Campus only records these messages, and does not process them. |
Return Code |
Description |
|---|---|
1 |
The user is locked by the online behavior management device. |
2 |
The user is online now, and the maximum number of access terminals using the same account is configured on the online behavior management device. When a conflict occurs, the current online user is not forced offline. |
3 |
The user level does not meet requirements of the online behavior management device. |
4 |
The IP and MAC address binding of the user does not meet requirements of the online behavior management device. |
5 |
The user has logged in to the iMaster NCE-Campus. |
Deregistration Response Packet
This section describes the format of a deregistration response packet.
A deregistration response packet is sent by the third-party online behavior management device to the SC to respond to the received deregistration success packet.
This packet consists of a packet serial number and fixed character string "logout OK", for example, 120102,"logout OK".
If the third-party online behavior management device fails to process the deregistration success packet received from the SC, the deregistration response packet also contains an error code next to logout OK with the delimiter | between them. Error code describes error code information.
Data Packet Format
Parameter Description
Parameter |
Type |
Description |
|---|---|---|
ulDataSerNumber |
int |
Packet serial number. The length is 4 bytes. NOTE:
The value must be the same as that of a login or logout packet. |
message |
string |
Printable message in the "logout OK|2" format. The content before | is the message, and after | is the error code. NOTE:
The iMaster NCE-Campus only records these messages, and does not process them. |
Online Status Query Packet
This section describes the format of an online status query packet.
An online status query packet is sent by the third-party online behavior management device to the SC after the device receives a request from an unauthenticated user. If this user is online on the SC, the SC sends the user login information to the online behavior management device to ensure consistent online user information. If the user is not online on the SC, the online behavior management device does not process the request from the user.
The ports used to query the online user status on the RADIUS, Portal, and authentication server components of the SC are 8885, 8886, and 8887, respectively.
Data Packet Format
Parameter Description
Parameter |
Type |
Description |
|---|---|---|
serNumber |
int |
Serial number of an online status query packet. The length is 4 bytes. The first digit of a serial number packet indicates the type of the IP address carried in the message. The value 0 indicates IPv4 and the value 1 indicates IPv6. NOTE:
This parameter value must meet the following requirements:
|
message |
string |
IPv4: Printable message containing IPv4 addresses of the integer type. NOTE:
One packet can contain a maximum of 50 IP addresses, separated by commas (,). IPv6: Printable message containing IPv6 addresses of the integer type. NOTE:
One packet can contain a maximum of 50 IP addresses, each of which is in 16 bytes. Multiple IP addresses are not separated by commas (,). |
Packet Encryption Algorithm
Packets exchanged between the SC of the iMaster NCE-Campus and the third-party online behavior management device are encrypted using an AES or a 3DES shared key before being transmitted using UDP.
AES
The Advanced Encryption Standard (AES) algorithm has low security. Therefore, the more secure enhanced AES is recommended.
Algorithm
AES/CBC/NoPadding
Key
Packets exchanged between the iMaster NCE-Campus and third-party online behavior management device are encrypted using a shared key. The key length must be a multiple of 16. If the key length is not a multiple of 16, 0s are added to extend the key length to the minimum multiple of 16.
Vector
{0X17, 0X71, 0X6F, 0X56, 0X5B, 0X07, 0X1E, 0X34, 0X79, 0X52, 0X48, 0X63, 0X12, 0X32, 0X71, 0X76}
Data Padding
If the key length is not a multiple of 16, 0s are added to extend the key length to the minimum multiple of 16.
3DES
The Triple Data Encryption Standard (3DES) algorithm has low security. Therefore, the more secure enhanced AES is recommended.
Algorithm
DESede/CBC/NoPadding
Key
Shared key of the iMaster NCE-Campus and third-party online behavior management device. The key length must be 24 bits. If the key length is not 24 bits, 0s are added.
Vector
Byte array corresponding to the character string "Y#*j@dkh"
Data Padding
If the key length is not a multiple of 8, 0s are added to extend the key length to the minimum multiple of 8.
Enhanced AES
Algorithm
AES/CBC/NoPadding
Key
Key calculated using the PBKDF2WithHmacSHA1 algorithm on the shared key of the iMaster NCE-Campus and third-party online behavior management device. If the length of the exported shared key is 16 bits, 0s are added to extend the key length to 16 bits.
Vector
- IV1: random value for calculating the key
- IV2: random value for encrypting message in the packet
Data Padding
Bits |
|
|---|---|
Octets |
8 7 6 5 4 3 2 1 |
1 |
Version |
2 |
Encrypt Type |
3-4 |
Encrypt Length |
5-20 |
Encrypt IV1 |
21-36 |
Encrypt IV2 |
36-N |
Encrypt Record |
Parameter |
Description |
|---|---|
Version |
Version number of the packet. |
Encrypt Type |
Encryption type. |
Encrypt Length |
= Packet length - Packet header length (36 bytes) |
Encrypt IV1 |
Salt value in the key export function. The maximum value length is 16 bytes. |
Encrypt IV2 |
IV in the encryption algorithm. The maximum value length is 16 bytes. |
Encrypt Record |
Encrypted message. If the value length is not a multiple of 16, 0s are added to extend the key length to the minimum multiple of 16. |
- Authentication and Authorization Management
- Configuration Guide in Typical Scenarios
- Configuring User Access Without Authentication
- Password Authentication
- Portal Authentication
- Configuration Task Overview
- (Optional) Configuring an Account for an End User
- (Optional) Connecting to Third-Party Platforms
- (Optional) Enabling the HTTP Port
- (Optional) Enabling the Port for Outdated Device Certificates
- (Optional) Customizing a Portal Page Pushed to End Users
- Configuring a Portal Page Pushing Policy
- (Optional) Configuring an Online User Control Policy
- (Optional) Configuring a Portal Server Template
- (Optional) Configuring a RADIUS Server Template
- Configuring an Authentication Point
- Configuring an Authentication Rule
- Configuring an Authorization Result
- Configuring an Authorization Rule
- Multi-Network Portal Authentication
- 802.1X Authentication
- Configuring a User Group and User
- (Optional) Attaching a Role to an Account
- Setting Basic Parameters
- (Optional) Configuring an Online User Control Policy
- (Optional) Configuring a Policy Element
- Configuring a RADIUS Template
- Configuring an Authentication Point
- Configuring an Authentication Rule
- Configuring an Authorization Result
- Configuring an Authorization Rule
- MAC Address Authentication
- PSK+MAC Address Authentication
- Two-Factor Authentication
- iMaster NCE-Campus as a Relay Agent
- Interconnection with a Third-Party Authentication Server
- HWTACACS Authentication
- Device Administrator Authentication
- Secure Access for IoT Access Control Terminals
- Configuring Secure Access for Cellular Network Terminals (IoT)
- Guest Management
- Configuring a Guest Administrator
- Configuring Guest Access Through Self-Registered Accounts
- Configuring Guest Access Through One-Click Authentication by Account, Email Address, or Mobile Number
- Configuring Guest Access Using a Public QR Code
- Configuring Guest Access Using Accounts Created by Administrators
- Configuring Guest Access Using a Facebook Account
- Configuring Guest Access Using a Twitter Account
- Configuring Guest Access Through One-Click WeChat Portal Authentication
- Configuring Guests to Obtain an Authentication URL by Following a WeChat Official Account (Editing Mode)
- Configuring Guests to Obtain an Authentication URL by Following a WeChat Official Account (in Developer Mode)
- Overview
- Setting Up a WeChat Official Accounts Platform Server Using the PHP Application
- Binding a WeChat Official Account to the Enterprise WeChat Official Accounts Platform Server
- Setting Parameters for Connecting the Enterprise WeChat Official Accounts Platform Server to iMaster NCE-Campus
- Configuring iMaster NCE-Campus
- Appendix - Secondary Development of the WeChat Official Accounts Platform
- Configuring Guest Access Through QR Code Scanning Using the WeChat APP via Wi-Fi
- Account Blacklist Management
- CA Management
- Boarding Configuration
- AD/LDAP Synchronization
- Overview
- Synchronization by OU for the AD/LDAP Server
- Synchronization by Group for the AD Server (Organization Structure Is Described by OU)
- Synchronization by Group for the AD Server (Organization Structure Is Described by Group)
- Synchronization by Group for the LDAP Server
- Synchronization by Plane Structure or User-defined Synchronization
- Synchronization by Conditions
- Configuring Non-Synchronization
- Authentication Using a RADIUS Token Server
- Authentication Using a Third-Party HTTP Server
- Authentication Using a Third-Party Database
- SSO Through Interconnection with AD FS
- Configuring Online Behavior Management
- Configuring a RADIUS Accounting Device
- Managing Admission Devices
- Region Management
- Terminal Management
- MDM Interconnection
- Appendix