User Authentication USG Firewall

11/24/2019 User Authentication
Contents
14 User Authentication
14.1 Web: Example for Configuring Local Authentication on Internet Access Users
14.2 Web: Example for Configuring Authentication Exemption for Internet Access Users (Bidirectionally Binding Users to IP and MAC Addresses)
14.3 Web: Example for Configuring AD SSO for Internet Access Users (Plug-In Mode)
14.4 Web: Example for Configuring AD SSO for Internet Access Users (No-Plug-In Mode)
14.5 Web: Example for Configuring TSM SSO for Internet Access Users (Users Proactively Access the Controller)
14.6 Web: Example for Configuring TSM SSO for Internet Access Users (Users' HTTP Services Are Redirected to the Controller)
14.7 Web: Example for Configuring RADIUS SSO for Internet Access Users
14.8 Web: Example for Configuring a RADIUS Server to Implement Authentication on Internet Access Users
14.9 Web: Example for Configuring an LDAP Server to Implement Authentication on Internet Access Users
14.10 Web: Example for Online Querying and Referencing the Specified Users/User Groups on the AD Server Using Security Policies
14.11 Web: Example for Configuring Authentication on Users at the Headquarters and Branch Offices Using an AD Server
14.12 CLI: Example for Configuring Local Authentication on Internet Access Users
14.13 CLI: Example for Configuring Authentication Exemption for Internet Access Users (Bidirectionally Binding Users to IP and MAC Addresses)
14.14 CLI: Example for Configuring AD SSO for Internet Access Users (Plug-In Mode)
14.15 CLI: Example for Configuring AD SSO for Internet Access Users (No-Plug-In Mode)
14.16 CLI: Example for Configuring TSM SSO for Internet Access Users (Users Proactively Access the Controller)
14.17 CLI: Example for Configuring TSM SSO for Internet Access Users (Users' HTTP Services Are Redirected to the Controller)
14.18 CLI: Example for Configuring RADIUS SSO for Internet Access Users
14.19 CLI: Example for Configuring a RADIUS Server to Implement Authentication on Internet Access Users
14.20 CLI: Example for Configuring an LDAP Server to Implement Authentication on Internet Access Users
14.21 CLI: Example for Configuring Authentication on Users at the Headquarters and Branch Offices Using an AD Server
14 User Authentication
This section describes how to configure local authentication for Internet access users when a FW works as an egress gateway.
14.2 Web: Example for Configuring Authentication Exemption for Internet Access Users (Bidirectionally Binding Users to IP
and MAC Addresses)
This section describes how to configure authentication exemption for high-level executives and implement user-specific permission
management when a FW works as an egress gateway.
This section provides an example for configuring AD Single Sign On (SSO) for Internet access users when a FW works as an egress
gateway. In this example, the ADSSO_Setup.exe must be installed on the AD monitor (any computer in the AD domain, including the
AD domain controller) and the login/logout scripts need to be set on the AD domain controller and delivered to PCs.
14.4 Web: Example for Configuring AD SSO for Internet Access Users (No-Plug-In Mode)
This section describes how to configure AD Single Sign On (SSO) for Internet access users when a FW works as an egress gateway. In
this mode, the SSO program is not installed on the AD domain controller.
14.5 Web: Example for Configuring TSM SSO for Internet Access Users (Users Proactively Access the Controller)
This section describes how to configure TSM (Policy Center or Agile Controller) Single Sign On (SSO) for Internet access users when a
FW works as an egress gateway. In this scenario, users proactively access the TSM portal authentication page and are authenticated
before accessing services.
14.6 Web: Example for Configuring TSM SSO for Internet Access Users (Users' HTTP Services Are Redirected to the
Controller)
FW works as an egress gateway. In this scenario, the FW redirects user HTTP requests to the TSM portal authentication page when an
unauthenticated user attempts to access HTTP services. After successful authentication, users can access services.
https://support.huawei.com/view/contentview/getFileStream?mid=SUPE_DOC&viewNid=EDOC1000118199&nid=EDOC1000118199&partNo=j00h&t… 1/92
This section describes how to configure RADIUS Single Sign On (SSO) for Internet access users when a FW works as an egress
gateway.
14.8 Web: Example for Configuring a RADIUS Server to Implement Authentication on Internet Access Users
This section describes how to configure RADIUS server authentication for Internet access users when a FW works as an egress gateway.
14.9 Web: Example for Configuring an LDAP Server to Implement Authentication on Internet Access Users
This section describes how to configure a Sun ONE LDAP server to authenticate Internet access users when a FW works as an egress
gateway.
14.10 Web: Example for Online Querying and Referencing the Specified Users/User Groups on the AD Server Using Security
Policies
14.11 Web: Example for Configuring Authentication on Users at the Headquarters and Branch Offices Using an AD Server
This section provides an example for configuring authentication on Internet access users and remote access users when a FW works as
an egress gateway and VPN access gateway.
14.13 CLI: Example for Configuring Authentication Exemption for Internet Access Users (Bidirectionally Binding Users to IP
and MAC Addresses)
This section provides an example for configuring AD Single Sign On (SSO) for Internet access users when a FW works as an egress
gateway. In this example, the ADSSO_Setup.exe must be installed on the AD monitor (any computer in the AD domain, including the
AD domain controller) and the login/logout scripts need to be set on the AD domain controller and delivered to PCs.
14.15 CLI: Example for Configuring AD SSO for Internet Access Users (No-Plug-In Mode)
This section describes how to configure AD Single Sign On (SSO) for Internet access users when a FW works as an egress gateway. In
this mode, the SSO program is not installed on the AD domain controller.
14.16 CLI: Example for Configuring TSM SSO for Internet Access Users (Users Proactively Access the Controller)
FW works as an egress gateway. In this scenario, users proactively access the TSM portal authentication page and are authenticated
before accessing services.
14.17 CLI: Example for Configuring TSM SSO for Internet Access Users (Users' HTTP Services Are Redirected to the
Controller)
FW works as an egress gateway. In this scenario, the FW redirects user HTTP requests to the TSM portal authentication page when an
This section describes how to configure RADIUS Single Sign On (SSO) for Internet access users when a FW works as an egress
gateway.
14.19 CLI: Example for Configuring a RADIUS Server to Implement Authentication on Internet Access Users
14.20 CLI: Example for Configuring an LDAP Server to Implement Authentication on Internet Access Users
This section describes how to configure a Sun ONE LDAP server to authenticate Internet access users when a FW works as an egress
gateway.
14.21 CLI: Example for Configuring Authentication on Users at the Headquarters and Branch Offices Using an AD Server
This section provides an example for configuring authentication on Internet access users and remote access users when a FW works as
an egress gateway and VPN access gateway.
Networking Requirements
An enterprise has deployed a FW as the egress gateway to connect the intranet to the Internet, as shown in Figure 14-1.
Internet access users include R&D employees, marketing employees, and guests. All of them dynamically obtain IP addresses.
Figure 14-1 Local authentication of Internet access users
The user management and authentication mechanisms of the FW must identify IP addresses on the intranet as users to implement user-specific
behavior control and permission assignment. Requirements are as follows:
Information about users and departments must be saved on the FW and must be referenceable by policies.
R&D employees and marketing employees must be authenticated by the FW.
Guests must be authenticated by the FW and can only use specified guest accounts to access network resources.
Redirected authentication must be implemented for guests. When an unauthenticated guest uses a browser to access a web page, the
FW redirects the guest to an authentication page. After the guest is authenticated, the browser displays the requested web page.
Configuration Roadmap
The configuration roadmap is as follows:
1. Create authentication policies and configure matching conditions and actions.

2. Configure the access control for authentication domain default as online behavior management.
3. Create user groups and users and set passwords for the users.
4. Configure a security policy to allow users to access authentication web pages.
Data Planning
Item Data Description
R&D employee Group Add each R&D employee to group research.

Name: research You can repeat the operations in this example to configure
Parent Group: /default multiple user accounts.
User
Login Name: user_0001
Display Name: Tom
Parent Group: /default/research
Password/Confirm Password:
Admin@123
Prohibit Users from Sharing This
Account
Marketing employee Group Add each marketing employee to group marketing.

Name: marketing You can repeat the operations in this example to configure
User
Display Name: Jack
Parent Group: /default/marketing
Admin@123
Account
Guest Group All guests use the guest account for authentication.
Name: /default
User
Login Name: guest
Parent Group: /default
Admin@123
Allow Users to Share This
Account
Authentication policy Name: policy_auth_01 Authentication is implemented on R&D employees,

Source Zone: Trust marketing employees, and guests who meet the matching
conditions.
Destination Zone: Any
R&D employees, marketing employees, and guests can
Source Address/Region:
access network resources only after being authenticated by a
10.3.0.0/24
FW.
Destination Address/Region: Any
Action: Portal authentication
Authentication domain Name: default The default authentication domain is used during
Access Control: Online behavior authentication. The user names for R&D employees,
management marketing employees, and guests do not require an
authentication domain.
Procedure
1. Choose Network > Interface. Set IP addresses for the interfaces and assign the interfaces to security zones.
The following example describes how to configure interface GigabitEthernet 1/0/3. You can configure other interfaces based on the
networking diagram.
Zone Trust
IP Address 10.3.0.1/24
2. Choose Object > User > Authentication Policy and click Add to create an authentication policy.
3. Choose Object > User > default and configure local authentication.
Click Add and create user groups and users.
a. Choose Add Group and create a user group object for an R&D employee.
b. Choose Add a User and create a user object for an R&D employee.
c. Repeat the previous steps to create the user group marketing and user account user_0002 for the marketing department
and a guest account guest.
d. Click Apply.
4. Choose Object > User > Authentication Option and configure the authentication page to redirect to the previously accessed page
after authentication.
In Global Configuration, set Redirection Setting After Successful Authentication as Redirect to the latest Web page and click
Apply.
5. Choose Policy > Security Policy > Security Policy and click Add to configure security policies.
a. Configure a security policy to allow users to access the authentication page.
Name policy_sec_01
Source Zone Trust
Destination Zone Local
Source Address 10.3.0.0/24
Service User-defined service (TCP/8887)
Action Permit
b. Configure a security policy to allow users to access the Internet.
Name policy_sec_02
Source Zone Trust
Destination Zone Untrust
Action Permit
NOTE:
Enable the DNS service from the Trust zone to the Untrust zone to allow HTTP domain name resolution packets to pass through.
c. Configure a security policy to allow users to access the server cluster.
Name policy_sec_03
Source Zone Trust
Destination Zone DMZ
Action Permit
6. After this configuration is complete, you can configure security policies, PBR policies, bandwidth policies, quota control policies,
proxy policies, and audit policies that reference the user and user group objects.
Verification
Verify that the following conditions are true:

When the R&D employee Tom accesses www.example.org, the web browser is redirected to an authentication page. The
R&D employee then enters user name user_0001 and password Admin@123 for authentication. After the R&D employee
is authenticated, the web browser is redirected to www.example.org.
When the marketing employee Jack accesses www.example.org, the web browser is redirected to an authentication page.
The marketing employee then enters user name user_0002 and password Admin@123 for authentication. After the
marketing employee is authenticated, the web browser is redirected to www.example.org.
When a guest accesses www.example.org, the web browser is redirected to an authentication page. The guest then enters
user name guest and password Admin@123 for authentication. After the guest is authenticated, the web browser is
redirected to www.example.org.
Before accessing non-HTTP servers, such as FTP servers, employees and guests must access the authentication page at
https://10.3.0.1:8887 for authentication. The IP address of the authentication page must be that of the interface on the FW and must
be reachable to users.
On the FW, choose Object > User > Online User to see information about online users.
Configuration Scripts
#
sysname FW
#
user-manage redirect
#
interface GigabitEthernet1/0/1
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
add interface GigabitEthernet1/0/3
#
firewall zone untrust
#
firewall zone dmz
#
aaa
#
domain default
service-type internetaccess
internet-access mode password
#
#
security-policy
rule name policy_sec_01
source-zone trust
source-address 10.3.0.0 24
destination-zone local
service protocol tcp destination-port 8887
action permit
source-zone trust
destination-zone untrust
action permit
source-zone trust
destination-zone dmz
action permit
#
auth-policy
rule name policy_auth_01
source-zone trust
action auth
# The following user/group creation configuration is stored in the database, but not in the configuration profile.
user-manage group /default/research
user-manage group /default/marketing
user-manage user user_0001
alias Tom
parent-group /default/research
password *********
undo multi-ip online enable
alias Jack
parent-group /default/marketing
password *********
user-manage user guest
parent-group /default
password *********
14.2 Web: Example for Configuring Authentication Exemption for Internet Access
Users (Bidirectionally Binding Users to IP and MAC Addresses)
behavior control and permission assignment.
High-level executives use the fixed IP address 10.3.0.2. To improve efficiency, these executives are exempted from authentication. However,
for security considerations, their accounts must be bound to IP addresses and MAC addresses. This ensures that executives can use only the
specified IP and MAC addresses to access network resources.
Figure 14-2 Authentication exemption for Internet access users
1. Create an authentication policy and configure the matching conditions and authentication action.
2. Set the access control for authentication domain default to Online behavior management.
3. Create a user group and user objects for executives and bidirectionally bind the user objects to IP and MAC addresses.
4. Configure security policies.
Data Planning
Executive Group Add the executive to the group manager and configure
Name: manager bidirectional binding for the account and the IP and MAC
addresses. No password is required for the executive. A FW
authenticates the executive based on the bound IP and MAC
User addresses.
Login Name: user_0001 You can repeat the operations in this example to configure
Display Name: Supervisor multiple user accounts.
Parent Group: /default/manager
Account
IP/MAC Binding: Bidirectional
binding
IP/MAC Address: 10.3.0.2/aaaa-
bbbb-cccc
Authentication policy Name: policy_auth_01 Executives who meet the matching conditions can access
Source Zone: Trust network resources without being authenticated.
10.3.0.2/32
Action: Authentication exemption
Authentication domain Name: default -

Access Control: Online behavior
management
Procedure
networking diagram.
Zone Trust
2. Choose Object > User > Authentication Policy and click Add to configure authentication policies.
NOTE:
If an authentication policy for common employees is required, the authentication policy for subnet 10.3.0.2/32 must be configured prior to that for subnet
10.3.0.2/24. Otherwise, executives cannot match the authentication exemption policy.
3. Choose Object > User > default and configure authentication exemption.
Click Add and create user groups and users.
a. Choose Add Group and create a user group object for executives.
b. Choose Add a User and create a user object for an executive.
As authentication-exempted users do not use passwords, their passwords can be set to any value.
c. Click Apply.
a. Configure a security policy to allow users to access the Internet.
Name policy_sec_02
Source Zone Trust
Action Permit
b. Configure a security policy to allow users to access the server cluster.
Name policy_sec_03
Source Zone Trust
Action Permit
Verification
Verify that the executive A can access network resources without authentication and that other users cannot use the executive user
name to access network resources because their IP addresses are not 10.3.0.2 and their MAC addresses are not aaaa-bbbb-cccc.
#
sysname FW
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
#
domain default
internet-access mode auto-online
#
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action exempt-auth
#The following user/group creation configuration is stored in the database, but not in the configuration profile.
user-manage group /default/manager
alias Supervisor
parent-group /default/manager
bind mode bidirectional
bind ipv4 10.3.0.2 mac aaaa-bbbb-cccc
This section provides an example for configuring AD Single Sign On (SSO) for Internet access users when a FW works as an egress gateway.
In this example, the ADSSO_Setup.exe must be installed on the AD monitor (any computer in the AD domain, including the AD domain
controller) and the login/logout scripts need to be set on the AD domain controller and delivered to PCs.
The AD identity authentication mechanism is enabled on the intranet, and information about users and user group is saved on an AD
server.
Internet access users on the intranet include R&D employees and marketing employees.
Figure 14-3 AD SSO for Internet access users (the ADSSO_Setup.exe is installed to receive messages from PCs)
Information about users and departments is saved on the FW and can be referenced by policies.
R&D employees and marketing employees use domain accounts to log in to AD domains and access network resources. R&D
employees and marketing employees are identified by the user names they use to log in to AD domains.
If the domain accounts of new employees have been created on an AD server but not stored on a FW, the FW automatically imports
their information based on the organizational structure on the AD server after authenticating them.
NOTE:
ADSSO_Setup.exe has two working mode: the mode of receiving messages from PCs and the mode of querying security logs of the AD server. In the mode of querying
security logs of the AD server, only user login messages can be obtained, but user logout messages cannot be obtained. In the mode of receiving messages from PCs, user
logout messages can be obtained, ADSSO_Setup.exe needs to be installed, and login & logout scripts need to be deployed on the AD domain controller, and the login PCs
can only be Windows systems. Set the working mode of ADSSO_Setup.exe as required.
NOTE:
This example describes only how to configure user management and authentication.
When AD SSO is enabled, install the AD SSO service program ADSSO_Setup.exe on the AD monitor (any computer in the AD domain, including the AD
domain controller). The service program can obtain the relevant user information upon user login and logout and send the information to the FW. In this
example, a PC in the domain is used as the AD monitor. If the AD monitor is the AD domain controller, install ADSSO_Setup.exe on the AD domain controller
and configure the AD monitor address as the address of the AD domain controller.
In the example, both users and user groups on the AD server are imported to the FW. If there are a large number of users on a live network, you can import only
user groups and control user permissions by user groups.
1. On a FW, set the parameters for communication with an AD server.

2. Configure an authentication domain on the FW. The domain name must be the same as that on the AD server.
3. Configure a policy to import user information from the AD server to the FW.
4. Configure the new user option of the authentication domain. If an authenticated user does not exist on the FW, the FW imports the
user based on the import policy.
5. Set SSO parameters for the FW to receive user login and logout messages sent from the AD monitor.
6. Configure an authentication policy whose action is authentication exemption on the FW.
7. To prevent repeated login to the domain for authentication because of frequent timeouts during the working hours (8 hours), you
need to set the user online timeout duration to 480 minutes.
8. Enable the AD SSO service (by installing ADSSO_Setup.exe) on an AD monitor, configure the login and logout scripts on the AD
domain controller, and deliver the scripts using group policies.
Data Planning
AD server Name: auth_server_ad On a FW, set the parameters for communication with an AD
Primary Authentication Server IP: server.
10.3.0.251 The parameter settings on the FW must be consistent with
Port: 88 those on the AD server.
Primary Server Host Name:
ad.cce.com
Base DN/Port DN: dc=cce,
dc=com
LDAP Port: 389
Administrator DN:
cn=administrator,cn=users
Administrator Password:
Admin@123
User information import policy Name: policy_import Import users from the AD server to the FW.
Server Type: AD
Server Name: auth_server_ad
Import Type: Import both users
and user groups
Target User Group: /cce.com
Incremental Synchronization: 120
minutes
Overwrite local user records when
the current user exists
AD SSO (FW) AD SSO: Enable Set SSO parameters on the FW and configure the FW to
Mode: Installing AD SSO service receive the user login and logout information from the AD
program monitor.
Shared Key: Admin@234
AD SSO service (ADSSO_Setup.exe AD Server Parameter Set the parameters of the AD server on the AD monitor for
program, installed on the AD monitor) AD Server IP: 10.3.0.251 the AD monitor to connect to the AD server for checking
user information after receiving user login/logout messages
Administrator Account:
from the client computer.
cce.com\administrator
Password: Admin@123
FW Parameter Enable the AD SSO service on the AD monitor, configure

IP Address: 10.3.0.1 the AD monitor to listen to information about user login and
logout, and send the information to the FW.
Device Listening Port of the AD
SSO service: 8000 The parameters must be the same as those on the FW.
Device Shared Key: Admin@234
Client Communication Parameter The service listening port is an open port of the
Service Listening Port of the AD AD monitor and is used to receive user
SSO service: 12345 login/logout information from client computers.
Anti-Replay Time Window: 1800s The client shared key is the shared key for
(default value) encrypting the communication packets between
Client Shared Key: Admin@123 the client computer and AD monitor and must be
the same as the key configured on the AD domain
controller when login/logout scripts are
configured.
The anti-replay time is the time that the AD
monitor used to check unauthorized client login. If
the interval between the last client login recorded
on the AD domain controller and the last login that
the AD monitor receives from the client exceeds
the anti-replay time, the AD monitor considers the
client login unauthorized and does not send the
client login/logout information to the FW.
AD domain controller (the login and logout IP Address: 10.3.0.254 Run the login and logout scripts on an AD domain
scripts) Listening Port: 12345 controller. If a group policy is used to control the user login
and logout, run the login and logout scripts respectively and
Client Shared Key: Admin@123
send the login and logout information to the AD SSO
service.
The parameters must be the same as those on the
ADSSO_Setup.exe.
Procedure
1. Choose Network > Interface, set IP addresses for interfaces and assign the interfaces to security zones.
networking diagram.
Zone trust
2. Choose Policy > Security Policy > Security Policy, click Add to configure security policies.
https://support.huawei.com/view/contentview/getFileStream?mid=SUPE_DOC&viewNid=EDOC1000118199&nid=EDOC1000118199&partNo=j00h… 10/92
a. Configure security policies between the Trust (AD server and AD monitor) and Local zone to ensure the communication
among the FW and AD server.
Name local_policy_ad_01
Source Zone local
Destination Zone trust
Destination Address 10.3.0.251/32,10.3.0.254/32
Action Permit
Source Zone trust
Destination Zone local
Source Address 10.3.0.251/32,10.3.0.254/32
Action Permit
Name policy_sec_02
Source Zone trust
Destination Zone untrust
Action Permit
Name policy_sec_03
Source Zone trust
Destination Zone dmz
Action Permit
3. On a FW, choose Object > Authentication Server > AD, click Add to set the parameters for communication with an AD server.
The parameter settings on the FW must be consistent with those on the AD server.
Click Detect. In the dialog box that is displayed, click OK and enter the user name and password that are configured on the AD
server. Click Start Checking to check the connectivity to the AD server.
If you are unfamiliar with the AD server and cannot provide the server name or Base DN values, you can use the AD Explorer
software downloaded from Internet to connect to the AD server to query the attribute values. The mappings between the server
attributes and parameters on the FW are as follows.
4. On a FW, choose Object > User > Authentication Domain, click Add to create an authentication domain.
5. On a FW, choose Object > User > User Import > Server Import, click Add to configure a policy to import user information from
the AD server to the FW.
NOTE:
If the server has many users or user groups, some users or user groups under the basedn may not be imported to the FW because the number of users
or user groups exceeds the FW's specification. Therefore, you are advised to click Select on the right of Server Import Location to select an import
range.
In this example, users and user groups are imported to the FW. The user and user group filtering conditions in this example use the default values
(&(|(objectclass=person)(objectclass=organizationalPerson))(cn=*)(!(objectclass=computer))) and (|(objectclass=organizationalUnit)(ou=*)).
If you need to import user groups only, set Import Type to Import only user groups and set the new user option in 6 to Consider new users as
temporary users and do not add them to the local user list. Authenticated users use the permissions of their owning groups.
6. Choose Object > User > cce.com, configure AD SSO and click Apply.
https://support.huawei.com/view/contentview/getFileStream?mid=SUPE_DOC&viewNid=EDOC1000118199&nid=EDOC1000118199&partNo=j00h&… 11/92
Click Configure on the right of Server Import Policy. A dialog box is displayed. Click Import Immediately corresponding to
policy_import. After the import is complete, the user groups and users on the AD server are displayed in User/User
Group/Security Group Management List.
7. Choose Object > User > Authentication Policy, click Add to create an authentication policy.
NOTE:
If the action of the authentication policy is set to authentication exemption, the FW obtains user information through SSO and permits the traffic when user
information fails to be obtained during SSO authentication. If the network has high security requirements, set the action of the authentication policy to portal
authentication. Then the FW will implement portal authentication on the users failing the SSO authentication.
If the packets exchanged between the user and the AD server, between the user and the AD monitor, and between the AD monitor and the AD server pass
through the FW, ensure that the authentication policy on the FW does not authenticate these packets and the security policy allows them through. You can
choose Object > User > Authentication Policy to check the authentication policy.
8. Choose Object > User > Authentication Option, set the online user timeout duration to 480 minutes.
9. In the 6 authentication domain window, download the AD SSO program to your PC, decompress the program package, and copy
ADSSO_Setup.exe to the AD monitor.
10. Deploy the AD SSO service on the AD monitor.
You must use an account that belongs to the Administrators group to log in to the AD monitor.
a. Double-click ADSSO_Setup.exe. In the dialog box that is displayed, select English as the installation wizard language
and click OK. The installation wizard is then displayed in English.
b. Click Next and specify an installation directory, click Install.
c. Start the ADSSO Agent program.
d. Configure AD SSO parameters.
i. Configure the parameters for the AD SSO program to receive messages from PCs and the shared key used by
the AD SSO program to communicate with the FW.
NOTE:
When an AD SSO service program monitors login messages of multiple AD servers in a domain forest, set Anti-replay Time to 0
and disable the anti-replay function. The anti-replay function detects the difference between the time at which the AD SSO service
program receives a user login message and the time at which the user actually logs in to the AD server. If the time difference exceeds
the anti-replay time, the user is prohibited from logging in to the FW. In a scenario where multiple AD servers exist, different users
are authenticated by various AD servers. The AD SSO program will connect to multiple AD servers in turn to obtain user login
time.This causes the time difference to exceed Anti-replay Time. Therefore, you shall disable the anti-replay function.
Make sure that the port (port 12345 in this example) you intend to use is not occupied by other services. Choose Start > Run on the
AD domain controller, enter cmd, and run netstat -ano|findstr 12345. If no information is returned, port 12345 is not occupied by
other services. Otherwise, the system displays a message indicating the process ID of the service occupying the port. You are advised
to release this port or specify another idle port for the AD SSO service.
SSO is enabled on all OUs by default. When the AD SSO program is installed on the AD domain controller, filtering by OU is
supported. Click Set FilterGroup and enter the OU for which SSO will be enabled. Four OUs can be configured. You can specify
three levels for each OU. For example, OU1=research,OU2=software indicates that SSO is enabled for /research/software.
ii. Add AD servers.

The AD SSO program supports a maximum of 16 AD servers. It can connect to multiple AD servers to query
login user information until it queries required information.
iii. Add FWs.
The SSO program supports a maximum of five FWs and sends user login/logout messages to the FWs.
NOTE:
When the FWs work in hot standby scenarios, you need to set Device Address to the virtual IP address of the VRRP group where the
interfaces reside, so that the SSO service can send user login messages to the standby device during an active/standby FW switchover.
iv. Start the SSO service.

You can right-click the AD SSO icon in the system tray on your desktop to start or stop the AD SSO service.
Alternatively, click Show Log on the home page to view program operating logs and SSO service logs.
11. On the AD domain controller, add script ReportLogin.exe to the logon script (Logon.exe) and logoff script (Logoff.exe)
respectively, and set the parameters of the logon and logoff scripts so that the AD SSO service can monitor the logon and logoff
operations of domain users. You can obtain script file ReportLogin.exe from the Script folder in the installation directory of the
AD SSO on the AD monitor.
NOTE:
You must use an account that belongs to the Administrators group to log in to the AD domain controller. In this example, the Windows Server 2003 and
Windows 2008 Server are used as an AD domain controller.
a. Access the group policy management page and locate logon and logoff scripts. The steps for accessing the group policy
management page and the paths of logon and logoff scripts differ on Windows 2003 Server, Windows 2008 Server and
Windows 2012 Server. Details are as follows:
Windows 2003 Server
i. Choose Start > All Programs > Administrator Tools > Active Directory Users and Computers. Then run
the Active Directory Users and Computers tool, as shown in Figure 14-4.
Figure 14-4 Directory structure on an AD server
ii. Right-click the domain (cce.com as an example) that requires SSO and select ProPerties. In the dialog box that
is displayed, click the Group Policy tab, as shown in Figure 14-5.
Figure 14-5 Domain properties configuration window
iii. Double-click Default Domain Policy to open the domain policy configuration window.
iv. Choose User Configuration > Windows Settings > Scripts(Logon/Logoff), as shown in Figure 14-6.
Figure 14-6 Group policy configuration window
Windows 2008 Server and Windows 2012 Server
i. Choose Start > Administrative Tools > Group Policy Management.

ii. Right-click Default Domain Policy under the domain to which SSO authentication is to be applied, and choose
Edit, as shown in Figure 14-7.
Figure 14-7 Group policy management
iii. Choose User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff), as shown in Figure
14-8.
Figure 14-8 Configuring the default domain policy
b. Double-click Logon to access the login script configuration window, as shown in Figure 14-9.
Figure 14-9 Login script configuration window
c. In the login script configuration window, click ShowFiles... and copy ReportLogin.exe to the directory that is displayed.
Then close the directory.
d. In the login script configuration window, click Add, add login script ReportLogin.exe, and set the script parameters, as
shown in Figure 14-10. Then click OK.
When adding the user login script, click Browse in Figure 14-10 and select ReportLogin.exe in the directory displayed in
11.c.
Figure 14-10 Adding ReportLogin.exe as the login script
NOTE:
The parameters are separated by spaces.
In the example, the IP address of the AD SSO service is the IP address (10.3.0.254) of the AD monitor.
The service port must the same as the Port value specified in 10 when you install ADSSO_Setup.exe. The port number in this example
is 12345.
The client shared key must the same as the Client Shared Key value specified in 10 when you install ADSSO_Setup.exe. The port
number in this example is Admin@123.
0 indicates a login script. To configure a logout script, set this parameter to 1.
e. Configure the logout script by referring to steps 11.b and 11.d. The login and logout scripts are both ReportLogin.exe but
are saved in different folders.
f. Choose Start > Run, enter cmd to open the CLI, and run gpupdate to apply the policy.
12. After the configuration is complete, you can configure security policies, PBR policies, bandwidth policies, quota control policies,
Verification

R&D employees use domain accounts to log in to AD domains and access network resources through the FW. They can
access network resources only after successful logins.
Marketing employees use domain accounts to log in to AD domains and access network resources through the FW. They
can access network resources only after successful logins.
#
sysname FW
#
user-manage online-user aging-time 480
user-manage single-sign-on ad
enable
plug-in shared-key %$%$B2N*$eJ0;'Nn'#ATC]t+Rri`%$%$
#
ad-server template auth_server_ad
ad-server authentication 10.3.0.251 88
ad-server authentication base-dn dc=cce,dc=com
ad-server authentication manager cn=administrator,cn=users %$%$M#._~J4QrR[kJu7PUMtHUqh_%$%$
ad-server authentication host-name ad.cce.com
ad-server authentication ldap-port 389
ad-server user-filter sAMAccountName
ad-server group-filter ou
#
security-policy
rule name local_policy_ad_01
source-zone local
destination-zone trust
destination-address 10.3.0.251 32
action permit
source-zone trust
action permit
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
rule name auth_policy_service
source-zone trust
action exempt-auth
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
user-manage import-policy policy_import from ad
server template auth_server_ad
server basedn dc=cce,dc=com
server searchdn ou=marketing,dc=cce,dc=com
server searchdn ou=research,dc=cce,dc=com
destination-group /cce.com
user-attribute sAMAccountName
user-filter (&(|(objectclass=person)(objectclass=organizationalPerson))(cn=*)(!(objectclass=computer)))
group-filter (|(objectclass=organizationalUnit)(ou=*))
import-type user-group
import-override enable
sync-mode incremental schedule interval 120
#
aaa
domain cce.com
internet-access mode single-sign-on
new-user add-local group /cce.com auto-import policy_import
# The following configuration is used to perform a one-time operation and not stored in the configuration profile.
execute user-manage import-policy policy_import
test-aaa testname testpassword ad-template auth_server_ad
14.4 Web: Example for Configuring AD SSO for Internet Access Users (No-Plug-In
Mode)
This section describes how to configure AD Single Sign On (SSO) for Internet access users when a FW works as an egress gateway. In this
mode, the SSO program is not installed on the AD domain controller.
AD identity authentication is enabled on the intranet, and information about users and user group is saved on an AD server.
Figure 14-11 AD SSO for Internet access users (non-plug-in Mode)

R&D employees and marketing employees must use domain accounts to log in to AD domains and access network resources. R&D
employees and marketing employees must be identified by the user names that they use to log in to AD domains.
If the domain accounts of new employees have been created on an AD server but not stored on a FW, the FW must authenticate them
and automatically import their information based on the organizational structure on the AD server.
For security purposes, no programs can be installed on the AD server.
NOTE:
Without the plug-in, the FW cannot obtain user logout messages. Users go offline only when their connections time out.
In this example, users and user groups on the AD server are imported to the FW. If there are a large number of users on the network, you can import user groups only and
control user permissions by user groups.

2. On the FW, configure an authentication domain with the same name as the authentication domain on the AD server.
4. Configure the new user option for the authentication domain. If an authenticated user does not exist on the FW, the FW imports the
5. Set SSO parameters for the FW to listen to authentication results sent from the AD server to PCs.
In this example, authentication packets do not pass through the FW. Therefore, the authentication results must be mirrored to the
FW.
7. Set the user online timeout duration to 480 minutes to prevent frequent timeouts during working hours.
8. Configure the port mirroring function on the switch to mirror authentication packets to the FW.
Data Planning
ad.cce.com
dc=com
LDAP Port: 389
Administrator DN:
Admin@123
Server Type: AD
and user groups
minutes
AD SSO AD SSO: Enable Set SSO parameters on the FW and configure the FW to
Mode: No Plug-In receive user login information from the AD server.
Interface for Receiving Mirrored
Authentication Packets:
GigabitEthernet 1/0/4
Server IP address/port:
10.3.0.251:88
Procedure
1. Choose Network > Interface, set IP addresses for interfaces, and assign the interfaces to security zones. The following example
describes how to configure interfaces GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4. You can configure other interfaces based on
the networking diagram.
Zone Trust
Zone Trust
Mode Switch
GigabitEthernet 1/0/4 is used to receive mirrored packets from the switch and must work in switching mode.
a. Configure security policies between the Trust (AD server) and Local zones to ensure that the FW and AD server can
communicate.
Source Zone Local
Destination Zone Trust
Destination Address 10.3.0.251/32
Action Permit
Source Zone Trust
Action Permit
Name policy_sec_02
Source Zone Trust
Action Permit
Name policy_sec_03
Source Zone Trust
Action Permit
3. On a FW, choose Object > Authentication Server > AD and click Add to set the parameters for communication with an AD
server.
server. Click Start Checking to check the connection to the AD server.
4. On a FW, choose Object > User > Authentication Domain and click Add to create an authentication domain.
5. On a FW, choose Object > User > User Import > Server Import and click Add to configure a policy to import user information
from the AD server to the FW.
NOTE:
To import user groups only, set Import Type to Import only user groups and set the new user option in 6 to Consider new users as temporary
users and do not add them to the local user list. Authenticated users use the permissions of their groups.
The user and user group filtering conditions in this example use the default values (&(|(objectclass=person)(objectclass=organizationalPerson))
(cn=*)(!(objectclass=computer))) and (|(objectclass=organizationalUnit)(ou=*)).
6. Choose Object > User > cce.com, configure AD SSO, and click Apply.
Click Configure on the right of Server Import Policy. In the dialog box that is displayed, click Import Immediately next to
policy_import. After the import is complete, the user groups and users on the AD server are displayed in User/User
NOTE:
Selecting Receive a copy of authentication packets and specifying a mirroring interface on the FW causes the interface to discard all packets except AD
authentication packets. If both authentication packets and service packets are mirrored by the switch to the FW deployed in bypass mode, do not select this
parameter.
7. Choose Object > User > Authentication Policy and click Add to create an authentication policy.
NOTE:
If the action of the authentication policy is set to authentication exemption, the FW obtains user information through SSO and permits traffic even when user
information cannot be obtained during SSO authentication. If the network has high security requirements, set the action of the authentication policy to portal
authentication. Then the FW will implement portal authentication on users that fail SSO authentication.
If the AD domain controller is deployed in the DMZ, ensure that the authentication policy on the FW exempts the authentication packets sent by users to the
AD server. You can choose Object > User > Authentication Policy to check the authentication policy.
The security policy must also allow these packets to pass through. Therefore, configure the following security policy on the FW:
Source Zone: Trust
Destination Zone: DMZ
Destination Address/Region: The IP address of the AD server
Action: Permit
8. Choose Object > User > Authentication Option and set the online user timeout duration to 480 minutes.
10. Configure the port mirroring function on the switch.
This example describes how to configure the port mirroring function on the Huawei S9700. For information about configuring other
functions, refer to the S9700 product documentation.
a. Configure GigabitEthernet 1/0/2 as the observing interface.

<Switch> system-view
[Switch] observe-port 1 interface GigabitEthernet 1/0/2
b. Configure GigabitEthernet 1/0/1 as the mirroring port to mirror incoming traffic.

[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] port-mirroring to observe-port 1 inbound
[Switch-GigabitEthernet1/0/1] quit
Verification

R&D employees can use domain accounts to log in to AD domains and access network resources through the FW. They can
access network resources only after logging in successfully.
Marketing employees can use domain accounts to log in to AD domains and access network resources through the FW.
They can access network resources only after logging in successfully.
#
sysname FW
#
mode no-plug-in
no-plug-in interface GigabitEthernet1/0/4
no-plug-in traffic server-ip 10.3.0.251 port 88
enable
#
#
security-policy
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action exempt-auth
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
portswitch
port link-type access
#
firewall zone trust
#
#
firewall zone dmz
#
#
aaa
domain cce.com
14.5 Web: Example for Configuring TSM SSO for Internet Access Users (Users
Proactively Access the Controller)
This section describes how to configure TSM (Policy Center or Agile Controller) Single Sign On (SSO) for Internet access users when a FW
works as an egress gateway. In this scenario, users proactively access the TSM portal authentication page and are authenticated before
accessing services.
TSM identity authentication is enabled on the intranet, and information about users and user groups is saved on a TSM server.
Figure 14-12 TSM SSO for Internet access users

R&D employees and marketing employees must enter valid TSM accounts and passwords and pass authentication to access network
resources. R&D employees and marketing employees must be identified by the user names they use for TSM authentication.
If the TSM accounts of new employees have been created on a TSM server but not stored on a FW, the FW must consider them
temporary users and assign them the permissions of the specified group.
NOTE:
1. Add the FW on the TSM server and configure the TSM server on the FW so that the FW and TSM server can communicate.
2. Configure a policy to import user information from the TSM server to the FW.
3. Set TSM SSO parameters on the FW.
4. Set the new user authentication option for the default authentication domain. After a new user is authenticated, the user receives the
permissions of the newuser group to access network resources.
6. On the FW, configure an authentication policy for user service traffic and set the action to authentication exemption.
7. Because the FW is deployed between users and the TSM server, authentication packets pass through the FW. Therefore, configure
an authentication policy to prevent the FW from authenticating the authentication requests destined for the TSM server and
configure security policies to ensure that the FW and TSM server can communicate normally.
Data Planning
TSM server Service Name: auth_server_tsm On a FW, set the parameters for communication with a TSM
TSM Controller IP Address: server.
Server Port: 8084 those on the TSM server.
Encryption: AES128
User information import policy Name: policy_import Import users from the TSM server to the FW.
Server Type: TSM
Server Name: auth_server_tsm
and user groups
Target User Group: /default
Automatic Synchronization from
Server: 120 minutes
Parent group of new users Name: newuser New users are considered temporary and use the
Parent Group: /default permissions of the group newuser.
TSM SSO TSM SSO: Enable Set SSO parameters on the FW and configure the FW to
Internet Access After Identity receive user login and logout information from the TSM
Authentication server.
Procedure
1. Add the FW on the TSM server.

NOTE:
The following uses the Agile Controller as an example. The user interface may vary in different versions. For details, refer to the Policy Center or Agile
Controller product documentation for your specific version.
a. Choose System Configuration > Server Configuration > Online Behavior Management Device.
b. Click Add and set the following parameters.

NOTE:
The Port value must be the same as the TSM SSO listening port on the FW in 6.
The Key and Encryption Algorithm values must be the same as the shared key and encryption algorithm in 4.
NOTE:
If the FWs work in hot standby mode, add Online Behavior Management Device twice on the TSM server. The IP Address parameters must be
set to the real IP addresses of the active and standby device interfaces connecting to the TSM server.
c. Click OK.
networking diagram.
Zone Trust
a. Configure a security policy between the Trust zone (users) and DMZ (TSM server) for users to be authenticated by the
TSM server.
Name sec_policy_tsm
Source Zone Trust
Action Permit
b. Configure security policies between the DMZ (TSM server) and Local zone for the TSM server and FW to communicate.
Name local_policy_tsm_01
Source Zone Local
Action Permit
Source Zone DMZ
Action Permit
c. Configure a security policy to allow users to access the Internet.
Name policy_sec_02
Source Zone Trust
Action Permit
4. On a FW, choose Object > Authentication Server > TSM and click Add to set the parameters for communication with a TSM
server.
The parameter settings on the FW must be consistent with those on the TSM server. In most cases, the Policy Center server port is
8080 and the Agile Controller server port is 8084.
Click Detect. In the dialog box that is displayed, click OK to check the connection to the TSM server.
from the TSM server to the FW.
NOTE:
User information on the TSM server can be imported only to the default authentication domain.
6. Choose Object > User > default, configure TSM SSO, and click Apply.
Click Configure to the right of Server Import Policy. In the dialog box that is displayed, click Import Immediately next to
policy_import. After the import is complete, the user groups and users on the TSM server are displayed in User/User
8. Choose Object > User > Authentication Policy and click Add to configure authentication policies. Select none as the action in the
authentication policy for users to access the TSM server so that authentication packets from users can pass through the FW to the
TSM server. Select authentication exemption as the action in the authentication policy for user service traffic so that the FW can
obtain user information through SSO.
NOTE:
Verification
Verify that R&D employees can access network resources after successfully logging in with their TSM accounts and passwords.
Verify that marketing employees can access network resources after successfully logging in with their TSM accounts and passwords.
#
sysname FW
#
user-manage single-sign-on tsm
enable
#
tsm-server template auth_server_tsm
tsm-server encryption-mode aes128 shared-key %$%$|5<h@/062'gA|%:9CO.2/JA8%$%$
tsm-server ip-address 10.2.0.50
#
security-policy
rule name sec_policy_tsm
source-zone trust
action permit
rule name local_policy_tsm_01
source-zone local
action permit
source-zone dmz
action permit
source-zone trust
action permit
#
auth-policy
rule name auth_policy_tsm
source-zone trust
action none
source-zone trust
action exempt-auth
#
user-manage server-sync tsm
sync-address 10.3.0.0 24
enable
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
user-manage import-policy policy_import from tsm
server template auth_server_tsm
server basedn root
destination-group /default
time-interval 120
#
aaa
domain default
new-user add-temporary group /default/newuser
user-manage group /default/newuser
test tsm-server template auth_server_tsm
14.6 Web: Example for Configuring TSM SSO for Internet Access Users (Users' HTTP
Services Are Redirected to the Controller)
works as an egress gateway. In this scenario, the FW redirects user HTTP requests to the TSM portal authentication page when an

The HTTP requests of R&D employees and marketing employees must be automatically redirected to the TSM portal authentication
page. These employees are not required to access the TSM portal authentication page proactively.
The FW saves department information, not user information. The permissions of authenticated users are controlled through the
groups to which they belong.
NOTE:
2. Configure a policy to import group information from the TSM server to the FW.
4. Set the new user authentication option for the authentication domain. New users are considered temporary users after being
authenticated.
5. Set the URL of the TSM portal authentication page as the redirected authentication page for unauthenticated users that directly
access HTTP services.
6. Configure an authentication policy to authenticate users before they access the Internet.
configure security policies to ensure that users, the FW and the TSM server can communicate.
Data Planning
Encryption: AES128
User information import policy Name: policy_import Import groups from the TSM server to the FW.
Server Type: TSM
Import Type: Import only user
groups
Server: 120 minutes
Parent group of new users New users preferentially receive the All users passing TSM authentication are new users for the
permissions of their parent groups on the FW.
server. If their parent groups do not exist on
the server, users receive the permission of
the /default group.
TSM authentication portal address http://10.2.0.50:8080/portal This address must be the same as the setting on the TSM
server.
Internet Access After Identity receive the user login and logout information from the TSM
Procedure

NOTE:
The following example uses the Agile Controller as an example. The user interface may vary in different versions. For details, refer to the Policy Center or
Agile Controller product documentation for your specific version.

NOTE:
The Port value must be the same as the TSM SSO listening port on the FW in 6.
NOTE:
c. Click OK.
networking diagram.
Zone Trust
TSM server.
Source Address
Name sec_policy_tsm
Source Zone Trust
Action Permit
NOTE:
If the URL of the authentication page is a domain name and the DNS server for resolving the URL is deployed in the DMZ, enable the DNS
service from the Trust zone to the DMZ.
Source Zone Local
Action Permit
Source Zone DMZ
Action Permit
Name policy_sec_02
Source Zone Trust
Action Permit
NOTE:
Enable the DNS service from the Trust to the Untrust zone to allow HTTP domain name resolution packets to pass through.
4. On a FW, choose Object > Authentication Server > TSM, click Add to set the parameters for communication with a TSM server.
Click Detect. In the dialog box that is displayed, click OK to check the connection to the TSM server.
from the TSM server to the FW.
NOTE:
6. Choose Object > User > default, configure TSM SSO, and click Apply.
policy_import. After the import is complete, the user groups and users on the TSM server are displayed in User/User
7. Choose Object > User > Authentication Option, select User-Defined Portal Authentication Settings, and set Portal server
URL to TSM portal authentication page.
The portal URL must be consistent with that configured on the Controller.
a. In the authentication policy for users to access the TSM server, set the action to none so that authentication packets from
users can pass through the FW to the TSM server.
b. In the authentication policy for users to access other services, set the action to portal authentication so that authentication
is triggered by HTTP service access traffic from users.
Verification
Access http://www.example.org/ as an R&D employee. Verify that the HTTP request is redirected to the authentication page and
that after entering a TSM account and password, you can access network resources.
Access http://www.example.org/ as a marketing employee. Verify that the HTTP request is redirected to the authentication page and
#
sysname FW
#
enable
user-manage portal-template portal 0
portal-url push information
portal-url http://10.2.0.50:8080/portal
#
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
source-zone local
action permit
source-zone dmz
action permit
#
enable
#
auth-policy
source-zone trust
action none
source-zone trust
action auth portal-template portal
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
server basedn root
import-type group
time-interval 120
#
aaa
domain default
new-user add-temporary group /default auto-import policy_import
This section describes how to configure RADIUS Single Sign On (SSO) for Internet access users when a FW works as an egress gateway.
Intranet users use the NAS to access the Internet.

The NAS sends user credentials to a RADIUS server for user authentication, and information about users and user groups is saved on
the RADIUS server.
Figure 14-14 RADIUS SSO for Internet access users

R&D employees and marketing employees must enter valid RADIUS accounts and passwords and pass authentication to access
network resources. R&D employees and marketing employees must be identified by the user names they use for RADIUS
authentication.
If the RADIUS accounts of new employees have been created on a RADIUS server but not stored on a FW, the FW considers them
temporary users and assigns them the permissions of the specified group.
NOTE:
1. Export user information on the RADIUS server into a CSV file in the specified format and import the CSV file into a FW to create
users and user groups in batches.
2. Set RADIUS SSO parameters on the FW.
4. Set the online user timeout duration to a larger value than the update interval of RADIUS accounting packets on the FW. This
prevents users from frequently having to log in to and log out of the FW. In the example, the online duration is set to 480 minutes.
6. Because the FW is deployed between users and the RADIUS server, authentication packets pass through the FW. Therefore,
configure an authentication policy to prevent the FW from authenticating the authentication requests destined for the RADIUS
server and configure security policies to ensure that the FW and RADIUS server can communicate normally.
Data Planning
RADIUS SSO RADIUS SSO: Enable Set SSO parameters on the FW for the FW to analyze the
Working mode: In-line RADIUS accounting packets passing by and obtain from
them the mappings between users and IP addresses.
Receiving Interface:
Traffic to be analyzed by RADIUS
SSO: 10.2.0.50:1813 (IP address of
the RADIUS server: accounting
port)
Procedure
networking diagram.
Zone Trust
a. Configure a security policy between the Trust zone (users and NAS device) and DMZ (RADIUS server) for users to be
authenticated by the RADIUS server.
Name policy_sec_radius
Source Zone Trust
Action Permit
Name policy_sec_02
Source Zone Trust
Action Permit
3. Choose Object > User > User Import > Local Import and import users and user groups from a CSV file.
a. In Import User, click Download CSV Template and download the CSV template to your PC.
b. Enter the user information on the RADIUS server into a CSV file according to the template.
Read the instructions in the CSV template and fill in user information. The following figure shows a completed CSV file.
c. Click Import to import the CSV file.
4. Choose Object > User > default, configure RADIUS SSO, and click Apply.
The user groups and users in the default authentication domain are imported through the CSV file in the previous step. The newuser
user group accommodates new users.
6. Choose Object > User > Authentication Policy and click Add to configure authentication policies. In the authentication policy for
users to access the RADIUS server, set the action to none so that authentication packets from users can pass through the FW to the
RADIUS server. In the authentication policy for user service traffic, set the action to authentication exemption so that the FW can
obtain user information through SSO.
NOTE:
Verification
Verify that R&D employees can access network resources after successfully logging in to the NAS using RADIUS accounts and
passwords.
Verify that marketing employees can access network resources after successfully logging in to the NAS using RADIUS accounts and
passwords.
#
sysname FW
#
user-manage single-sign-on radius
enable
mode in-path
traffic server-ip 10.2.0.50 port 1813
#
security-policy
rule name sec_policy_radius
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
rule name auth_policy_radius
source-zone trust
action none
source-zone trust
action exempt-auth
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
domain default
user-manage user-import demo.csv auto-create-group override
14.8 Web: Example for Configuring a RADIUS Server to Implement Authentication on

Internet Access Users
An enterprise has deployed a FW as the egress gateway to connect the intranet to the Internet, as shown in Figure 14-15. Details are as
follows:
RADIUS authentication is enabled on the intranet, and information about users and user groups is saved on the RADIUS server.
Figure 14-15 RADIUS server deployed to authenticate Internet access users

The RADIUS server must authenticate Internet access users.
R&D employees and marketing employees must be authenticated on the FW portal before accessing network resources.
If the accounts of new employees are created on the RADIUS server but not stored on a FW, the FW adds the accounts to a user
group after the new employees are authenticated. You can change the parent groups of the new employees.
NOTE:
1. Set parameters for the FW to communicate with the RADIUS server. Configure the FW to work as a client of the RADIUS server
and send user names and passwords to the RADIUS server for authentication.
3. Configure a net1 authentication domain on the FW that references the RADIUS server and configure the new user authentication
option.
5. Configure security policies on the FW to allow Internet access users to access authentication web pages for user-initiated
authentication and to allow the FW to communicate with the RADIUS server.
6. Configure the RADIUS server.
Data Planning
R&D employee Group Add the R&D employee to group research.

Parent Group: /net1 multiple user accounts.
User
Display Name: R&D employee
Parent Group: /net1/research
Account
IP/MAC Binding: No binding
Expiration Time: Always Valid
Marketing employee Group Add the marketing employee to group marketing.

User
Display Name: Marketing
employee
Parent Group: /net1/marketing
Account
Parent group of new users Name: newuser Add new users to group newuser.
Parent Group: /net1 New users can access network resources that are accessible
to the group newuser.
RADIUS server Name: auth_server_radius On the FW, set the parameters for communicating with a
Shared Key: secret RADIUS server.
Primary Authentication Server IP: The parameters on the FW must be consistent with those on
10.2.0.50 the RADIUS server.
Port: 1645
Authentication domain Name: net1 The net1 authentication domain is used during
Access Control: Online behavior authentication.
management
Authentication Server:
auth_server_radius
New User Authentication Option:
Add to user group newuser
Authentication policy Name: policy_auth_service R&D employees and marketing employees can access
Source Zone: Trust network resources only after being authenticated by a FW.
10.3.0.0/24
Action: auth
Procedure
networking diagram.
Zone Trust
2. Choose Object > Authentication Server > RADIUS and click Add to set the parameters for communication with a RADIUS
server.
Click Detect. In the dialog box that is displayed, click OK and enter the user name and password that are configured on the
RADIUS server. Click Start Checking to check the connection to the RADIUS server.
NOTE:
The parameters on the FW must be consistent with those on the RADIUS server.
Include the authentication domain name indicates that the user name sent by the FW to the RADIUS server contains a domain name. If the user name on the
RADIUS server contains an at sign (@), select Include the authentication domain name on the FW.
If the RADIUS server does not support user names in user name@authentication domain name format, do not select Include the authentication domain
name parameter on the FW. Otherwise, authentication will fail.
4. Choose Object > User > Authentication Domain and click Add to create an authentication domain.
The authentication domain must be the same as the string following the at sign (@) in the user name on the RADIUS server.
5. Choose Object > User > User Import > Local Import and import users and user groups from a CSV file.
a. In Import User, click Download CSV Template and download the CSV template to your PC.
b. Enter the user information on the RADIUS server into a CSV file according to the template.
NOTE:
The first level of the group path in the CSV file is the authentication domain name. Therefore, the login name does not contain "@domain-name."
In this example, the user name on the RADIUS server is user_0002@net1. Therefore, in the CSV file, the group path is /net1 and the login name
is user_0002.
c. Click Import to import the CSV file.
6. Choose Object > User > net1, configure RADIUS server authentication, and click Apply.
The user groups and users in the net1 authentication domain are imported through the CSV file in the previous step. The newuser
user group accommodates new users.
Name policy_local_01
Source Zone Trust
Action Permit
b. Configure a security policy to allow the FW to communicate with the RADIUS server.
Source Zone Local
Action Permit
Name policy_sec_02
Source Zone Trust
Action Permit
NOTE:
d. Configure a security policy to allow users to access the server cluster.
Name policy_sec_03
Source Zone Trust
Action Permit
NOTE:
The following uses Shiva Access Manager as an example. To configure your specific RADIUS server, refer to relevant product documentation.
a. Install Shiva Access Manager on the PC. (The installation procedure is omitted here.)
b. Choose Start > Programs > Shiva Access Manager > Shiva Access Manager to start the Shiva Access Manager
program.
c. In the dialog box displayed, enter the user name and password. The default user name is supermanager and the password
is null. See Figure 14-16.
Figure 14-16 Logging in to the Shiva Access Manager server
d. Click Login. In the dialog box displayed, click Start Console Now, as shown in Figure 14-17.
Figure 14-17 Starting the Shiva Access Manager software
e. In the dialog box displayed, enter the user name and password. The default user name is supermanager and the password
Figure 14-18 Logging in to the Shiva Access Manager console
f. Click Login. The Shiva Access Manager Console interface is displayed, as shown in Figure 14-19.
Figure 14-19 Shiva access manager console
g. Click on the toolbar. In the Encryption Configuration dialog box, enter the NAS address and key, as shown in Figure
14-20. The NAS address is the interface IP address for communication between the FW and the RADIUS server. The key
is the shared key that is set on the FW side.
Figure 14-20 Encryption configuration
h. Click Add. The added NAS address is displayed under NAS List, as shown in Figure 14-21.
i. Click Exit.
j. Click on the toolbar. In the General Options dialog box, set Authentication UDP Port, as shown in Figure 14-22.
Figure 14-22 Setting the RADIUS server ports
k. Click on the toolbar. In the Manage Users dialog box, click the General Attributes tab, and set the parameters, as
shown in Figure 14-23. Username and Password are the user name and password used for client access. Username is
the user followed by the domain name set on the FW side.
NOTICE:
Do not select Disable Account. Otherwise, the configuration will fail.
Figure 14-23 Configuring users
l. Click Add User.
Verification
Verify that when an R&D employee accesses www.example.org, the web browser is redirected to an authentication page. The R&D
employee then enters a user name and password for authentication. After the R&D employee is authenticated, the R&D employee can
access network resources.
Verify that when a marketing employee accesses www.example.org, the web browser is redirected to an authentication page. The
marketing employee then enters a user name and password for authentication. After the marketing employee is authenticated, the
marketing employee can access network resources.
Verify that when a new employee accesses www.example.org, the web browser is redirected to an authentication page. The new
employee then enters a user name and password for authentication. After the new employee is authenticated, the new employee can
Before accessing non-HTTP servers, such as FTP servers, employees must access the authentication page at https://10.3.0.1:8887 for
authentication. The IP address of the authentication page must be that of the interface on the FW and must be reachable to users.
#
sysname FW
#
radius-server template auth_server_radius
radius-server shared-key cipher %$%$73pu<+^]XV9mn=*qd}_,r3*!%$%$
radius-server authentication 10.2.0.50 1645
radius-server user-name domain-included
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
authentication-scheme radius
authentication-mode radius
#
domain net1
radius-server auth_server_radius
new-user add-local group /net1/newuser
#
auth-policy
source-zone trust
action auth
#
security-policy
rule name policy_local_01
source-zone trust
action permit
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
test-aaa testname testpassword radius-template auth_server_radius
14.9 Web: Example for Configuring an LDAP Server to Implement Authentication on

This section describes how to configure a Sun ONE LDAP server to authenticate Internet access users when a FW works as an egress gateway.
follows:
The intranet has a Sun ONE LDAP server that stores information about users, departments, and groups (named static groups on the
LDAP server).
Figure 14-24 LDAP server deployed to authenticate Internet access users

The LDAP server must authenticate Internet access users.
R&D employees and marketing employees must be authenticated on the FW portal before accessing network resources.
If the domain accounts of new employees have been created on an LDAP server but not stored on a FW, the FW authenticates them
and automatically imports their information based on the organizational structure on the LDAP server.
NOTE:
Information about users, departments, and groups (static groups) on the LDAP server must be imported to the FW. Select the import type as appropriate. For example,
when a large number of users exist on the LDAP server, you can import departments and groups and implement department- and group-specific permission control.
1. Set parameters for the FW to communicate with the LDAP server. Configure the FW to work as a client of the LDAP server and
send user names and passwords to the LDAP server for authentication.
3. On the FW, configure an authentication domain with the same name as the authentication domain on the LDAP server.
4. Configure a policy to import user information from the LDAP server to the FW.
User groups on the FW correspond to departments on the LDAP server, and security groups on the FW correspond to static groups
on the LDAP server.
authentication and to allow the FW to communicate with the LDAP server.
Data Planning
LDAP server Name: auth_server_ldap On a FW, set the parameters for communication with an
Primary Authentication Server IP: LDAP server.
Port: 389 those on the LDAP server.
Server Type: Sun ONE LDAP
Base DN: dc=cce, dc=com
LDAP Port: 389
Administrator DN: uid=admin_test
Admin@123
User information import policy Name: policy_import Import users from the LDAP server to the FW.
Server Type: LDAP
Server Name: auth_server_ldap
Import Type: All
minutes
Authentication domain Name: cce.com The cce.com authentication domain is used during
Access Control: Online behavior authentication.
management
auth_server_ldap
New User Authentication Option:
Imports the user based on the
import policy.
10.3.0.0/24
Action: auth
Procedure
networking diagram.
Zone Trust
Source Zone Trust
Action Permit
b. Configure a security policy to allow the FW to communicate with the LDAP server.
Source Zone Local
Action Permit
Name policy_sec_02
Source Zone Trust
Action Permit
NOTE:
Name policy_sec_03
Source Zone Trust
Action Permit
3. Choose Object > Authentication Server > LDAP and click Add to set the parameters for communication with an LDAP server.
The parameters on the FW must be consistent with those on the LDAP server.
Click Detect. In the dialog box that is displayed, click OK and enter the user name and password that are configured on the LDAP
server. Click Start Checking to check the connection to the LDAP server.
5. Choose Object > User > Authentication Domain and click Add to create an authentication domain.
The domain name must be the same as that on the LDAP server.
from the LDAP server to the FW.
7. Choose Object > User > cce.com, configure LDAP server authentication, and click Apply.
policy_import. After the import is complete, the user groups and users on the LDAP server are displayed in User/User
Verification
#
sysname FW
#
ldap-server template auth_server_ldap
ldap-server authentication 10.3.0.50 389
ldap-server authentication base-dn dc=cce,dc=com
ldap-server authentication manager uid=admin_test %$%$>884X|-geW:1_*O\(6EI+|sj%$%$ %$%$>884X|-geW:1_*O\(6EI+|sj%$%$
ldap-server group-filter ou
ldap-server user-filter uid
ldap-server server-type sun-one
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
authentication-scheme ldap
authentication-mode ldap
#
domain cce.com
ldap-server auth_server_ldap
#
user-manage import-policy policy_import from ldap
server template auth_server_ldap
user-attribute uid
user-filter (&(|(objectclass=person)(objectclass=organizationalPerson))(uid=*))
security-group-filter (&(objectclass=groupofuniquenames)(!(memberURL=*)))
import-type all
#
auth-policy
source-zone trust
action auth
#
security-policy
source-zone trust
action permit
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
test-aaa testname testpassword ldap-template auth_server_ldap
14.10 Web: Example for Online Querying and Referencing the Specified Users/User
Groups on the AD Server Using Security Policies
server.
Figure 14-25 Networking diagram for online querying and referencing the specified users/user groups on the AD server using security policies
R&D and marketing employees can log in to the AD domain using their domain accounts and passwords and access permitted
resources without further authentication. R&D and marketing employees are identified by the user names that they use to log in to the
AD domain.
The AD server has a great number of users and user groups, and only some of them need to be imported to the FW for policies to
reference.
Security policies are configured to allow only marketing employees (user group: marketing) and some R&D employees (such as
users rd_1 and rd_2) to access the Internet.
NOTE:
This section describes only the operations for online querying, importing, and referencing users from an AD server and configuring authentication domains and server
import policies. For the AD server authentication, AD LDAP server authentication, and AD SSO configuration operations, see the corresponding configuration description
or configuration examples.

3. Configure a server import policy on the FW.
4. Configure new user options of the authentication domain and associate the authentication domain with the configured server import
policy. Otherwise, the user cannot be queried online using the policy.
5. Configure a security policy on the FW, online query and import user group marketing and users rd_1 and rd_2 from the AD
server, and reference them in the security policy to allow the specified users on the intranet to access the Internet.
Only the AD and AD LDAP servers support remote query and import of users, user groups, or security groups.
This section describes how to online query, import, and reference users in security policies. You can also online query, import, and
reference users, user groups, or security groups in other policies that use user as a matching condition.
Data Planning
ad.cce.com
dc=com
LDAP Port: 389
Administrator DN:
Admin@123
Server Type: AD
and user groups
Security Policy Name: policy_sec Allow only marketing employees (user group: marketing)
Source Zone: trust and some R&D employees (such as users rd_1 and rd_2) to
access the Internet.
Destination Zone: untrust
10.3.0.0/24
User: /cce.com/marketing,
[email protected], [email protected]
Action: Permit
Procedure
a. Choose Object > Authentication Server > AD.
c. Click Detect. In the dialog box that is displayed, click OK and enter the user name and password that are configured on
the AD server. Click Start Checking to check the connectivity to the AD server.
d. Click OK.
2. Configure an authentication domain.
a. Choose Object > User > Authentication Domain.

NOTE:
Associated User Group must be set to Same as the Domain Name. Otherwise, the function of importing users, user groups, or security groups in
policies cannot be used.
a. Choose Object > User > User Import > Server Import.
NOTE:
The import type and filtering parameter configured in the server import policy do not take effect in this scenario.
In this scenario, only the specified user, user group, or security group needs to be imported. Therefore, do not select Incremental Synchronization or Full
Synchronization.
4. Configure the cce.com authentication domain on the FW.
a. Choose Object > User > cce.com.

b. Set the following parameters.
NOTE:
The authentication domain must be associated with the configured server import policy. Otherwise, the users, user groups, or security groups on the server
cannot be online queried using the policy.
5. Configure a security policy on the FW, online query and import user group marketing and users rd_1 and rd_2 from the AD
server, and reference them in the security policy to allow the specified users on the intranet to access the Internet.
a. Choose Policy > Security Policy > Security Policy, click Add > Add Security Policy.
b. Click the text box of the User matching condition, select Server Import, enter the specified keywords, and click Server
Import.
c. Separately select user group marketing and users rd_1 and rd_2, click , and click OK to import the selected users or
user group. Then reference the users or user group in the security policy.
NOTE:
When querying users, user groups, or security groups online, you can select the object type in Type to obtain specific query results.
The destination group to which a user or user group is imported is determined by the configuration of the server import policy. In this example, the
user or user group is imported to user group cce.com.
d. Set the matching conditions as follows:
Name policy_sec
Source Zone trust
Destination Zone untrust
Source Address/Region 10.3.0.0/24
User /cce.com/marketing, [email protected], [email protected]
Action Permit
Verification
After R&D employees rd_1 and rd_2 use their domain accounts and passwords to log in to the AD domain, they can access the
Internet, while other R&D employees cannot access the Internet.
After marketing employees use their domain accounts and passwords to log in to the AD domain, they can access the Internet.
Configuration Script
#
sysname FW
#
ad-server authentication host-name cce.com
#
security-policy
rule name policy_sec
source-zone trust
user /cce.com/marketing
user [email protected]
user [email protected]
action permit
#
#
aaa
domain cce.com
14.11 Web: Example for Configuring Authentication on Users at the Headquarters and
Branch Offices Using an AD Server
This section provides an example for configuring authentication on Internet access users and remote access users when a FW works as an
egress gateway and VPN access gateway.
As shown in Figure 14-26, FWs are deployed at the network borders of the headquarters and branch office of an enterprise. Details are as
follows:
The AD identity authentication mechanism is enabled for the enterprise, and information about users and user groups are saved on an
AD server. The enterprise has top executives, R&D employees, and marketing employees. The R&D and marketing employees work
in the headquarters and branch offices.
The top executives, R&D employees, and marketing employees in the headquarters must be authenticated by FW_A before accessing
network resources.
Top executives use the fixed IP address (10.3.0.2). To improve efficiency, top executives are exempted from authentication,
but for security considerations, the accounts used by top executives must be bound to IP addresses and MAC addresses.
R&D employees and marketing employees use domain accounts to log in to AD domains and access network resources.
An IPSec tunnel is established between the headquarters and a branch office. Employees in the branch office must be authenticated
by FW_A before accessing the resources in the headquarters.
The R&D and marketing employees on the move can connect to FW_A using SSL VPN to access network resources.
Figure 14-26 Authentication on users at the headquarters and branch offices using an AD server
NOTE:
1. On the FW_A, set the parameters for communication with an AD server.

2. Configure an authentication domain on the FW_A. The domain name must be the same as that on the AD server.
3. Configure a policy to import user group information from the AD server to the FW_A.
4. Set a new user authentication item for the authentication domain. If a user passes the authentication but does not exist on FW_A, the
user is a temporary user and is granted the permission of its parent group.
NOTE:
In this example, only the organizational unit on the AD server is imported. Therefore, all users are new to FW_A. When you configure a new user
authentication item, the user is not added to the local user list. Its parent group is obtained based on the server import policy, and the user is granted the
permission of its parent group.
5. Configure authentication for headquarters employees.

Configure authentication exemption for top executives.
Create group and user objects for top executives and bidirectionally bind the user objects to IP and MAC addresses. Create
an authentication policy and set the authentication action to no authentication.
Configure AD SSO.
Employees are required to pass FW_A authentication after AD domain authentication. Therefore, configure AD SSO on
FW_A to ensure that FW_A can monitor the authentication result packets that the AD server sends to the employees' PCs.
6. Configure authentication on branch employees and the employees on the move.
a. Configure an authentication scheme and set the authentication mode to AD.

b. Configure an authentication policy for branch employees connected to the headquarters over IPSec tunnels to be
authenticated by FW_A before accessing network resources.
Data Planning
AD server Name: auth_server_ad On a FW_A, set the parameters for communication with an
Primary Authentication Server IP: AD server.
10.2.0.50 The parameter settings on the FW_A must be consistent
Port: 88 with those on the AD server.
ad.cce.com
dc=com
LDAP Port: 389
Administrator DN:
Admin@123
Authentication domain Name: cce.com The domain name must be the same as that on the AD
Access Control: SSL VPN Access server.
and Internet behavior management
auth_server_ad
Authentication scheme: ad
New User Authentication Item:
New users preferentially use the
permissions of their parent groups
on the server. If their parent groups
do not exist on the server, users use
the permission of the /cce.com
group.
User information import policy Name: policy_import Import users from the AD server to the FW_A.
Server Type: AD
Import Type: Import user groups
minutes
AD SSO AD SSO: Enable Set SSO parameters on the FW_A and configure the FW_A
Mode: No-Plug-In to receive the user login information from the AD server.
10.2.0.50:88
Top executive Group Add the top executive to the group manager and configure
Name: manager bidirectional binding for the top executive and the IP and
MAC addresses. No password is required for the top
Parent Group: /cce.com
executive. A FW_A implements authentication on the top
User executive based on the bound IP and MAC addresses.
Display Name: Top executive A multiple user accounts.
Parent Group: /cce.com/manager
Account
binding
bbbb-cccc
Authentication policy for top executives Name: policy_auth_01 Authentication is not implemented on the top executive who
Source Zone: trust meets matching conditions. FW_A identifies the top
executive based on the bound IP and MAC addresses.
Destination Zone: any
The top executive can access network resources without
entering any user name and password.
10.3.0.2/32
Destination Address/Region: any
Action: exempt-auth
Authentication policy for branch office Name: policy_auth_02 Employees in the branch office must pass the authentication
Source Zone: untrust before accessing the resources in the headquarters.
10.4.0.0/16
Action: auth
Procedure
1. Choose Network > Interface, set IP addresses for interfaces and assign the interfaces to security zones.
networking diagram.
Zone trust
2. Choose Policy > Security Policy > Security Policy, click Add to configure security policies.
a. Configure security policies between the DMZ (AD server) and Local zone to ensure the communication among the FW
and AD server.
Source Zone local
Action Permit
Source Zone dmz
Action Permit
Name policy_sec_02
Source Zone trust
Action Permit
c. Configure a security policy to allow branch office employees to access the authentication page.
Name policy_sec_03
Service Create user-defined service (TCP/8887)
Action Permit
3. On the FW_A, choose Object > Authentication Server > AD, click Add to set the parameters for communication with an AD
server.
The parameter settings on the FW_A must be consistent with those on the AD server.
server. Click Start Checking to check the connectivity to the AD server.
4. On the FW_A, choose Object > User > Authentication Domain, click Add to create an authentication domain.
5. On the FW_A, choose Object > User > User Import > Server Import, click Add to configure a policy to import user group
information from the AD server to the FW_A.
NOTE:
The user and user group filtering conditions in this example use the default values (&(|(objectclass=person)(objectclass=organizationalPerson))(cn=*)(!
(objectclass=computer))) and (|(objectclass=organizationalUnit)(ou=*)). To change them, run the user-filter and group-filter commands.
6. Choose Object > User > cce.com, configure the authentication parameters and click Apply.
Configure mobile or branch employees to access the HQ for AD server authentication: Set User Location to
Authentication server and select the AD server.
Import user groups from the AD server: Click Configure on the right of Server Import Policy. A dialog box is displayed.
Click Import Immediately corresponding to policy_import. After the import is complete, the user groups on the AD
server are displayed in User/User Group/Security Group Management List.
Configure authentication exemption for senior managers: Create the user account user_0001 and user group manager for
the senior manager; configure bidirectional binding of the user account and IP/MAC address.
Configure AD SSO for HQ employees: Set AD login parameters.
In this example, AD SSO is configured in no-plug-in mode. For configuration in plug-in mode, see CLI: Example for
Configuring AD SSO for Internet Access Users (Install ADSSO_Setup.exe to receive messages from PCs).
Configure new user options: A user logs in as a temporary user after passing AD server authentication if FW_A does not
have the user.
7. Choose Object > User > Authentication Option, set the online user timeout duration to 480 minutes.
8. Choose Object > User > Authentication Policy, click Add to configure authentication policies.
a. Set the authentication policy for the senior manager to authentication exemption.
b. Configure an AD SSO authentication policy.

Configure the action in the authentication policy for users to access the AD server as no-authentication so that the users'
authentication packets can go through the FW to the AD server. Configure the action in the authentication policy for
users' service traffic to authentication exemption so that the FW can obtain user information through SSO.
NOTE:
If the action of the authentication policy is set to authentication exemption, the FW obtains user information through SSO and permits the traffic
when user information fails to be obtained during SSO authentication. If the network has high security requirements, set the action of the
authentication policy to portal authentication. Then the FW will implement portal authentication on the users failing the SSO authentication.
c. Set the AD server authentication policy to portal authentication for branch and mobile employees.
proxy policies, and audit policies that reference the user group objects.
Verification
The top executive user_0001 can access network resources without authentication. Other users cannot use the user name of the top
executive to access network resources because their IP addresses are not 10.3.0.2 and their MAC addresses are not aaaa-bbbb-cccc.
Employees in the headquarters can use domain accounts and passwords to log in to the AD domain and access network resources.
An employee in the branch office accesses https://10.3.0.1:8887 and enters the user name and password for authentication. After the
authentication succeeds, the employee can access the network resources in the headquarters.
An employee on the move accesses the authentication page of the SSL VPN virtual gateway and enters the user name and password
for authentication. After the authentication succeeds, the employee can access the network resources in the headquarters.
#
sysname FW_A
#
mode no-plug-in
enable
#
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
firewall zone dmz
set priority 50
#
security-policy
source-zone local
action permit
source-zone dmz
action permit
source-zone trust
action permit
action permit
#
import-type group
#
aaa
authentication-scheme ad
authentication-mode ad
#
domain cce.com
service-type internetaccess ssl-vpn
internet-access mode single-sign-on auto-online password
ad-server auth_server_ad
new-user add-temporary group /cce.com auto-import policy_import
#
auth-policy
source-zone trust
action exempt-auth
rule name auth_policy_ad
source-zone trust
action none
source-zone trust
action exempt-auth
source-zone untrust
action auth
user-manage group /cce.com/manager
alias Supervisor
parent-group /cce.com/manager
Internet access users include R&D employees, marketing employees, and guests. All of them dynamically obtain IP addresses.
Figure 14-27 Local authentication of Internet access users
R&D employees and marketing employees must be authenticated by the FW.
Guests must be authenticated by the FW and can only use specified guest accounts to access network resources.
Redirected authentication must be implemented for guests. When an unauthenticated guest uses a browser to access a web page, the
FW redirects the guest to an authentication page. After the guest is authenticated, the browser displays the requested web page.
1. Create user groups and users and set passwords for the users.
2. Create authentication policies and configure matching conditions and actions.
3. Configure the default authentication domain.
4. Configure a security policy to allow users to access authentication web pages.
Data Planning
R&D employee Group Add each R&D employee to group research.

User
Display Name: Tom
Parent Group: /default/research
Admin@123
Account
Marketing employee Group Add each marketing employee to group marketing.

User
Display Name: Jack
Parent Group: /default/marketing
Admin@123
Account
Guest Group All guests use the guest account for authentication.
Name: /default
User
Login Name: guest
Admin@123
Allow Users to Share This
Account
Authentication policy Name: policy_auth_01 Authentication is implemented on R&D employees,

Source Zone: Trust marketing employees, and guests who meet the matching
conditions.
R&D employees, marketing employees, and guests can
access network resources only after being authenticated by a
10.3.0.0/24
FW.
Action: Portal authentication
Authentication domain Name: default The default authentication domain is used during
Access Control: Online behavior authentication. The user names for R&D employees,
management marketing employees, and guests do not require an
authentication domain.
Procedure
1. Set IP addresses for the interfaces and assign the interfaces to security zones. The following example describes how to configure
interface GigabitEthernet 1/0/3. You can configure other interfaces based on the networking diagram.
<FW> system-view
[FW] interface GigabitEthernet 1/0/3
[FW-GigabitEthernet1/0/3] ip address 10.3.0.1 24
[FW-GigabitEthernet1/0/3] quit
[FW] firewall zone trust
[FW-zone-trust] add interface GigabitEthernet 1/0/3
[FW-zone-trust] quit
2. Create a user group object and a user object for an R&D employee.
[FW] user-manage group /default/research
[FW-usergroup-/default/research] quit
[FW] user-manage user user_0001
[FW-localuser-user_0001] alias Tom
[FW-localuser-user_0001] parent-group /default/research
[FW-localuser-user_0001] password Admin@123
[FW-localuser-user_0001] undo multi-ip online enable
[FW-localuser-user_0001] quit
3. Create a user group object and a user object for a marketing employee.
[FW] user-manage group /default/marketing
[FW-usergroup-/default/marketing] quit
[FW-localuser-user_0002] alias Jack
[FW-localuser-user_0002] parent-group /default/marketing
[FW-localuser-user_0002] password Admin@123
4. Create a user object for the guest account.
[FW] user-manage user guest
[FW-localuser-user_guest] parent-group /default
[FW-localuser-user_guest] password Admin@123
[FW-localuser-user_guest] quit
5. Configure the authentication page to redirect to the previously accessed page after authentication.
[FW] user-manage redirect
6. Configure an authentication policy.
[FW] auth-policy
[FW-policy-auth] rule name policy_auth_01
[FW-policy-auth-rule-policy_auth_01] source-zone trust
[FW-policy-auth-rule-policy_auth_01] source-address 10.3.0.0 24
[FW-policy-auth-rule-policy_auth_01] action auth
[FW-policy-auth-rule-policy_auth_01] quit
[FW-policy-auth] quit
7. Configure the authentication domain.

[FW] aaa
[FW-aaa] domain default
[FW-aaa-domain-default] service-type internetaccess
[FW-aaa-domain-default] quit
[FW-aaa] quit

[FW] security-policy
[FW-policy-security] rule name policy_sec_01
[FW-policy-security-rule-policy_sec_01] source-zone trust
[FW-policy-security-rule-policy_sec_01] destination-zone local
[FW-policy-security-rule-policy_sec_01] source-address 10.3.0.0 24
[FW-policy-security-rule-policy_sec_01] service protocol tcp destination-port 8887
[FW-policy-security-rule-policy_sec_01] action permit
[FW-policy-security-rule-policy_sec_01] quit

[FW-policy-security-rule-policy_sec_02] destination-zone untrust
NOTE:

[FW-policy-security-rule-policy_sec_03] destination-zone dmz
[FW-policy-security] quit
Verification

When the R&D employee Tom accesses www.example.org, the web browser is redirected to an authentication page. The
R&D employee then enters user name user_0001 and password Admin@123 for authentication. After the R&D employee
is authenticated, the web browser is redirected to www.example.org.
When the marketing employee Jack accesses www.example.org, the web browser is redirected to an authentication page.
The marketing employee then enters user name user_0002 and password Admin@123 for authentication. After the
marketing employee is authenticated, the web browser is redirected to www.example.org.
When a guest accesses www.example.org, the web browser is redirected to an authentication page. The guest then enters
user name guest and password Admin@123 for authentication. After the guest is authenticated, the web browser is
redirected to www.example.org.
Before accessing non-HTTP servers, such as FTP servers, employees and guests must access the authentication page at
https://10.3.0.1:8887 for authentication. The IP address of the authentication page must be that of the interface on the FW and must
be reachable to users.
Run the display user-manage online-user command on the FW to display information about online users.
<FW> display user-manage online-user verbose
Current Total Number: 3
--------------------------------------------------------------------------------
IP Address: 10.3.0.2
Login Time: 2015-01-21 14:58:36 Online Time: 00:00:49
State: Active TTL: 00:30:00 Left Time: 00:29:59
Access Type: local
Authentication Mode: Password (Local)
Access Device Type: unknown
<--packets: 0 bytes: 0 -->packets: 0 bytes: 0
Build ID: 0
User Name: user_0001 Parent User Group: /default/research
Access Type: local
Build ID: 0
User Name: user_0002 Parent User Group: /default/marketing
Access Type: local
Build ID: 0
User Name: guest Parent User Group: /default
--------------------------------------------------------------------------------
#
sysname FW
#
user-manage redirect
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
#
domain default
#
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action auth
user-manage group /default/research
user-manage group /default/marketing
alias Tom
parent-group /default/research
password *********
alias Jack
parent-group /default/marketing
password *********
user-manage user guest
parent-group /default
password *********
14.13 CLI: Example for Configuring Authentication Exemption for Internet Access
Users (Bidirectionally Binding Users to IP and MAC Addresses)
behavior control and permission assignment.
High-level executives use the fixed IP address 10.3.0.2. To improve efficiency, these executives are exempted from authentication. However,
for security purposes, their accounts must be bound to IP addresses and MAC addresses. This ensures that executives can use only the
specified IP and MAC addresses to access network resources.
Figure 14-28 Authentication exemption for Internet access users
1. Create a user group and user objects for executives and bidirectionally bind the user objects to IP and MAC addresses.
2. Create an authentication policy and configure the matching conditions and authentication action.
3. Configure the authentication domain default.
Data Planning
Executive Group Add the executive to the group manager and configure
Name: manager bidirectional binding for the account and the IP and MAC
addresses. No password is required for the executive. A FW
authenticates the top executive based on the bound IP and
User MAC addresses.
Display Name: Supervisor multiple user accounts.
Parent Group: /default/manager
Account
binding
bbbb-cccc
Authentication policy Name: policy_auth_01 Executives who meet the matching conditions can access
Source Zone: Trust network resources without being authenticated.
10.3.0.2/32
Action: Authentication exemption
Authentication domain Name: default -

management
Procedure
<FW> system-view
2. Create a user group object and a user object for an executive.

[FW] user-manage group /default/manager
[FW-usergroup-/default/manager] quit
[FW-localuser-user_0001] alias Supervisor
[FW-localuser-user_0001] parent-group /default/manager
[FW-localuser-user_0001] bind mode bidirectional
[FW-localuser-user_0001] bind ipv4 10.3.0.2 mac aaaa-bbbb-cccc

[FW] auth-policy
[FW-policy-auth] rule name policy_auth_01
[FW-policy-auth-rule-policy_auth_01] source-zone trust
[FW-policy-auth-rule-policy_auth_01] source-address 10.3.0.2 32
[FW-policy-auth-rule-policy_auth_01] action exempt-auth
[FW-policy-auth-rule-policy_auth_01] quit
NOTE:
If an authentication policy for common employees is required, the authentication policy for subnet 10.3.0.2/32 must be configured prior to that for subnet
10.3.0.2/24. Otherwise, executives cannot match the authentication exemption policy.
4. Configure the authentication domain default.
[FW] aaa
[FW-aaa] quit
a. Configure a security policy to allow users to access the Internet.


Verification
Verify that the executive A can access network resources without authentication and that other users cannot use the executive user
name to access network resources because their IP addresses are not 10.3.0.2 and their MAC addresses are not aaaa-bbbb-cccc.
--------------------------------------------------------------------------------
Access Type: local
Authentication Mode: Authentication Exemption (IP/MAC Bind User) Bind Mode: Bidirectional
Build ID: 0
User Name: user_0001 Parent User Group: /default/manager
--------------------------------------------------------------------------------
#
sysname FW
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
#
domain default
#
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action exempt-auth
#The following user/group creation configuration is stored in the database, but not in the configuration profile.
user-manage group /default/manager
alias Supervisor
parent-group /default/manager
This section provides an example for configuring AD Single Sign On (SSO) for Internet access users when a FW works as an egress gateway.
In this example, the ADSSO_Setup.exe must be installed on the AD monitor (any computer in the AD domain, including the AD domain
controller) and the login/logout scripts need to be set on the AD domain controller and delivered to PCs.
server.
Figure 14-29 AD SSO for Internet access users (the ADSSO_Setup.exe is installed to receive messages from PCs)
Information about users and departments is saved on the FW and can be referenced by policies.
R&D employees and marketing employees use domain accounts to log in to AD domains and access network resources. R&D
employees and marketing employees are identified by the user names they use to log in to AD domains.
If the domain accounts of new employees have been created on an AD server but not stored on a FW, the FW automatically imports
their information based on the organizational structure on the AD server after authenticating them.
NOTE:
ADSSO_Setup.exe has two working mode: the mode of receiving messages from PCs and the mode of querying security logs of the AD server. In the mode of querying
security logs of the AD server, only user login messages can be obtained, but user logout messages cannot be obtained. In the mode of receiving messages from PCs, user
logout messages can be obtained, ADSSO_Setup.exe needs to be installed, and login & logout scripts need to be deployed on the AD domain controller, and the login PCs
can only be Windows systems. Set the working mode of ADSSO_Setup.exe as required.
NOTE:
When AD SSO is enabled, install the AD SSO service program ADSSO_Setup.exe on the AD monitor (any computer in the AD domain, including the AD
domain controller). The service program can obtain the relevant user information upon user login and logout and send the information to the FW. In this
example, a PC in the domain is used as the AD monitor. If the AD monitor is the AD domain controller, install ADSSO_Setup.exe on the AD domain controller
and configure the AD monitor address as the address of the AD domain controller.
In the example, both users and user groups on the AD server are imported to the FW. If there are a large number of users on a live network, you can import only
user groups and control user permissions by user groups.

4. Configure the new user option of the authentication domain. If an authenticated user does not exist on the FW, the FW imports the
6. Set SSO parameters for the FW to receive user login and logout messages sent from the AD monitor.
7. To prevent repeated login to the domain for authentication because of frequent timeouts during the working hours (8 hours), you
need to set the user online timeout duration to 480 minutes.
8. Enable the AD SSO service (by installing ADSSO_Setup.exe) on an AD monitor, configure the login and logout scripts on the AD
domain controller, and deliver the scripts using group policies.
Data Planning
ad.cce.com
dc=com
LDAP Port: 389
Administrator DN:
Admin@123
Server Type: AD
and user groups
minutes
AD SSO (FW) AD SSO: Enable Set SSO parameters on the FW and configure the FW to
Mode: Installing AD SSO program receive the user login and logout information from the AD
monitor.
AD SSO service (ADSSO_Setup.exe AD Server Parameter Set the parameters of the AD server on the AD monitor for
program, installed on the AD monitor) AD Server IP: 10.3.0.251 the AD monitor to connect to the AD server for checking
user information after receiving user login/logout messages
Administrator Account:
from the client computer.
cce.com\administrator
Password: Admin@123
FW Parameter Enable the AD SSO service on the AD monitor, configure

IP Address: 10.3.0.1 the AD monitor to listen to information about user login and
logout, and send the information to the FW.
Device Listening Port of the AD
SSO service: 8000 The parameters must be the same as those on the FW.
Device Shared Key: Admin@234
Client Communication Parameter The service listening port is an open port of the
Service Listening Port of the AD AD monitor and is used to receive user
SSO service: 12345 login/logout information from client computers.
Anti-Replay Time Window: 1800s The client shared key is the shared key for
(default value) encrypting the communication packets between
Client Shared Key: Admin@123 the client computer and AD monitor and must be
the same as the key configured on the AD domain
controller when login/logout scripts are
configured.
The anti-replay time is the time that the AD
monitor used to check unauthorized client login. If
the interval between the last client login recorded
on the AD domain controller and the last login that
the AD monitor receives from the client exceeds
the anti-replay time, the AD monitor considers the
client login unauthorized and does not send the
client login/logout information to the FW.
AD domain controller (the login and logout IP Address: 10.3.0.254 Run the login and logout scripts on an AD domain
scripts) Listening Port: 12345 controller. If a group policy is used to control the user login
and logout, run the login and logout scripts respectively and
Client Shared Key: Admin@123
send the login and logout information to the AD SSO
service.
The parameters must be the same as those on the
ADSSO_Setup.exe.
Procedure
1. Set IP addresses for interfaces and assign the interfaces to security zones. The following example describes how to configure
<FW> system-view
a. Configure security policies between the trust (AD server and AD monitor) and local zone to ensure the communication
among the FW and AD server.
[FW-policy-security] rule name local_policy_ad_01
[FW-policy-security-rule-local_policy_ad_01] source-zone local
[FW-policy-security-rule-local_policy_ad_01] destination-zone trust
[FW-policy-security-rule-local_policy_ad_01] destination-address 10.3.0.251 32
[FW-policy-security-rule-local_policy_ad_01] action permit
[FW-policy-security-rule-local_policy_ad_01] quit
[FW-policy-security-rule-local_policy_ad_02] source-zone trust
[FW-policy-security-rule-local_policy_ad_02] destination-zone local
[FW-policy-security-rule-local_policy_ad_02] source-address 10.3.0.251 32


[FW] ad-server template auth_server_ad
[FW-ad-auth_server_ad] ad-server authentication 10.3.0.251 88
[FW-ad-auth_server_ad] ad-server authentication base-dn dc=cce,dc=com
[FW-ad-auth_server_ad] ad-server authentication manager cn=administrator,cn=users Admin@123
[FW-ad-auth_server_ad] ad-server authentication host-name ad.cce.com
[FW-ad-auth_server_ad] ad-server authentication ldap-port 389
[FW-ad-auth_server_ad] ad-server user-filter sAMAccountName
[FW-ad-auth_server_ad] ad-server group-filter ou
If you are unfamiliar with the AD server and cannot provide the server name or Base DN values, you can use the AD Explorer
software downloaded from Internet to connect to the AD server to query the attribute values. The mappings between the server
attributes and parameters on the FW are as follows.
Use the user name and password that are configured on the AD server to check the connectivity to the AD server.
[FW-ad-auth_server_ad] test-aaa testname testpassword ad-template auth_server_ad
[FW-ad-auth_server_ad] quit

[FW] aaa
[FW-aaa] domain cce.com
[FW-aaa-domain-cce.com] service-type internetaccess
[FW-aaa-domain-cce.com] quit
[FW-aaa] quit
[FW] user-manage import-policy policy_import from ad
[FW-import-policy_import] server template auth_server_ad
[FW-import-policy_import] server basedn dc=cce,dc=com
[FW-import-policy_import] server searchdn ou=marketing,dc=cce,dc=com
[FW-import-policy_import] server searchdn ou=research,dc=cce,dc=com
[FW-import-policy_import] destination-group /cce.com
[FW-import-policy_import] import-type user-group
[FW-import-policy_import] import-override enable
[FW-import-policy_import] sync-mode incremental schedule interval 120
[FW-import-policy_import] quit
NOTE:
If the server has many users or user groups, some users or user groups under the basedn may not be imported to the FW because the number of users
or user groups exceeds the FW's specification. Therefore, you are advised to run the command server searchdn to select an import range.
In this example, users and user groups are imported to the FW. The user and user group filtering conditions in this example use the default values
(&(|(objectclass=person)(objectclass=organizationalPerson))(cn=*)(!(objectclass=computer))) and (|(objectclass=organizationalUnit)(ou=*)).
To change them, run the user-filter and group-filter commands.
If you need to import user groups only, set import-type to group and set the new user option in 7 to new-user add-temporary group /cce.com
auto-importpolicy_import. Authenticated users use the permissions of their owning groups.
6. Execute the import policy to import users to the FW.

[FW] execute user-manage import-policy policy_import
7. Set the new user option for the authentication domain on the FW.
[FW] aaa
[FW-aaa-domain-cce.com] new-user add-local group /cce.com auto-import policy_import
[FW-aaa] quit

[FW] auth-policy
[FW-policy-auth] rule name auth_policy_service
[FW-policy-auth-rule-auth_policy_service] source-zone trust
[FW-policy-auth-rule-auth_policy_service] source-address 10.3.0.0 24
[FW-policy-auth-rule-auth_policy_service] action exempt-auth
[FW-policy-auth-rule-auth_policy_service] quit
NOTE:
If the action of the authentication policy is set to authentication exemption, the FW obtains user information through SSO and permits the traffic when user
information fails to be obtained during SSO authentication. If the network has high security requirements, set the action of the authentication policy to portal
authentication. Then the FW will implement portal authentication on the users failing the SSO authentication.
If the packets exchanged between the user and the AD server, between the user and the AD monitor, and between the AD monitor and the AD server pass
through the FW, ensure that the authentication policy on the FW does not authenticate these packets and the security policy allows them through. You can run
the display auth-policy command to check the authentication policy.
9. Set AD SSO parameters on the FW.
[FW] user-manage single-sign-on ad
[FW-sso-ad] plug-in shared-key Admin@234
[FW-sso-ad] mode plug-in
[FW-sso-ad] enable
[FW-sso-ad] quit
10. Set the online user timeout duration to 480 minutes.
[FW] user-manage online-user aging-time 480
11. On the FW Web UI, choose Object > User > cce.com, set Internet access authentication mode to SSO Authentication. On the
SSO configuration page, download the AD SSO program to your PC, decompress the program package, and copy
ADSSO_Setup.exe to the AD monitor.
12. Deploy the AD SSO service on the AD monitor.
You must use an account that belongs to the Administrators group to log in to the AD monitor.
a. Double-click ADSSO_Setup.exe. In the dialog box that is displayed, select English as the installation wizard language
and click OK. The installation wizard is then displayed in English.
b. Click Next and specify an installation directory, click Install.
c. Start the ADSSO Agent program.
d. Configure AD SSO parameters.
i. Configure the parameters for the AD SSO program to receive messages from PCs and the shared key used by
the AD SSO program to communicate with the FW.
NOTE:
When an AD SSO service program monitors login messages of multiple AD servers , set Anti-replay Time to 0 and disable the anti-
replay function. The anti-replay function detects the difference between the time at which the AD SSO service program receives a
user login message and the time at which the user actually logs in to the AD server. If the time difference exceeds the anti-replay
time, the user is prohibited from logging in to the FW. In a scenario where multiple AD servers exist, different users are authenticated
by various AD servers. The AD SSO program will connect to multiple AD servers in turn to obtain user login time. This causes the
time difference to exceed Anti-replay Time. Therefore, you shall disable the anti-replay function.
Make sure that the port (port 12345 in this example) you intend to use is not occupied by other services. Choose Start > Run on the
AD domain controller, enter cmd, and run netstat -ano|findstr 12345. If no information is returned, port 12345 is not occupied by
other services. Otherwise, the system displays a message indicating the process ID of the service occupying the port. You are advised
to release this port or specify another idle port for the AD SSO service.
SSO is enabled on all OUs by default. When the AD SSO program is installed on the AD domain controller, filtering by OU is
supported. Click Set FilterGroup and enter the OU for which SSO will be enabled. Four OUs can be configured. You can specify
three levels for each OU. For example, OU1=research,OU2=software indicates that SSO is enabled for /research/software.
ii. Add AD servers.

The AD SSO program supports a maximum of 16 AD servers. It can connect to multiple AD servers to query
login user information until it queries required information.
iii. Add FWs.
The SSO program supports a maximum of five FWs and sends user login/logout messages to the FWs.
NOTE:
When the FWs work in hot standby scenarios, you need to set Device Address to the virtual IP address of the VRRP group where the
interfaces reside, so that the SSO service can send user login messages to the standby device during an active/standby FW switchover.
iv. Start the SSO service.

You can right-click the AD SSO icon in the system tray on your desktop to start or stop the AD SSO service.
Alternatively, click Show Log on the home page to view program operating logs and SSO service logs.
13. On the AD domain controller, add script ReportLogin.exe to the logon script (Logon.exe) and logoff script (Logoff.exe)
respectively, and set the parameters of the logon and logoff scripts so that the AD SSO service can monitor the logon and logoff
operations of domain users. You can obtain script file ReportLogin.exe from the Script folder in the installation directory of the
AD SSO on the AD monitor.
NOTE:
You must use an account that belongs to the Administrators group to log in to the AD domain controller. In this example, the Windows Server 2003 and
Windows 2008 Server are used as an AD domain controller.
a. Access the group policy management page and locate logon and logoff scripts. The steps for accessing the group policy
management page and the paths of logon and logoff scripts differ on Windows 2003 Server, Windows 2008 Server and
Windows 2012 Server. Details are as follows:
Windows 2003 Server
i. Choose Start > All Programs > Administrator Tools > Active Directory Users and Computers. Then run
the Active Directory Users and Computers tool, as shown in Figure 14-30.
Figure 14-30 Directory structure on an AD server
ii. Right-click the domain (cce.com as an example) that requires SSO and select ProPerties. In the dialog box that
is displayed, click the Group Policy tab, as shown in Figure 14-31.
Figure 14-31 Domain properties configuration window
iii. Double-click Default Domain Policy to open the domain policy configuration window.
iv. Choose User Configuration > Windows Settings > Scripts(Logon/Logoff), as shown in Figure 14-32.
Figure 14-32 Group policy configuration window
Windows 2008 Server and Windows 2012 Server
i. Choose Start > Administrative Tools > Group Policy Management.

ii. Right-click Default Domain Policy under the domain to which SSO authentication is to be applied, and choose
Edit, as shown in Figure 14-33.
Figure 14-33 Group policy management
iii. Choose User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff), as shown in Figure
14-34.
Figure 14-34 Configuring the default domain policy
b. Double-click Logon to access the login script configuration window, as shown in Figure 14-35.
Figure 14-35 Login script configuration window
c. In the login script configuration window, click ShowFiles... and copy ReportLogin.exe to the directory that is displayed.
Then close the directory.
d. In the login script configuration window, click Add, add login script ReportLogin.exe, and set the script parameters, as
shown in Figure 14-36. Then click OK.
When adding the user login script, click Browse in Figure 14-36 and select ReportLogin.exe in the directory displayed in
13.c.
Figure 14-36 Adding ReportLogin.exe as the login script
NOTE:
The parameters are separated by spaces.
In the example, the IP address of the AD SSO service is the IP address (10.3.0.254) of the AD monitor.
The service port must the same as the Service Listening Port value specified in 12 when you install ADSSO_Setup.exe. The port
number in this example is 12345.
The client shared key must the same as the Client Shared Key value specified in 12 when you install ADSSO_Setup.exe. The port
number in this example is Admin@123.
0 indicates a login script. To configure a logout script, set this parameter to 1.
e. Configure the logout script by referring to steps 13.b and 13.d. The login and logout scripts are both ReportLogin.exe but
are saved in different folders.
f. Choose Start > Run, enter cmd to open the CLI, and run gpupdate to apply the policy.
Verification
Run the display user-manage user and display user-manage group commands on the FW to display information about users and
user groups.
R&D employees use domain accounts to log in to AD domains and access network resources through the FW. They can
access network resources only after successful logins.
Marketing employees use domain accounts to log in to AD domains and access network resources through the FW. They
can access network resources only after successful logins.
--------------------------------------------------------------------------------
Access Type: local
Authentication Mode: Single Sign-on
Build ID: 0
User Name: [email protected] Parent User Group: /cce.com/research
--------------------------------------------------------------------------------
#
sysname FW
#
enable
plug-in shared-key %$%$B2N*$eJ0;'Nn'#ATC]t+Rri`%$%$
#
#
security-policy
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action exempt-auth
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
server searchdn ou=marketing,dc=cce,dc=com
server searchdn ou=research,dc=cce,dc=com
#
aaa
domain cce.com
14.15 CLI: Example for Configuring AD SSO for Internet Access Users (No-Plug-In
Mode)
This section describes how to configure AD Single Sign On (SSO) for Internet access users when a FW works as an egress gateway. In this
mode, the SSO program is not installed on the AD domain controller.
AD identity authentication is enabled on the intranet, and information about users and user groups is saved on an AD server.
Figure 14-37 AD SSO for Internet access users (non-plug-in mode)

R&D employees and marketing employees must use domain accounts to log in to AD domains and access network resources. R&D
employees and marketing employees must be identified by the user names that they use to log in to AD domains.
If the domain accounts of new employees have been created on an AD server but not stored on a FW, the FW must authenticate them
and automatically import their information based on the organizational structure on the AD server.
For security purposes, no programs can be installed on the AD server.
NOTE:
Without the plug-in, the FW cannot obtain user logout messages. Users go offline only when their connections time out.
In this example, users and user groups on the AD server are imported to the FW. If there are a large number of users on the network, you can import user groups only and
control user permissions by user groups.

2. On the FW, configure an authentication domain with the same name as the authentication domain on the AD server.
6. Set SSO parameters for the FW to listen to authentication results sent from the AD server to PCs.
In this example, authentication packets do not pass through the FW. Therefore, the authentication results must be mirrored to the
FW.
8. Configure the port mirroring function on the switch to mirror authentication packets to the FW.
Data Planning
ad.cce.com
dc=com
LDAP Port: 389
Administrator DN:
Admin@123
Server Type: AD
and user groups
minutes
AD SSO AD SSO: Enable Set SSO parameters on the FW and configure the FW to
Mode: No Plug-In receive user login information from the AD server.
Interface for Receiving Mirrored
Authentication Packets:
Server IP Address/Port:
10.3.0.251:88
Procedure
interfaces GigabitEthernet 1/0/3 and GigabitEthernet 1/0/4. You can configure other interfaces based on the networking diagram.
<FW> system-view
[FW-GigabitEthernet1/0/4] portswitch
GigabitEthernet 1/0/4 is used to receive mirrored packets from the switch and must work in switching mode.
a. Configure security policies between the Trust (AD server) and Local zones to ensure that the FWand AD server can
communicate.
[FW-policy-security-rule-local_policy_ad_01] source-zone local
[FW-policy-security-rule-local_policy_ad_01] destination-zone trust
[FW-policy-security-rule-local_policy_ad_02] source-zone trust
[FW-policy-security-rule-local_policy_ad_02] destination-zone local


[FW] ad-server template auth_server_ad
[FW-ad-auth_server_ad] ad-server authentication 10.3.0.251 88
[FW-ad-auth_server_ad] ad-server authentication base-dn dc=cce,dc=com
[FW-ad-auth_server_ad] ad-server authentication manager cn=administrator,cn=users Admin@123
[FW-ad-auth_server_ad] ad-server authentication host-name ad.cce.com
[FW-ad-auth_server_ad] ad-server authentication ldap-port 389
[FW-ad-auth_server_ad] ad-server user-filter sAMAccountName
[FW-ad-auth_server_ad] ad-server group-filter ou
[FW-ad-auth_server_ad] test-aaa testname testpassword ad-template auth_server_ad
[FW-ad-auth_server_ad] quit
[FW] aaa
[FW-aaa] quit
[FW] user-manage import-policy policy_import from ad
[FW-import-policy_import] server template auth_server_ad
[FW-import-policy_import] user-attribute sAMAccountName
NOTE:
To import user groups only, set import-type to group and set the new user option in 7 to new-user add-temporary group /cce.com auto-
importpolicy_import. Authenticated users use the permissions of their groups.
The user and user group filtering conditions in this example use the default values (&(|(objectclass=person)(objectclass=organizationalPerson))
(cn=*)(!(objectclass=computer))) and (|(objectclass=organizationalUnit)(ou=*)). To change them, run the user-filter and group-filter
commands.

[FW] aaa
[FW-aaa] quit

[FW] auth-policy
NOTE:
If the AD domain controller is deployed in the DMZ, ensure that the authentication policy on the FW exempts the authentication packets sent by users to the
AD server. You can run the display auth-policy command to check the authentication policy.
The security policy must also allow these packets to pass through. Therefore, configure the following security policy on the FW:
Source Zone: Trust
Destination Zone: DMZ
Destination Address/Region: The IP address of the AD server
Action: Permit
9. Set SSO parameters on the FW.

[FW] user-manage single-sign-on ad
[FW-sso-ad] mode no-plug-in
[FW-sso-ad] no-plug-in traffic server-ip 10.3.0.251 port 88
[FW-sso-ad] no-plug-in interface GigabitEthernet1/0/4
[FW-sso-ad] enable
[FW-sso-ad] quit
NOTE:
Running the command no-plug-in interface on the FW causes the interface to discard all packets except AD authentication packets. If both authentication
packets and service packets are mirrored by the switch to the FW deployed in bypass mode, do not run this command.

12. Configure the port mirroring function on the switch.
This example describes how to configure the port mirroring function on the Huawei S9700. For information about configuring other
functions, refer to the S9700 product documentation.
a. Configure GigabitEthernet 1/0/2 as the observing interface.

<Switch> system-view
[Switch] observe-port 1 interface GigabitEthernet 1/0/2
b. Configure GigabitEthernet 1/0/1 as the mirroring port to mirror incoming traffic.

[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] port-mirroring to observe-port 1 inbound
[Switch-GigabitEthernet1/0/1] quit
Verification
user groups.
R&D employees can use domain accounts to log in to AD domains and access network resources through the FW. They can
access network resources only after logging in successfully.
Marketing employees can use domain accounts to log in to AD domains and access network resources through the FW.
They can access network resources only after logging in successfully.
--------------------------------------------------------------------------------
Access Type: local
Build ID: 0
--------------------------------------------------------------------------------
#
sysname FW
#
mode no-plug-in
no-plug-in interface GigabitEthernet1/0/4
enable
#
#
security-policy
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action exempt-auth
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
portswitch
port link-type access
#
firewall zone trust
#
#
firewall zone dmz
#
#
aaa
domain cce.com
14.16 CLI: Example for Configuring TSM SSO for Internet Access Users (Users
Proactively Access the Controller)
works as an egress gateway. In this scenario, users proactively access the TSM portal authentication page and are authenticated before
accessing services.

If the TSM accounts of new employees have been created on a TSM server but not stored on a FW, the FW must consider them
temporary users and assign them the permissions of the specified group.
NOTE:
configure security policies to ensure that the FW and TSM server can communicate normally.
Data Planning
Encryption: AES128
User information import policy Name: policy_import Import users from the TSM server to the FW.
Server Type: TSM
and user groups
Server: 120 minutes
Parent group of new users Name: newuser New users are considered temporary and receive the
Procedure

NOTE:
The following uses the Agile Controller as an example. The user interface may vary in different versions. For details, refer to the Policy Center or Agile
Controller product documentation for your specific version.

NOTE:
The Port value must be the same as the TSM SSO listening port on the FW. The default value is 8001.
The Key and Encryption Algorithm value must be the same as the shared key and encryption algorithm in 4.
NOTE:
c. Click OK.
2. Set IP addresses for the interfaces and assign the interfaces to security zones on the FW. The following example describes how to
configure interface GigabitEthernet 1/0/3. You can configure other interfaces based on the networking diagram.
<FW> system-view
3. Configure security policies so that users, the TSM server, and the FW can communicate.
TSM server.
[FW-policy-security] rule name sec_policy_tsm
[FW-policy-security-rule-sec_policy_tsm] source-zone trust
[FW-policy-security-rule-sec_policy_tsm] source-address 10.3.0.0 24
[FW-policy-security-rule-sec_policy_tsm] destination-zone dmz
[FW-policy-security-rule-sec_policy_tsm] destination-address 10.2.0.0 24
[FW-policy-security-rule-sec_policy_tsm] action permit
[FW-policy-security-rule-sec_policy_tsm] quit
[FW-policy-security] rule name local_policy_tsm_01
[FW-policy-security-rule-local_policy_tsm_01] source-zone local
[FW-policy-security-rule-local_policy_tsm_01] destination-zone dmz
[FW-policy-security-rule-local_policy_tsm_01] action permit
[FW-policy-security-rule-local_policy_tsm_01] quit
[FW-policy-security-rule-local_policy_tsm_02] source-zone dmz
[FW-policy-security-rule-local_policy_tsm_02] destination-zone local

4. On a FW, set the parameters for communication with a TSM server.

[FW] tsm-server template auth_server_tsm
[FW-tsm-auth_server_tsm] tsm-server ip-address 10.2.0.50
[FW-tsm-auth_server_tsm] tsm-server port 8084
[FW-tsm-auth_server_tsm] tsm-server encryption-mode aes128 shared-key Admin@123
[FW-tsm-auth_server_tsm] test tsm-server template auth_server_tsm
[FW-tsm-auth_server_tsm] quit
[FW-tsm-auth_server_tsm] user-manage import-policy policy_import from tsm
[FW-import-policy_import] server template auth_server_tsm
[FW-import-policy_import] server basedn root
[FW-import-policy_import] destination-group /default
[FW-import-policy_import] time-interval 120
NOTE:

7. Create a parent group for new users on the FW.

[FW] user-manage group /default/newuser
[FW-usergroup-/default/newuser] quit

[FW] user-manage single-sign-on tsm
[FW-sso-tsm] enable
[FW-sso-tsm] quit
[FW] user-manage server-sync tsm
[FW-srv-sync-tsm] sync-address 10.3.0.0 24
[FW-srv-sync-tsm] enable
[FW-srv-sync-tsm] quit
9. Set the new user authentication option for the authentication domain.
[FW] aaa
[FW-aaa-domain-default] new-user add-temporary group /default/newuser
[FW-aaa] quit
11. In the authentication policy for users to access the TSM server, set the action to none so that authentication packets from users can
pass through the FW to the TSM server. In the authentication policy for user service traffic, set the action to authentication
exemption so that the FW can obtain user information through SSO.
[FW] auth-policy
[FW-policy-auth] rule name auth_policy_tsm
[FW-policy-auth-rule-auth_policy_tsm] source-zone trust
[FW-policy-auth-rule-auth_policy_tsm] destination-zone dmz
[FW-policy-auth-rule-auth_policy_tsm] source-address 10.3.0.0 24
[FW-policy-auth-rule-auth_policy_tsm] destination-address 10.2.0.50 32
[FW-policy-auth-rule-auth_policy_tsm] action none
[FW-policy-auth-rule-auth_policy_tsm] quit
NOTE:
Verification
user groups.
Verify that R&D employees can access network resources after successfully logging in with their TSM accounts and passwords.
Verify that marketing employees can access network resources after successfully logging in with their TSM accounts and passwords.
--------------------------------------------------------------------------------
Access Type: local
Build ID: 0
--------------------------------------------------------------------------------
#
sysname FW
#
enable
#
#
security-policy
source-zone trust
action permit
source-zone local
action permit
source-zone dmz
action permit
source-zone trust
action permit
#
auth-policy
source-zone trust
action none
source-zone trust
action exempt-auth
#
enable
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
server basedn root
time-interval 120
#
aaa
domain default
14.17 CLI: Example for Configuring TSM SSO for Internet Access Users (Users' HTTP
Services Are Redirected to the Controller)
works as an egress gateway. In this scenario, the FW redirects user HTTP requests to the TSM portal authentication page when an

The HTTP requests of R&D employees and marketing employees must be automatically redirected to the TSM portal authentication
page. These employees are not required to access the TSM portal authentication page proactively.
The FW saves department information, not user information. The permissions of authenticated users are controlled through the
groups to which they belong.
NOTE:
2. Configure a policy to import group information from the TSM server to the FW.
4. Set the new user authentication item for the authentication domain. New users are considered temporary users after being
authenticated.
5. Set the URL of the TSM portal authentication page as the redirected authentication page for unauthenticated users that directly
access HTTP services.
configure security policies to ensure that users, the FW, and the TSM server can communicate normally.
Data Planning
Encryption: AES128
User information import policy Name: policy_import Import groups from the TSM server to the FW.
Server Type: TSM
Import Type: Import only user
groups
Server: 120 minutes
Parent group of new users New users preferentially receive the All users passing TSM authentication are new users for the
permissions of their parent groups on the FW.
server. If their parent groups do not exist on
the server, users receive the permissions of
the /default group.
TSM authentication portal address http://10.2.0.50:8080/portal This address must be the same as the setting on the TSM
server.
Procedure

NOTE:
The following example uses the Agile Controller as an example. The user interface may vary in different versions. For details, refer to the Policy Center or
Agile Controller product documentation for your specific version.

NOTE:
The Port value must be the same as the TSM SSO listening port on the FW. The default value is 8001.
NOTE:
c. Click OK.
<FW> system-view
3. Configure security policies so that users, the TSM server, and the FW can communicate.
TSM server.
[FW-policy-security] rule name sec_policy_tsm
[FW-policy-security-rule-sec_policy_tsm] source-zone trust
[FW-policy-security-rule-sec_policy_tsm] source-address 10.3.0.0 24
[FW-policy-security-rule-sec_policy_tsm] destination-zone dmz
[FW-policy-security-rule-sec_policy_tsm] destination-address 10.2.0.0 24
[FW-policy-security-rule-sec_policy_tsm] action permit
[FW-policy-security-rule-sec_policy_tsm] quit
NOTE:
If the URL of the authentication page is a domain name and the DNS server for resolving the URL is deployed in the DMZ, enable the DNS
service from the Trust zone to the DMZ.
[FW-policy-security-rule-local_policy_tsm_01] source-zone local
[FW-policy-security-rule-local_policy_tsm_01] destination-zone dmz
[FW-policy-security-rule-local_policy_tsm_02] source-zone dmz
[FW-policy-security-rule-local_policy_tsm_02] destination-zone local

NOTE:
4. On a FW, set the parameters for communication with a TSM server.

[FW] tsm-server template auth_server_tsm
[FW-tsm-auth_server_tsm] tsm-server ip-address 10.2.0.50
[FW-tsm-auth_server_tsm] tsm-server port 8084
[FW-tsm-auth_server_tsm] tsm-server encryption-mode aes128 shared-key Admin@123
[FW-tsm-auth_server_tsm] test tsm-server template auth_server_tsm
[FW-tsm-auth_server_tsm] quit
[FW-tsm-auth_server_tsm] user-manage import-policy policy_import from tsm
[FW-import-policy_import] server template auth_server_tsm
[FW-import-policy_import] server basedn root
[FW-import-policy_import] destination-group /default
[FW-import-policy_import] import-type group
[FW-import-policy_import] time-interval 120
NOTE:

[FW] user-manage single-sign-on tsm
[FW-sso-tsm] enable
[FW-sso-tsm] quit
[FW] user-manage server-sync tsm
[FW-srv-sync-tsm] sync-address 10.3.0.0 24
[FW-srv-sync-tsm] enable
[FW-srv-sync-tsm] quit
8. Set the new user authentication option for the authentication domain.
[FW] aaa
[FW-aaa-domain-default] new-user add-temporary group /default auto-import policy_import
[FW-aaa] quit
9. Configure the portal authentication page.
[FW] user-manage portal-template portal
[FW-portal-template-portal] portal-url push information
[FW-portal-template-portal] portal-url http://10.2.0.50:8080/portal
The portal URL must be consistent with that configured on the Controller.
10. In the authentication policy for users to access the TSM server, set the action to none so that authentication packets from users can
pass through the FW to the TSM server. In the authentication policy for users to access other services, set the action to portal
authentication so that authentication is triggered by HTTP service access traffic from users.
[FW] auth-policy
[FW-policy-auth] rule name auth_policy_tsm
[FW-policy-auth-rule-auth_policy_tsm] source-zone trust
[FW-policy-auth-rule-auth_policy_tsm] destination-zone dmz
[FW-policy-auth-rule-auth_policy_tsm] source-address 10.3.0.0 24
[FW-policy-auth-rule-auth_policy_tsm] destination-address 10.2.0.50 32
[FW-policy-auth-rule-auth_policy_tsm] action none
[FW-policy-auth-rule-auth_policy_tsm] quit
[FW-policy-auth-rule-auth_policy_service] destination-zone untrust
[FW-policy-auth-rule-auth_policy_service] action auth portal-template portal
Verification
user groups.
Access http://www.example.org/ as an R&D employee. Verify that the HTTP request is redirected to the authentication page and
Access http://www.example.org/ as a marketing employee. Verify that the HTTP request is redirected to the authentication page and
--------------------------------------------------------------------------------
Access Type: local
Build ID: 0
--------------------------------------------------------------------------------
#
sysname FW
#
enable
user-manage portal-template portal 0
portal-url push information
portal-url http://10.2.0.50:8080/portal
#
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
source-zone local
action permit
source-zone dmz
action permit
#
auth-policy
source-zone trust
action none
source-zone trust
action auth portal-template portal
#
enable
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
server basedn root
import-type group
time-interval 120
#
aaa
domain default
new-user add-temporary group /default auto-import policy_import
This section describes how to configure RADIUS Single Sign On (SSO) for Internet access users when a FW works as an egress gateway.
Intranet users use the NAS to access the Internet.

The NAS sends user credentials to a RADIUS server for user authentication, and information about users and user groups is saved on
the RADIUS server.
Figure 14-40 RADIUS SSO for Internet access users
R&D employees and marketing employees must enter valid RADIUS accounts and passwords and pass authentication to access
network resources. R&D employees and marketing employees must be identified by the user names they use for RADIUS
authentication.
If the RADIUS accounts of new employees have been created on a RADIUS server but not stored on a FW, the FW considers them
temporary users and assigns them the permissions of the specified group.
NOTE:
4. Set the online user timeout duration to a larger value than the update interval of RADIUS accounting packets on the FW. This
prevents users from frequently having to log in to and log out of the FW. In the example, the timeout interval is set to 480 minutes.
6. Because the FW is deployed between users and the RADIUS server, authentication packets pass through the FW. Therefore,
configure an authentication policy to prevent the FW from authenticating the authentication requests destined for the RADIUS
server and configure security policies to ensure that the FW and RADIUS server can communicate normally.
Data Planning
RADIUS SSO RADIUS SSO: Enable Set SSO parameters on the FW for the FW to analyze the
Working mode: In-line RADIUS accounting packets passing by and obtain from
them the mappings between users and IP addresses.
Receiving Interface:
Traffic to be analyzed by RADIUS
SSO: 10.2.0.50:1813 (IP address of
the RADIUS server: accounting
port)
Procedure
<FW> system-view
a. Configure a security policy between the Trust zone (users and NAS device) and DMZ (RADIUS server) for users to be
authenticated by the RADIUS server.
[FW-policy-security] rule name policy_sec_radius
[FW-policy-security-rule-policy_sec_radius] source-zone trust
[FW-policy-security-rule-policy_sec_radius] destination-zone dmz
[FW-policy-security-rule-policy_sec_radius] destination-address 10.2.0.0 24
[FW-policy-security-rule-policy_sec_radius] action permit
[FW-policy-security-rule-policy_sec_radius] quit

3. Import users and user groups from a CSV file on the FW.
a. Choose Object > User > User Import > Local Import.
b. In User Import, click CSV Template Download and download the CSV template to your PC.
c. Enter the user information on the RADIUS server into a CSV file according to the template.
d. Upload the CSV file to FW using SFTP.
e. Import the CSV file.

[FW] user-manage user-import demo.csv auto-create-group override
4. Create a parent group for new users on the FW.

[FW] user-manage group /default/newuser
[FW-usergroup-/default/newuser] quit
[FW] user-manage single-sign-on radius
[FW-sso-radius] mode in-path
[FW-sso-radius] interface GigabitEthernet 1/0/3
[FW-sso-radius] traffic server-ip 10.2.0.50 port 1813
[FW-sso-radius] enable
[FW-sso-radius] quit
6. Set the new user option for the default authentication domain on the FW.
[FW] aaa
[FW-aaa-domain-default] new-user add-temporary group /default/newuser
[FW-aaa] quit
8. In the authentication policy for users to access the RADIUS server, set the action to none so that authentication packets from users
can pass through the FW to the RADIUS server. In the authentication policy for user service traffic, set the action to authentication
exemption so that the FW can obtain user information through SSO.
[FW] auth-policy
[FW-policy-auth] rule name auth_policy_radius
[FW-policy-auth-rule-auth_policy_radius] source-zone trust
[FW-policy-auth-rule-auth_policy_radius] destination-zone dmz
[FW-policy-auth-rule-auth_policy_radius] destination-address 10.2.0.50 32
[FW-policy-auth-rule-auth_policy_radius] action none
[FW-policy-auth-rule-auth_policy_radius] quit
NOTE:
Verification
user groups.
Verify that R&D employees can access network resources after successfully logging in to the NAS using RADIUS accounts and
passwords.
Verify that marketing employees can access network resources after successful logging in to the NAS using RADIUS accounts and
passwords.
--------------------------------------------------------------------------------
Access Type: local
Build ID: 0
--------------------------------------------------------------------------------
#
sysname FW
#
user-manage single-sign-on radius
enable
mode in-path
traffic server-ip 10.2.0.50 port 1813
#
security-policy
rule name sec_policy_radius
source-zone trust
action permit
source-zone trust
action permit
#
auth-policy
rule name auth_policy_radius
source-zone trust
action none
source-zone trust
action exempt-auth
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
domain default
14.19 CLI: Example for Configuring a RADIUS Server to Implement Authentication on

follows:
RADIUS authentication is enabled on the intranet, and information about users and user groups is saved on the RADIUS server.
Figure 14-41 RADIUS server deployed to authenticate Internet access users

The RADIUS server must authenticate Internet access users.
R&D employees and marketing employees must be authenticated on the FW portal to access network resources.
If the accounts of new employees have been created on a RADIUS server but not stored on a FW, the FW adds the accounts to a user
group after the new employees are authenticated. You can change the parent groups of the new employees.
NOTE:
1. Set parameters for the FW to communicate with the RADIUS server. Configure the FW to work as a client of the RADIUS server
and send user names and passwords to the RADIUS server for authentication.
2. Configure an authentication scheme and set the authentication mode to RADIUS.
3. Configure a net1 authentication domain on the FW that references the RADIUS server and authentication scheme. Then configure
the new user authentication option.
authentication and to allow the FW to communicate with the RADIUS server.
Data Planning
R&D employee Group Add the R&D employee to group research.

User
Display Name: R&D employee
Parent Group: /net1/research
Account
Marketing employee Group Add the marketing employee to group marketing.

User
Display Name: Marketing
employee
Parent Group: /net1/marketing
Account
Parent group of new users Name: newuser Add new users to group newuser.
Parent Group: /net1 New users can access network resources that are accessible
to the group newuser.
RADIUS server Name: auth_server_radius On the FW, set the parameters for communicating with a
Shared Key: secret RADIUS server.
Primary Authentication Server IP: The parameters on the FW must be consistent with those on
10.2.0.50 the RADIUS server.
Port: 1645
Authentication domain Name: net1 The net1 authentication domain is used during
Authentication Scheme: radius authentication.
management
auth_server_radius
Add to user group newuser
10.3.0.0/24
Action: auth
Procedure
<FW> system-view
2. Set the parameters for communication with the RADIUS server.

[FW] radius-server template auth_server_radius
[FW-radius-auth_server_radius] radius-server shared-key cipher secret
[FW-radius-auth_server_radius] radius-server authentication 10.2.0.50 1645
[FW-radius-auth_server_radius] radius-server user-name domain-included
[FW-radius-auth_server_radius] test-aaa testname testpassword radius-template auth_server_radius
[FW-radius-auth_server_radius] quit
NOTE:
The parameters on the FW must be consistent with those on the RADIUS server.
radius-server user-name domain-included indicates that the user name sent by the FW to the RADIUS server contains a domain name.
If the user name on the RADIUS server contains an at sign (@), run the radius-server user-name domain-included command on the FW.
If the user name on the RADIUS server does not contain an at sign (@), do not run this command.
If the RADIUS server does not support user names in user name@authentication domain name format, do not run the radius-server user-name domain-
included command on the FW. Otherwise, authentication will fail.
3. Configure an authentication scheme.

[FW] aaa
[FW-aaa] authentication-scheme radius
[FW-aaa-authen-radius] authentication-mode radius
[FW-aaa-authen-radius] quit
4. Create an authentication domain.

[FW-aaa] domain net1
[FW-aaa-domain-net1] authentication-scheme radius
[FW-aaa-domain-net1] radius-server auth_server_radius
[FW-aaa-domain-net1] service-type internetaccess
[FW-aaa-domain-net1] quit
[FW-aaa] quit
The authentication domain must be the same as the string following the at sign (@) in the user name on the RADIUS server.
5. Create a parent group for new users.
[FW] user-manage group /net1/newuser
[FW-usergroup-/net1/newuser] quit
6. Set the new user option for the authentication domain.

[FW] aaa
[FW-aaa] domain net1
[FW-aaa-domain-net1] new-user add-local group /net1/newuser
[FW-aaa-domain-net1] quit
[FW-aaa] quit
7. Import users and user groups from a CSV file.
a. Choose Object > User > Import User > Local Import.
b. In Import User, click Download CSV Template and download the CSV template to your PC.
c. Enter the user information on the RADIUS server into a CSV file according to the template.
NOTE:
The first level of the group path in the CSV file is the authentication domain name. Therefore, the login name does not contain "@domain-name."
In this example, the user name on the RADIUS server is user_0002@net1. Therefore, in the CSV file, the group path is /net1 and the login name
is user_0002.
d. Upload the CSV file to the FW using FTP.
e. Import the CSV file.

[FW] user-manage user-import demo.csv auto-create-group override

[FW] auth-policy
[FW-policy-auth-rule-auth_policy_service] action auth

[FW-policy-security] rule name policy_local_01
[FW-policy-security-rule-policy_local_01] source-zone trust
[FW-policy-security-rule-policy_local_01] destination-zone local
[FW-policy-security-rule-policy_local_01] source-address 10.3.0.0 24
[FW-policy-security-rule-policy_local_01] service protocol tcp destination-port 8887
[FW-policy-security-rule-policy_local_01] action permit
[FW-policy-security-rule-policy_local_01] quit
b. Configure a security policy to allow the FW to communicate with the RADIUS server.
[FW-policy-security-rule-policy_local_02] source-zone local
[FW-policy-security-rule-policy_local_02] destination-zone dmz
[FW-policy-security-rule-policy_local_02] destination-address 10.2.0.50 32
NOTE:

NOTE:
The following uses Shiva Access Manager as an example. To configure your specific RADIUS server, refer to relevant product documentation.
a. Install Shiva Access Manager on the PC. (The installation procedure is omitted here.)
b. Choose Start > Programs > Shiva Access Manager > Shiva Access Manager to start the Shiva Access Manager
program.
c. In the dialog box displayed, enter the user name and password. The default user name is supermanager and the password
Figure 14-42 Logging in to the Shiva Access Manager server
d. Click Login. In the dialog box displayed, click Start Console Now, as shown in Figure 14-43.
Figure 14-43 Starting the Shiva Access Manager software
e. In the dialog box displayed, enter the user name and password. The default user name is supermanager and the password
Figure 14-44 Logging in to the Shiva Access Manager console
f. Click Login. The Shiva Access Manager Console interface is displayed, as shown in Figure 14-45.
Figure 14-45 Shiva access manager console
g. Click on the toolbar. In the Encryption Configuration dialog box, enter the NAS address and key, as shown in Figure
14-46. The NAS address is the interface IP address for communication between the FW and the RADIUS server. The key
is the shared key that is set on the FW side.
h. Click Add. The added NAS address is displayed under NAS List, as shown in Figure 14-47.
i. Click Exit.
j. Click on the toolbar. In the General Options dialog box, set Authentication UDP Port, as shown in Figure 14-48.
Figure 14-48 Setting the RADIUS server ports
k. Click on the toolbar. In the Manage Users dialog box, click the General Attributes tab and set the parameters, as shown
in Figure 14-49. Username and Password are the user name and password used for client access. Username is the user
followed by the domain name set on the FW side.
NOTICE:
Do not select Disable Account. Otherwise, the configuration will fail.
Figure 14-49 Configuring users
l. Click Add User.
Verification
user groups.
--------------------------------------------------------------------------------
Access Type: local
Authentication Mode: Password (RADIUS)
Build ID: 0
User Name: user_0002@net1 Parent User Group: /net1/research
--------------------------------------------------------------------------------
#
sysname FW
#
radius-server template auth_server_radius
radius-server shared-key cipher %$%$73pu<+^]XV9mn=*qd}_,r3*!%$%$
radius-server authentication 10.2.0.50 1645
radius-server user-name domain-included
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
authentication-mode radius
#
domain net1
radius-server auth_server_radius
new-user add-local group /net1/newuser
#
auth-policy
source-zone trust
action auth
#
security-policy
source-zone trust
action permit
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
test-aaa testname testpassword radius-template auth_server_radius
14.20 CLI: Example for Configuring an LDAP Server to Implement Authentication on

This section describes how to configure a Sun ONE LDAP server to authenticate Internet access users when a FW works as an egress gateway.
follows:
The intranet has a Sun ONE LDAP server that stores information about users, departments, and groups (named static groups on the
LDAP server).
Figure 14-50 LDAP server deployed to authenticate Internet access users

The LDAP server must authenticate Internet access users.
R&D employees and marketing employees must be authenticated on the FW portal to access network resources.
If the domain accounts of new employees have been created on an LDAP server but not stored on a FW, the FW authenticates them
and automatically imports their information based on the organizational structure on the LDAP server.
NOTE:
Information about users, departments, and groups (static groups) on the LDAP server must be imported to the FW. Select the import type as appropriate. For example,
when a large number of users exist on the LDAP server, you can import departments and groups and implement department- and group-specific permission control.
1. Set parameters for the FW to communicate with the LDAP server. Configure the FW to work as a client of the LDAP server and
send user names and passwords to the LDAP server for authentication.
2. Configure an authentication scheme and set the authentication mode to LDAP.
3. On the FW, configure an authentication domain with the same name as the authentication domain on the LDAP server.
User groups on the FW correspond to departments on the LDAP server, and security groups on the FW correspond to static groups
on the LDAP server.
authentication and to allow the FW to communicate with the LDAP server.
Data Planning
LDAP server Name: auth_server_ldap On a FW, set the parameters for communication with an
Primary Authentication Server IP: LDAP server.
Port: 389 those on the LDAP server.
Server Type: Sun ONE LDAP
Base DN: dc=cce, dc=com
LDAP Port: 389
Administrator DN: uid=admin_test
Admin@123
User information import policy Name: policy_import Import users from the LDAP server to the FW.
Server Type: LDAP
Server Name: auth_server_ldap
Import Type: All
minutes
Authentication domain Name: cce.com The cce.com authentication domain is used during
Authentication Scheme: ldap authentication.
management
auth_server_ldap
Imports the user based on the
import policy.
10.3.0.0/24
Action: auth
Procedure
<FW> system-view

[FW-policy-security-rule-policy_local_01] source-zone trust
[FW-policy-security-rule-policy_local_01] destination-zone local
[FW-policy-security-rule-policy_local_01] source-address 10.3.0.0 24
[FW-policy-security-rule-policy_local_01] service protocol tcp destination-port 8887
b. Configure a security policy to allow the FW to communicate with the LDAP server.
[FW-policy-security-rule-policy_local_02] source-zone local
[FW-policy-security-rule-policy_local_02] destination-zone dmz
[FW-policy-security-rule-policy_local_02] destination-address 10.2.0.50 32

NOTE:

3. Set the parameters for communication with the LDAP server.

[FW] ldap-server template auth_server_ldap
[FW-ldap-auth_server_ldap] ldap-server authentication 10.2.0.50 389
[FW-ldap-auth_server_ldap] ldap-server authentication base-dn dc=cce,dc=com
[FW-ldap-auth_server_ldap] ldap-server authentication manager uid=admin_test Admin@123
[FW-ldap-auth_server_ldap] ldap-server group-filter ou
[FW-ldap-auth_server_ldap] ldap-server user-filter uid
[FW-ldap-auth_server_ldap] ldap-server server-type sun-one
[FW-ldap-auth_server_ldap] test-aaa testname testpassword ldap-template auth_server_ldap
[FW-ldap-auth_server_ldap] quit
The parameters on the FW must be consistent with those on the LDAP server.
4. Configure an authentication scheme.
[FW] aaa
[FW-aaa] authentication-scheme ldap
[FW-aaa-authen-ldap] authentication-mode ldap
[FW-aaa-authen-ldap] quit
[FW-aaa-domain-cce.com] authentication-scheme ldap
[FW-aaa-domain-cce.com] ldap-server auth_server_ldap
[FW-aaa] quit
The domain name must be the same as that on the LDAP server.
[FW] user-manage import-policy policy_import from ldap
[FW-import-policy_import] server template auth_server_ldap
[FW-import-policy_import] user-attribute uid
[FW-import-policy_import] import-type all
[FW] aaa
[FW-aaa] quit

[FW] auth-policy
[FW-policy-auth-rule-auth_policy_service] action auth
Verification
user groups.
--------------------------------------------------------------------------------
Access Type: local
Authentication Mode: Password (LDAP)
Build ID: 0
--------------------------------------------------------------------------------
#
sysname FW
#
ldap-server template auth_server_ldap
ldap-server authentication 10.3.0.50 389
ldap-server authentication base-dn dc=cce,dc=com
ldap-server authentication manager uid=admin_test %$%$>884X|-geW:1_*O\(6EI+|sj%$%$ %$%$>884X|-geW:1_*O\(6EI+|sj%$%$
ldap-server group-filter ou
ldap-server user-filter uid
ldap-server server-type sun-one
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
#
#
firewall zone dmz
#
aaa
authentication-mode ldap
#
domain cce.com
ldap-server auth_server_ldap
#
user-manage import-policy policy_import from ldap
server template auth_server_ldap
user-attribute uid
user-filter (&(|(objectclass=person)(objectclass=organizationalPerson))(uid=*))
security-group-filter (&(objectclass=groupofuniquenames)(!(memberURL=*)))
import-type all
#
auth-policy
source-zone trust
action auth
#
security-policy
source-zone trust
action permit
source-zone local
action permit
source-zone trust
action permit
source-zone trust
action permit
test-aaa testname testpassword ldap-template auth_server_ldap
14.21 CLI: Example for Configuring Authentication on Users at the Headquarters and
Branch Offices Using an AD Server
This section provides an example for configuring authentication on Internet access users and remote access users when a FW works as an
egress gateway and VPN access gateway.
As shown in Figure 14-51, FWs are deployed at the network borders of the headquarters and branch office of an enterprise. Details are as
follows:
The AD identity authentication mechanism is enabled for the enterprise, and information about users and user groups are saved on an
AD server. The enterprise has top executives, R&D employees, and marketing employees. The R&D and marketing employees work
in the headquarters and branch offices.
The top executives, R&D employees, and marketing employees in the headquarters must be authenticated by FW_A before accessing
network resources.
Top executives use the fixed IP address (10.3.0.2). To improve efficiency, top executives are exempted from authentication,
but for security considerations, the accounts used by top executives must be bound to IP addresses and MAC addresses.
R&D employees and marketing employees use domain accounts to log in to AD domains and access network resources.
An IPSec tunnel is established between the headquarters and a branch office. Employees in the branch office must be authenticated
by FW_A before accessing the resources in the headquarters.
The R&D and marketing employees on the move can connect to FW_A using SSL VPN to access network resources.
Figure 14-51 Authentication on users at the headquarters and branch offices using an AD server
NOTE:
1. On the FW_A, set the parameters for communication with an AD server.

2. Configure an authentication domain on the FW_A. The domain name must be the same as that on the AD server.
3. Configure a policy to import user group information from the AD server to the FW_A.
4. Set a new user authentication item for the authentication domain. If a user passes the authentication but does not exist on FW_A, the
user is a temporary user and is granted the permission of its parent group.
NOTE:
In this example, only the organizational unit on the AD server is imported. Therefore, all users are new to FW_A. When you configure a new user
authentication item, the user is not added to the local user list. Its parent group is obtained based on the server import policy, and the user is granted the
permission of its parent group.
5. Configure authentication for headquarters employees.

Configure authentication exemption for top executives.
Create group and user objects for top executives and bidirectionally bind the user objects to IP and MAC addresses. Create
an authentication policy and set the authentication action to no authentication.
Configure AD SSO.
Employees are required to pass FW_A authentication after AD domain authentication. Therefore, configure AD SSO on
FW_A to ensure that FW_A can monitor the authentication result packets that the AD server sends to the employees' PCs.
6. Configure authentication on branch employees and the employees on the move.
a. Configure an authentication scheme and set the authentication mode to AD.

b. Configure an authentication policy for branch employees connected to the headquarters over IPSec tunnels to be
authenticated by FW_A before accessing network resources.
Data Planning
AD server Name: auth_server_ad On a FW_A, set the parameters for communication with an
Primary Authentication Server IP: AD server.
10.2.0.50 The parameter settings on the FW_A must be consistent
Port: 88 with those on the AD server.
ad.cce.com
dc=com
LDAP Port: 389
Administrator DN:
Admin@123
Authentication domain Name: cce.com The domain name must be the same as that on the AD
Access Control: SSL VPN Access server.
and Internet behavior management
auth_server_ad
Authentication scheme: ad
New users preferentially use the
permissions of their parent groups
on the server. If their parent groups
do not exist on the server, users use
the permission of the /cce.com
group.
User information import policy Name: policy_import Import users from the AD server to the FW_A.
Server Type: AD
Import Type: Import user groups
minutes
AD SSO AD SSO: Enable Set SSO parameters on the FW_A and configure the FW_A
to receive the user login information from the AD server.
Mode: No-Plug-In
10.2.0.50:88
Top executive Group Add the top executive to the group manager and configure
Name: manager bidirectional binding for the top executive and the IP and
MAC addresses. No password is required for the top
Parent Group: /cce.com
executive. A FW_A implements authentication on the top
User executive based on the bound IP and MAC addresses.
Display Name: Top executive A multiple user accounts.
Parent Group: /cce.com/manager
Account
binding
bbbb-cccc
Authentication policy for top executives Name: policy_auth_01 Authentication is not implemented on the top executive who
Source Zone: trust meets matching conditions. FW_A identifies the top
executive based on the bound IP and MAC addresses.
The top executive can access network resources without
entering any user name and password.
10.3.0.2/32
Action: exempt-auth
Authentication policy for branch office Name: policy_auth_02 Employees in the branch office must pass the authentication
Source Zone: untrust before accessing the resources in the headquarters.
10.4.0.0/16
Action: auth
Procedure
1. Set IP addresses for interfaces and assign the interfaces to security zones. The following example describes how to configure
<FW_A> system-view
[FW_A] interface GigabitEthernet 1/0/3
[FW_A-GigabitEthernet1/0/3] ip address 10.3.0.1 24
[FW_A-GigabitEthernet1/0/3] quit
[FW_A] firewall zone trust
[FW_A-zone-trust] add interface GigabitEthernet 1/0/3
[FW_A-zone-trust] quit
a. Configure security policies between the DMZ (AD server) and Local zone to ensure the communication among the FW
and AD server.
[FW_A] security-policy
[FW_A-policy-security] rule name local_policy_ad_01
[FW_A-policy-security-rule-local_policy_ad_01] source-zone local
[FW_A-policy-security-rule-local_policy_ad_01] destination-zone dmz
[FW_A-policy-security-rule-local_policy_ad_01] destination-address 10.2.0.50 32
[FW_A-policy-security-rule-local_policy_ad_01] action permit
[FW_A-policy-security-rule-local_policy_ad_01] quit
[FW_A-policy-security] rule name local_policy_ad_02
[FW_A-policy-security-rule-local_policy_ad_02] source-zone dmz
[FW_A-policy-security-rule-local_policy_ad_02] destination-zone local
[FW_A-policy-security-rule-local_policy_ad_02] source-address 10.2.0.50 32
[FW_A-policy-security-rule-local_policy_ad_02] action permit
[FW_A-policy-security-rule-local_policy_ad_02] quit
[FW_A-policy-security] rule name policy_sec_02
[FW_A-policy-security-rule-policy_sec_02] source-zone trust
[FW_A-policy-security-rule-policy_sec_02] destination-zone dmz
[FW_A-policy-security-rule-policy_sec_02] source-address 10.3.0.0 24
[FW_A-policy-security-rule-policy_sec_02] action permit
[FW_A-policy-security-rule-policy_sec_02] quit
[FW_A-policy-security] quit
c. Configure a security policy to allow branch office employees to access the authentication page.
[FW_A-policy-security] rule name policy_sec_03
[FW_A-policy-security-rule-policy_sec_03] destination-zone local
[FW_A-policy-security-rule-policy_sec_03] service protocol tcp destination-port 8887
[FW_A-policy-security-rule-policy_sec_03] action permit
[FW_A-policy-security-rule-policy_sec_03] quit
3. On a FW_A, set the parameters for communication with an AD server.

[FW_A] ad-server template auth_server_ad
[FW_A-ad-auth_server_ad] ad-server authentication 10.2.0.50 88
[FW_A-ad-auth_server_ad] ad-server authentication base-dn dc=cce,dc=com
[FW_A-ad-auth_server_ad] ad-server authentication manager cn=administrator,cn=users Admin@123
[FW_A-ad-auth_server_ad] ad-server authentication host-name ad.cce.com
[FW_A-ad-auth_server_ad] ad-server authentication ldap-port 389
[FW_A-ad-auth_server_ad] ad-server user-filter sAMAccountName
[FW_A-ad-auth_server_ad] ad-server group-filter ou
[FW_A-ad-auth_server_ad] test-aaa testname testpassword ad-template auth_server_ad
[FW_A-ad-auth_server_ad] quit
[FW_A] aaa
[FW_A-aaa] domain cce.com
[FW_A-aaa-domain-cce.com] service-type internetaccess ssl-vpn
[FW_A-aaa-domain-cce.com] quit
[FW_A-aaa] quit
5. Configure a policy to import user group information from the AD server to the FW_A
a. Configure a policy to import user group information from the AD server.

[FW_A] user-manage import-policy policy_import from ad
[FW_A-import-policy_import] server template auth_server_ad
[FW_A-import-policy_import] server basedn dc=cce,dc=com
[FW_A-import-policy_import] destination-group /cce.com
[FW_A-import-policy_import] user-attribute sAMAccountName
[FW_A-import-policy_import] import-type group
[FW_A-import-policy_import] import-override enable
[FW_A-import-policy_import] sync-mode incremental schedule interval 120
[FW_A-import-policy_import] quit
NOTE:
The user and user group filtering conditions in this example use the default values (&(|(objectclass=person)
(objectclass=organizationalPerson))(cn=*)(!(objectclass=computer))) and (|(objectclass=organizationalUnit)(ou=*)). To change them, run
the user-filter and group-filter commands.
b. Execute the import policy to import users to the FW_A.

[FW_A] execute user-manage import-policy policy_import
6. Set the new user option for the authentication domain on the FW_A.
[FW_A] aaa
[FW_A-aaa-domain-cce.com] new-user add-temporary group /cce.com auto-import policy_import
[FW_A-aaa] quit
[FW_A] user-manage online-user aging-time 480
8. Configure authentication exemption for top executives.
a. Create a user group object and a user object for a top executive.
[FW_A] user-manage group /cce.com/manager
[FW_A-usergroup-/cce.com/manager] quit
[FW_A] user-manage user user_0001
[FW_A-localuser-user_0001] alias Supervisor
[FW_A-localuser-user_0001] parent-group /cce.com/manager
[FW_A-localuser-user_0001] undo multi-ip online enable
[FW_A-localuser-user_0001] bind mode bidirectional
[FW_A-localuser-user_0001] bind ipv4 10.3.0.2 mac aaaa-bbbb-cccc
[FW_A-localuser-user_0001] quit
b. Configure authentication policies.

[FW_A] auth-policy
[FW_A-policy-auth] rule name policy_auth_01
[FW_A-policy-auth-rule-policy_auth_01] source-zone trust
[FW_A-policy-auth-rule-policy_auth_01] source-address 10.3.0.2 32
[FW_A-policy-auth-rule-policy_auth_01] action exempt-auth
[FW_A-policy-auth-rule-policy_auth_01] quit
[FW_A-policy-auth] quit
9. Configure AD SSO for headquarters employees.
a. Set SSO parameters on the FW_A.

[FW_A] user-manage single-sign-on ad
[FW_A-sso-ad] mode no-plug-in
[FW_A-sso-ad] no-plug-in traffic server-ip 10.2.0.50 port 88
[FW_A-sso-ad] enable
[FW_A-sso-ad] quit
In this example, AD SSO is configured in no-plug-in mode. For configuration in plug-in mode, see CLI: Example for
Configuring AD SSO for Internet Access Users (Install ADSSO_Setup.exe to receive messages from PCs).
b. Configure authentication policies. Configure the action in the authentication policy for users to access the AD server as
no-authentication so that the users' authentication packets can go through the FW to the AD server. Configure the action
in the authentication policy for users' service traffic to authentication exemption so that the FW can obtain user
information through SSO.
[FW] auth-policy
[FW-policy-auth] rule name auth_policy_ad
[FW-policy-auth-rule-auth_policy_ad] source-zone trust
[FW-policy-auth-rule-auth_policy_ad] destination-zone dmz
[FW-policy-auth-rule-auth_policy_ad] source-address 10.3.0.0 24
[FW-policy-auth-rule-auth_policy_ad] destination-address 10.2.0.50 32
[FW-policy-auth-rule-auth_policy_ad] action none
[FW-policy-auth-rule-auth_policy_ad] quit
NOTE:
If the action of the authentication policy is set to authentication exemption, the FW obtains user information through SSO and permits the traffic
when user information fails to be obtained during SSO authentication. If the network has high security requirements, set the action of the
authentication policy to portal authentication. Then the FW will implement portal authentication on the users failing the SSO authentication.
10. Configure authentication for branch employees and the employees on the move.
a. Configure an authentication scheme, set the authentication mode to AD authentication, and reference an AD server.
[FW_A] aaa
[FW_A-aaa] authentication-scheme ad
[FW_A-aaa-authen-ad] authentication-mode ad
[FW_A-aaa-authen-ad] quit
[FW_A-aaa-domain-cce.com] authentication-scheme ad
[FW_A-aaa-domain-cce.com] ad-server auth_server_ad
[FW_A-aaa] quit
b. Configure an authentication policy for branch employees.

[FW_A] auth-policy
[FW_A-policy-auth] rule name policy_auth_02
[FW_A-policy-auth-rule-policy_auth_02] source-zone untrust
[FW_A-policy-auth-rule-policy_auth_02] source-address 10.4.0.0 16
[FW_A-policy-auth-rule-policy_auth_02] action auth
[FW_A-policy-auth-rule-policy_auth_02] quit
[FW_A-policy-auth] quit
proxy policies, and audit policies that reference the user group objects.
Verification
Run the display user-manage group commands on the FW_A to display information about user groups.
The top executive user_0001 can access network resources without authentication. Other users cannot use the user name of the top
executive to access network resources because their IP addresses are not 10.3.0.2 and their MAC addresses are not aaaa-bbbb-cccc.
Employees in the headquarters can use domain accounts and passwords to log in to the AD domain and access network resources.
An employee in the branch office accesses https://10.3.0.1:8887 and enters the user name and password for authentication. After the
authentication succeeds, the employee can access the network resources in the headquarters.
An employee on the move accesses the authentication page of the SSL VPN virtual gateway and enters the user name and password
for authentication. After the authentication succeeds, the employee can access the network resources in the headquarters.
Run the display user-manage online-user command on the FW_A to display information about online users.
#
sysname FW_A
#
mode no-plug-in
enable
#
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
firewall zone dmz
set priority 50
#
security-policy
source-zone local
action permit
source-zone dmz
action permit
source-zone trust
action permit
action permit
#
import-type group
#
aaa
authentication-mode ad
#
domain cce.com
service-type internetaccess ssl-vpn
ad-server auth_server_ad
new-user add-temporary group /cce.com auto-import policy_import
#
auth-policy
source-zone trust
action exempt-auth
rule name auth_policy_ad
source-zone trust
action none
source-zone trust
action exempt-auth
source-zone untrust
action auth
user-manage group /cce.com/manager
alias Supervisor
parent-group /cce.com/manager

User Authentication USG Firewall

Uploaded by

Copyright:

Available Formats

User Authentication USG Firewall

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Authentication USG Firewall

Uploaded by

Copyright:

Available Formats

11/24/2019 User Authentication

1. Create authentication policies and configure matching conditions and actions.

R&D employee Group Add each R&D employee to group research.

Marketing employee Group Add each marketing employee to group marketing.

Authentication policy Name: policy_auth_01 Authentication is implemented on R&D employees,

Item Data Description

Click Add and create user groups and users.

a. Configure a security policy to allow users to access the authentication page.

Source Zone Trust

Destination Zone Local

Source Address 10.3.0.0/24

Service User-defined service (TCP/8887)

b. Configure a security policy to allow users to access the Internet.

Source Zone Trust

Destination Zone Untrust

Source Address 10.3.0.0/24

c. Configure a security policy to allow users to access the server cluster.

Destination Zone DMZ

Source Address 10.3.0.0/24

Verify that the following conditions are true:

Item Data Description

Authentication domain Name: default -

Click Add and create user groups and users.

b. Choose Add a User and create a user object for an executive.

a. Configure a security policy to allow users to access the Internet.

Source Zone Trust

Destination Zone Untrust

Source Address 10.3.0.0/24

b. Configure a security policy to allow users to access the server cluster.

Source Zone Trust

Destination Zone DMZ

Source Address 10.3.0.0/24

The configuration roadmap is as follows:

1. On a FW, set the parameters for communication with an AD server.

Item Data Description

FW Parameter Enable the AD SSO service on the AD monitor, configure

Source Zone local

Destination Zone trust

Destination Address 10.3.0.251/32,10.3.0.254/32

Source Zone trust

Destination Zone local

Source Address 10.3.0.251/32,10.3.0.254/32

b. Configure a security policy to allow users to access the Internet.

Source Zone trust

Destination Zone untrust

Source Address 10.3.0.0/24

c. Configure a security policy to allow users to access the server cluster.

Source Zone trust

Destination Zone dmz

Source Address 10.3.0.0/24

b. Click Next and specify an installation directory, click Install.

c. Start the ADSSO Agent program.

d. Configure AD SSO parameters.

ii. Add AD servers.

iv. Start the SSO service.

Windows 2008 Server and Windows 2012 Server

i. Choose Start > Administrative Tools > Group Policy Management.

Verify that the following conditions are true:

Figure 14-11 AD SSO for Internet access users (non-plug-in Mode)

The configuration roadmap is as follows: