总是发现网络中有未授权的互联网流量！怎么办？
简介
介绍用户与认证的定义和目的。
用户
用户指的是访问网络资源的主体，表示“谁”在进行访问，是网络访问行为的重要标识。FW上的用户包括上网用户和接入用户两种形式：
- 上网用户内部网络中访问网络资源的主体，如企业总部的内部员工。上网用户可以直接通过FW访问网络资源。
- 接入用户外部网络中访问网络资源的主体，如企业的分支机构员工和出差员工。接入用户需要先通过SSL VPN、L2TP VPN、IPSec VPN或PPPoE方式接入到FW，然后才能访问企业总部的网络资源。
认证
FW通过认证来验证访问者的身份，FW对访问者进行认证的方式包括：
- 本地认证访问者通过Portal认证页面将标识其身份的用户名和密码发送给FW，FW上存储了密码，验证过程在FW上进行，该方式称为本地认证。
- 服务器认证访问者通过Portal认证页面将标识其身份的用户名和密码发送给FW，FW上没有存储密码，FW将用户名和密码发送至第三方认证服务器，验证过程在认证服务器上进行，该方式称为服务器认证。
- 单点登录访问者将标识其身份的用户名和密码发送给第三方认证服务器，认证通过后，第三方认证服务器将访问者的身份信息发送给FW。FW只记录访问者的身份信息不参与认证过程，该方式称为单点登录（Single Sign-On）。
对于上网用户，访问网络资源时FW会对其进行认证。对于接入用户，接入FW时FW会对其进行认证；访问网络资源时，FW还可以根据需要来对其进行二次认证。
目的
如图1所示，在FW上部署用户管理与认证，将网络流量的IP地址识别为用户，为网络行为控制和网络权限分配提供了基于用户的管理维度，实现精细化的管理：
- 基于用户进行策略的可视化制定，提高策略的易用性。
- 基于用户进行威胁、流量的报表查看和统计分析，实现对用户网络访问行为的审计。
- 解决了IP地址动态变化带来的策略控制问题，即以不变的用户应对变化的IP地址。
上网用户访问网络资源
介绍上网用户访问网络资源时，如何实施用户管理与认证机制。
FW作为企业的出口网关，内部网络中的访问者通过FW访问资源服务器或Internet时，为了实现基于用户的访问行为控制，需要在FW上完成如下任务：
- 存储用户信息，使用户可以被安全策略、策略路由、带宽策略、SSL加密流量检测、审计策略以及配额控制策略所引用。
- 对访问者进行认证，验证访问者的身份，同时获取用户与IP地址的对应关系。
在不同的网络环境下，针对这两个任务也有不同的实现方式，下面分情况介绍。
FW内置Portal认证
FW作为企业的出口网关，已部署了内置Portal认证页面用于对用户进行认证，FW接收到认证请求后可转发认证请求至本地用户数据库、认证服务器，由FW、认证服务器完成用户认证。
- 本地认证管理员依据企业的组织结构，在FW上创建相应的用户/组，并设置用户的密码。认证时，由FW来验证访问者使用的用户和密码，对访问者进行认证。如图1所示，FW提供了内置Portal认证页面，访问者主动访问认证页面或者访问者访问HTTP业务被FW重定向到认证页面，由FW完成用户认证。认证成功后，FW记录访问者使用的用户和IP地址之间的对应关系。访问者访问网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。图1 本地认证时用户管理和认证方式示意图
- 服务器认证企业已经部署了RADIUS（Remote Authentication Dial In User Service）、HWTACACS（HuaWei Terminal Access Controller Access Control System）、AD、LDAP（Lightweight Directory Access Protocol）认证服务器，并在认证服务器上存储了用户/组和密码等信息。对于RADIUS、HWTACACS服务器，管理员需要根据现有的组织结构，在FW上手动创建或者使用文件批量导入相应的用户/组。对于AD或LDAP服务器，管理员可以将AD或LDAP服务器中的用户信息导入到FW上，以便后续管理员可以在FW上通过策略来控制不同用户/组对网络的访问行为。如图2所示，FW提供了内置Portal认证页面，访问者主动访问认证页面或者访问者访问HTTP业务被FW重定向到认证页面，FW作为认证服务器的代理客户端，将用户名和密码发送给认证服务器进行认证。访问者经过认证服务器认证成功后，FW会记录访问者使用的用户和IP地址之间的对应关系。访问者访问网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。图2 服务器认证时用户管理和认证方式示意图
此处以认证服务器位于资源服务器所在的网络为例进行说明，描述同样适用于认证服务器位于访问者所在网络的情况。
自定义Portal认证
企业已部署了外部Portal服务器，用于和FW联动对用户进行认证，例如，部署Agile Controller作为外部Portal服务器参与用户认证。
如图3所示，FW收到访问者的HTTP业务时，将HTTP请求重定向到Agile Controller的Portal认证页面，由Agile Controller处理认证请求。
用户认证通过后可以访问网络资源。
免认证
企业高级管理者希望不输入用户名和密码就可以完成认证并访问网络资源，FW提供免认证满足此需求。管理员在FW上创建高级管理者对应的用户，并将用户与IP、MAC或IP-MAC进行双向绑定。高级管理者访问网络资源时，FW通过识别IP/MAC和用户的双向绑定关系，确定访问者的身份。进行免认证的访问者只能使用特定的IP/MAC地址来访问网络资源。
AD单点登录
企业已经部署了AD（Active Directory）身份验证机制，AD服务器上存储了用户/组和密码等信息。管理员可以将AD服务器上的组织结构和账号信息导入到FW。对于AD服务器上新创建的用户信息，还可以按照一定的时间间隔定时导入。以便后续管理员可以在FW上通过策略来控制不同用户/组对网络的访问行为。
认证时，由AD服务器对访问者进行认证，并将认证信息发送至FW，使FW能够获取用户与IP地址的对应关系。访问者通过AD服务器的认证后，就可以直接访问网络资源，无需再由FW进行认证，这种认证方式也称为“AD单点登录”。
如图4所示，AD服务器上存储了用户/组和密码等信息，FW上可以存储用户/组信息以及组织结构关系。内部网络中的访问者使用AD域账号和密码进行认证，认证通过后，AD服务器将域账号和IP地址发送至FW，FW记录访问者使用的用户和IP地址之间的对应关系。访问者访问网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。
此处以AD服务器位于访问者所在的网络为例进行说明，如果AD服务器位于资源服务器所在的网络，则需要在FW上配置认证策略时，不对访问者与AD服务器之间的认证报文进行认证，同时在安全策略中保证这类报文可以正常通过FW。
Agile Controller单点登录
企业已经部署了Agile Controller（Terminal Security Management）身份验证机制，Agile Controller服务器上存储了用户/组和密码等信息。管理员可以将Agile Controller服务器上的组织结构和账号信息导入到FW，以便后续管理员可以在FW上通过策略来控制不同用户/组对网络的访问行为。
认证时，由Agile Controller服务器对访问者进行认证，并将认证信息发送至FW，使FW能够获取用户与IP地址的对应关系。访问者通过Agile Controller服务器的认证后，就可以直接访问网络资源，无需再由FW进行认证，这种认证方式也称为“Agile Controller单点登录”。
如图5所示，Agile Controller服务器上存储了用户/组和密码等信息，FW上可以存储用户/组信息。内部网络中的访问者使用Agile Controller账号和密码进行认证，认证通过后，Agile Controller服务器将账号和IP地址发送至FW，FW记录访问者使用的用户和IP地址之间的对应关系。访问者访问网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。
图5 Agile Controller单点登录时用户管理和认证方式示意图
目前FW支持与华为公司的Agile Controller系统（Policy Center或Agile Controller）对接。
此处以Agile Controller服务器位于访问者所在的网络为例进行说明，如果Agile Controller服务器位于资源服务器所在的网络，则需要在FW上配置认证策略时，不对访问者与Agile Controller服务器之间的认证报文进行认证，同时在安全策略中保证这类报文可以正常通过FW。
RADIUS单点登录
企业已经部署了RADIUS（Remote Authentication Dial In User Service）服务器，并在RADIUS服务器上存储了用户/组和密码等信息。管理员可以根据现有的组织结构，在FW上手动创建或者使用文件批量导入相应的用户/组，以便后续管理员可以在FW上通过策略来控制不同用户/组对网络的访问行为。
认证时，NAS设备作为RADIUS服务器的代理客户端，将用户名和密码发送给RADIUS服务器进行认证。访问者通过RADIUS服务器的认证后，NAS设备开始跟RADIUS服务器交互计费报文。FW通过解析经过自身的计费报文获取用户与IP地址的对应关系。在这种场景下，访问者通过RADIUS服务器的认证后，就可以直接访问网络资源，无需再由FW进行认证，这种认证方式也称为“RADIUS单点登录”。
如图6所示，RADIUS服务器上存储了用户/组和密码等信息，FW上可以存储用户/组信息。内部网络中的访问者通过NAS设备接入网络，在访问网络资源之前，必须先通过RADIUS服务器的认证。FW解析经过自身的NAS设备与RADIUS服务器交互的计费报文，记录访问者使用的用户名和IP地址之间的对应关系。访问者访问网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。
此处RADIUS服务器位于资源服务器所在的网络，则需要在FW上配置认证策略时，不对访问者与RADIUS服务器之间、NAS与RADIUS服务器之间的认证报文进行认证，同时在安全策略中保证这类报文可以正常通过FW。
如果部署的网络中，NAS设备与RADIUS服务器交互的计费报文没有经过FW，为实现RADIUS单点登录的功能，必须采用一定的方法将计费报文镜像到FW上，例如通过交换机镜像。
NTLM认证
NTLM（NT LAN Manager）是Windows的安全协议，用于验证用户。当已经登录AD域的用户通过浏览器上网时，FW作为NTLM认证代理，触发并中转浏览器与AD服务器之间的NTLM认证，在认证过程中获取用户身份。此种场景不用再次要求用户输入用户名、密码，直接复用用户登录AD域时的身份。
如图7所示，用户登录AD域然后通过浏览器上网，FW收到流量后要求浏览器进行NTLM认证。然后FW作为NTLM代理将浏览器的认证请求发送至AD服务器，AD服务器NTLM认证通过后用户就同时在FW认证通过。
此种场景要求浏览器必须支持NTLM认证，用户登录AD域后用户的身份可以自动通过浏览器传递给AD服务器。
管理员可以将AD服务器上的组织结构和账号信息导入到FW，从而通过策略来控制不同用户/组的上网行为。
此种场景与AD单点登录类似，都是用户登录AD域后不需要FW的再次认证就能访问网络。NTLM认证的优点是部署简单，不用安装额外程序，但是局限于用户通过浏览器上网的场景，而且对浏览器有要求。
接入用户使用SSL VPN接入设备后访问网络资源
介绍接入用户使用SSL VPN接入FW并访问网络资源时，如何实施用户管理与认证机制。
FW作为企业的VPN接入网关，接入用户使用SSL VPN接入FW并访问网络资源时，整体过程可以分为接入（建立隧道）和访问资源两个阶段：
- 接入阶段在接入阶段，访问者登录SSL VPN认证页面，FW对访问者进行身份验证，建立SSL VPN隧道。
- 访问资源阶段接入后，访问者可以使用Web代理、文件共享、端口转发或网络扩展业务来访问网络资源。FW针对不同的业务资源的权限控制方式不同：
- Web代理、文件共享和端口转发业务：访问者通过FW中转来访问网络资源，用户权限由SSL VPN虚拟网关的“角色”模块来分配。本章不做具体介绍，具体参见SSL VPN部分。
- 网络扩展业务：FW会为访问者分配私网IP地址，访问者可以像在内网一样访问网络资源。如果需要控制用户访问权限，可以基于用户配置策略。
为了保证访问者正常接入，以及对访问者使用网络扩展业务访问资源时进行控制，需要在FW上完成如下任务：
- 存储用户/组信息，使用户/组可以被安全策略、策略路由、带宽策略、SSL加密流量检测策略、审计策略以及配额控制策略所引用。另外，配置SSL VPN功能时也要引用用户/组。
- 在接入阶段，对访问者进行认证，防止非授权的访问者接入。在访问资源阶段，对于使用网络扩展业务的访问者，获取其用户与IP地址的对应关系。
为了便于描述，下面以本地认证为例来进行说明，即FW上已经创建了相应的用户/组，并设置了用户的密码，由FW来完成验证密码的过程。下文的描述同样适用于服务器认证的情况，不同之处在于服务器认证是由认证服务器来完成验证密码的过程。
如图1所示，分支机构员工或出差员工接入时，必须先通过FW的认证。认证成功后，对于使用网络扩展业务的访问者，FW会为其分配私网IP地址，同时会记录访问者使用的用户和私网IP地址之间的对应关系。
在访问资源阶段，由于FW已经记录了访问者使用的用户和私网IP地址的对应关系，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为，在这一阶段无需对访问者进行二次认证。
图1 接入用户使用SSL VPN网络扩展功能访问网络资源时用户管理和认证方式示意图
接入用户使用L2TP VPN接入设备后访问网络资源
介绍接入用户使用L2TP VPN接入FW并访问网络资源时，如何实施用户管理与认证机制。
本节的描述也适用于接入用户使用L2TP over IPSec VPN接入FW并访问网络资源的场景。
FW作为企业的VPN接入网关，接入用户使用L2TP VPN接入FW并访问网络资源时，整体过程可以分为接入（建立隧道）和访问资源两个阶段：
- 接入阶段在接入阶段，FW对访问者进行身份验证，建立L2TP VPN隧道。
- 访问资源阶段接入后，访问者可以访问企业总部的网络资源。FW可以基于用户控制访问者可以访问的网络资源。
为了保证访问者正常接入，以及访问资源时对其进行控制，需要在FW上完成如下任务：
- 存储用户/组信息，使用户/组可以被安全策略、策略路由、带宽策略、SSL加密流量检测策略、及审计策略以及配额控制策略所引用。另外，配置L2TP VPN功能时也要引用用户/组。
- 在接入阶段，对访问者进行认证，防止非授权的访问者接入。在访问资源阶段，是否对访问者进行二次认证，与实际网络环境中对安全管理和权限控制的需求有关，需要综合考虑各方面的因素。
下面根据建立L2TP隧道的不同方式来分情况介绍。
为了便于描述，下面以本地认证为例来进行说明，即FW上已经创建了相应的用户/组，并设置了用户的密码，由FW来完成验证密码的过程。下文的描述同样适用于服务器认证的情况，不同之处在于服务器认证是由认证服务器来完成验证密码的过程。
LAC自主拨号方式
如图1所示，分支机构通过LAC自主拨号方式与总部建立L2TP VPN隧道。在接入阶段，FW（LNS）对LAC进行认证。隧道一旦建立，分支机构中的访问者可以直接访问总部的网络资源。
由于在接入阶段LAC使用的用户仅用于标识LAC的身份，FW无法使用该用户来标识分支机构中的访问者，因此在访问资源阶段，如果需要基于用户控制访问权限，FW必须对分支机构中的访问者再次进行认证。认证成功后，FW记录访问者使用的用户和IP地址之间的对应关系。分支机构中的访问者访问总部网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。
图1 LAC自主拨号方式的L2TP VPN场景中接入用户访问网络资源时用户管理和认证方式示意图
NAS-Initiated/Client-Initiated方式
如图2所示，分支机构通过NAS-Initiated方式与总部建立L2TP隧道，出差员工通过Client-Initiated方式与总部建立L2TP隧道。在接入阶段，这两种方式都是使用用户名和密码通过拨号方式来触发L2TP隧道的建立。L2TP隧道建立过程中，FW（LNS）会为访问者分配私网IP地址，同时会记录访问者使用的用户和私网IP地址之间的对应关系。
在访问资源阶段，FW可以直接根据接入阶段记录的用户来控制访问者的权限和行为，不需要对访问者进行二次认证。
图2 NAS-Initiated/Client-Initiated方式的L2TP VPN场景中接入用户访问网络资源时用户管理和认证方式示意图
如果需要进一步对访问者实施安全管理和权限控制，也可以在访问资源阶段对访问者进行二次认证，FW根据访问者在二次认证中使用的用户来控制访问者的权限和行为。
接入用户使用IPSec VPN接入设备后访问网络资源
介绍接入用户使用IPSec VPN接入FW并访问网络资源时，如何实施用户管理与认证机制。
本节的描述也适用于接入用户使用GRE VPN接入FW并访问网络资源的场景。
FW作为企业的VPN接入网关，接入用户使用IPSec VPN接入FW并访问网络资源时，整体过程可以分为接入（建立隧道）和访问资源两个阶段：
- 接入阶段在接入阶段，FW协商建立IPSec VPN隧道。如果是移动用户通过EAP认证方式接入IPSec VPN隧道涉及用户认证，其他方式建立IPSec VPN隧道不涉及用户认证。
- 访问资源阶段接入后，访问者可以访问企业总部的网络资源。FW可以基于用户控制访问者可以访问的网络资源。
为了实现基于用户的访问行为控制，需要在FW上完成如下任务：
- 存储用户/组信息，使用户/组可以被安全策略、策略路由、带宽策略、SSL加密流量检测策略、审计策略以及配额控制策略所引用。
- 在接入阶段对访问者进行认证（移动用户接入）或在访问资源阶段对访问者进行认证（网关接入），获取用户与IP地址的对应关系。
下面根据建立IPSec隧道的不同方式来分情况介绍。
网关之间建立IPSec VPN隧道
如图1所示，分支机构与总部建立IPSec VPN隧道，此阶段不涉及用户认证。隧道成功建立后，如果需要基于用户控制访问权限，分支机构中的访问者在访问企业总部的网络资源之前必须先通过FW的认证。认证成功后，FW记录访问者使用的用户和IP地址之间的对应关系。分支机构中的访问者访问总部网络资源时，FW上基于此用户或用户所属组的策略决定了访问者的权限和行为。
图1 接入用户通过网关之间的IPSec VPN隧道访问网络资源时用户管理和认证方式示意图
为了便于描述，下面以本地认证为例来进行说明，即FW上已经创建了相应的用户/组，并设置了用户的密码，由FW来完成验证密码的过程。下文的描述同样适用于服务器认证的情况，不同之处在于服务器认证是由认证服务器来完成验证密码的过程。
移动用户与网关直接建立IPSec VPN隧道
如图2所示，在无线解决方案中AP（Access Point）通过EAP认证方式与FW建立IKEv2的IPSec VPN隧道。在隧道建立过程中FW通过RADIUS服务器对AP进行认证，认证成功后FW会为AP分配私网IP地址，同时会记录AP使用的身份标识和私网IP地址之间的对应关系。
图2 移动用户通过EAP认证方式接入IPSec VPN隧道访问网络资源时用户管理和认证方式示意图
移动用户通过Windows 7客户端与网关之间也可以建立IPSec VPN隧道，此时客户端通过证书标明身份，无需在FW上部署用户名密码的身份认证机制，本章不详细介绍
用户组织结构
用户是网络访问的主体，是FW进行网络行为控制和网络权限分配的基本单元。
FW中的用户组织结构是实际企业中组织结构的映射，是基于用户进行权限管控的基础。如图1所示，用户组织结构分为按部门进行组织的树形维度、按跨部门群组进行组织的横向维度。
用户组织结构中涉及如下概念：
- 认证域：用户组织结构的容器，类似于Microsoft Active Directory (AD)服务器中的域。FW缺省存在default认证域，用户可以根据需求新建认证域。
- 用户组/用户：用户按树形结构组织，用户隶属于组（部门）。管理员可以根据企业的组织结构来创建部门和用户。这种方式易于管理员查询、定位，是常用的用户组织方式。
- 安全组：横向组织结构的跨部门群组。当需要基于部门以外的维度对用户进行管理可以创建跨部门的安全组，例如企业中跨部门成立的群组。另外当企业通过第三方认证服务器存储组织结构时，服务器上也存在类似的横向群组，为了基于这些群组配置策略，FW上需要创建安全组与服务器上的组织结构保持一致。
下面分别具体介绍两种组织结构的规则。
树形组织结构
树形组织结构的顶级节点是“认证域”，也可以看作是根组，认证域下级可以是用户组、用户。default认证域是设备缺省存在的认证域，相当于default根组。
通常情况下，在缺省的default认证域下规划组织结构即可，如果有不同用户使用不同认证方式、与服务器上域名对应等需求时才需要规划新的认证域。
如果有规划新的认证域需求，FW提供如下两种方式规划用户组织结构：
- 每个认证域拥有独立的用户帐号每个认证域是一个独立的树形组织结构，类似于AD/LDAP等认证服务器上的域结构。各认证域的用户账号独立，不同认证域的账号允许重名。
- 所有认证域共享default认证域的用户帐号只有default认证域一个树形组织结构，其他认证域与default认证域共享账号。此时新建认证域的作用在于决定哪些用户使用哪种认证方式，不作为用户组织结构的顶级节点。
建议按第一种方式规划用户组织结构，与服务器组织结构对应。第二种方式主要用于，同一个用户账号有使用不同认证方式或版本升级兼容的特殊情况。选择哪种部署方式由认证域下的配置决定。
规划树形组织结构时必须遵循如下规定：
- default认证域是设备默认自带的认证域，不能被删除，且名称不能被修改。
- 设备最多支持20层用户结构，包括认证域和用户，即认证域和用户之间最多允许存在18层用户组。
- 每个用户组可以包括多个用户和用户组，但每个用户组只能属于一个父用户组。
- 一个用户只能属于一个父用户组。
- 用户组名允许重名，但所在组织结构的全路径必须确保唯一性。
- 用户和用户组都可以被策略所引用，如果用户组被策略引用，则用户组下的用户继承其父组和所有上级节点的策略。
基于安全组的横向组织结构
用户/组（部门）是“纵向”的组织结构，体现了用户的所属关系；而安全组是“横向”的组织结构，可以把不同部门的用户划分到同一个安全组，从新的管理维度来对用户进行管理。管理员基于安全组配置策略后，安全组中的所有成员用户都会继承该策略，这就使得对用户的管理更加灵活和便捷。
安全组还可以用于FW与第三方认证服务器配合工作的场景。当网络中存在AD、Sun ONE LDAP服务器时，AD、Sun ONE LDAP服务器上除了组织单元（OU）之外，还存在其它类型的组织结构。例如，AD服务器上还存在安全组，Sun ONE LDAP服务器上还存在静态组和动态组。如果期望FW能基于AD服务器上的安全组或Sun ONE LDAP服务器上静态组/动态组来对用户进行管理，可以通过FW上的安全组来实现。
AD服务器上的安全组以及Sun ONE LDAP服务器上静态组/动态组通常用于控制和管理组下用户对网络共享位置、文件、目录和打印机等资源和对象的访问。FW上的用户组对应的是AD、Sun ONE LDAP服务器上的组织单元，而FW上的安全组则对应的是AD服务器上的安全组以及Sun ONE LDAP服务器上的静态组和动态组。关于安全组或静态组/动态组的详细介绍请参见AD服务器或Sun ONE LDAP服务器自带的文档。
FW上的安全组分为以下两种类型：
- 静态安全组静态安全组是指其成员用户（组）是固定不变的。静态安全组的来源包括：由管理员手动创建的静态安全组、从AD服务器上导入的安全组、以及从Sun ONE LDAP服务器上导入的静态组。
- 动态安全组动态安全组是指其成员用户不固定，而是将服务器上满足一定过滤条件的用户作为动态安全组的成员。动态安全组的来源包括：由管理员手动创建的AD类型的动态组、由管理员手动创建的Sun ONE LDAP类型的动态组、以及从Sun ONE LDAP服务器上导入的动态组。在portal认证场景中，用户认证时FW根据本地的动态安全组过滤条件到认证服务器查找，如果服务器上有符合条件的用户，则用户作为临时用户在此动态安全组上线。
规划安全组时必须遵循如下规定：
- 一个用户可以不属于任何父安全组，也可以最多属于40个父安全组。
- 一个安全组可以不属于任何父安全组，也可以最多属于40个父安全组。
- 用户的父安全组可以是任意认证域的安全组，但是安全组和其父安全组只能属于同一个认证域。
- 安全组最多支持三层嵌套，即父安全组、安全组、子安全组。
- 安全组支持环形嵌套，即安全组A属于安全组B，安全组B属于安全组C，安全组C属于安全组A的情况，安全组的组织结构为网状结构。
- 动态安全组不能作为任何安全组的父组，但可以作为静态安全组的成员。
- 安全组可以被策略所引用，如果安全组被策略引用，则安全组下的直属用户继承其父安全组的策略，安全组下的子安全组用户不继承上级安全组的策略。
用户/用户组/安全组的来源
在FW上创建用户、用户组和安全组时，可以使用以下方式：
对用户进行权限控制需要在策略中引用用户、用户组或安全组，因此即使采用服务器认证方式的用户也需要在FW存在对应的用户组、安全组或用户，至少要存在用户组或安全组。
- 手动创建管理员手动创建用户、用户组、安全组，并配置用户属性。例如，管理员可根据企业的纵向组织架构创建用户组，根据企业的横向组织架构创建安全组，然后在各组下创建用户信息。如果没有部署第三方认证服务器或者部署的第三方认证服务器不支持向FW导入用户信息的功能，请使用该方式来创建用户。
- 从CSV文件导入将用户信息、安全组信息按照指定格式写入不同的CSV文件中，再将CSV文件导入到FW中，或者将之前从FW上导出的CSV文件再次导入，批量创建用户、用户组和安全组。如果没有部署第三方认证服务器或者部署的第三方认证服务器不支持向FW导入用户信息的功能，请使用该方式来创建用户。与手动创建方式相比，可以简化配置。
- 从服务器导入如果实际环境中已经部署了身份验证机制，并且用户信息都存放在第三方认证服务器上，则可以通过执行服务器导入策略，将第三方认证服务器上用户/用户组/安全组的信息导入到FW上。目前FW只支持从AD、LDAP和Agile Controller服务器导入用户和组，支持从AD、Sun One LDAP服务器导入安全组。对于其他服务器，请使用手动创建、CSV文件导入或设备自动发现并创建的方式。
用户属性
用户的主要属性及其说明如表1所示。
| 属性 | 说明 |
|---|---|
| 登录名 | 用户的账号，即用户进行认证时使用的名称。 |
| 显示名 | 用户在FW上显示的名称，仅作为区分用户的标识。通常情况下，在日志、报表的用户字段中，用户会以“登录名（显示名）”的格式出现。 |
| 描述 | 用户的描述信息，便于管理员对该用户进行识别和维护。 |
| 所属用户组 | 用户所在的父用户组，一个用户只能属于一个父用户组。 |
| 所属安全组 | 用户所在的父安全组，一个用户可以不属于任何父安全组，也可以最多属于40个父安全组。 |
| 密码 | 用户的密码。使用本地认证时，必须在FW上配置用户的密码；使用服务器认证时，用户的密码在第三方认证服务器上配置，无需在FW上配置。 |
| 账号过期时间 | 账号的有效期，过期之后该账号无法使用。 |
| 允许多人同时使用该账号登录 | 是否允许多人同时使用该用户的登录名登录，即允许该登录名同时在多台计算机上登录。 |
| IP/MAC绑定 | 将用户与IP/MAC绑定，限制该用户只能在特定的IP/MAC地址上登录。 |
在线用户
用户访问网络资源前，首先需要经过FW的认证，目的是识别这个用户当前在使用哪个IP地址。对于通过认证的用户，FW还会检查用户的属性（用户状态、账号过期时间、IP/MAC地址绑定、是否允许多人同时使用该账号登录），只有认证和用户属性检查都通过的用户，该用户才能上线，称为在线用户。
FW上的在线用户表记录了用户和该用户当前所使用的地址的对应关系，对用户实施策略，也就是对该用户对应的IP地址实施策略。
用户上线后，如果在线用户表项超时时间内（缺省30分钟）没有发起业务流量，则该用户对应的在线用户监控表项将被删除。当该用户下次再发起业务访问时，需要重新进行认证。
在线用户信息同步
当在不同的网络位置部署了多台FW时，希望用户在一台FW的上线信息能同步到其他FW，从而实现对用户权限的全方位管控。此时可以通过在线用户信息同步功能，使用户在多台FW同时上线。
在此种部署方式下，工作过程分为同步操作和查询操作两种，如图2所示（以FW_B为例讲解）。
- 同步操作当内置Portal认证、AD/Agile Controller/RADIUS单点登录的用户在FW_B上线或下线时，FW_B将此信息发送给通知列表中的设备，使用户同时在FW_A和FW_C上线、下线。另外当用户发起流量刷新在线用户的剩余时间时，FW_B也会每隔5分钟同步刷新到其他设备，防止其他设备表项超时。
- 查询操作当经过FW_B的流量没有对应的在线用户表项时，FW_B可以向查询服务器FW_A发起一次查询，如果FW_A存在对应的表项将下发给FW_B。一般选择用户流量频繁的设备，例如出口防火墙作为查询服务器，因为这类设备表项不容易超时。
总体流程
了解整体的认证流程，有助于后续配置。
FW上的认证过程由多个环节组成，各个环节的处理存在先后顺序。根据不同的部署方式和网络环境，FW提供了多种用户认证方案供管理员选择，如图1和表1所示。
| 分类 | 说明 | 认证方式 |
|---|---|---|
| 上网用户单点登录 | 用户只要通过了其他认证系统的认证就相当于通过了FW的认证。用户认证通过后FW可以获知用户和IP的对应关系，从而基于用户进行策略管理。此种方式适用于部署防火墙用户认证功能之前已经部署认证系统的场景。 | AD单点登录：用户登录AD域，由AD服务器进行认证。Agile Controller单点登录：用户由华为公司的Agile Controller系统（Policy Center或Agile Controller）进行认证。RADIUS单点登录：用户接入NAS设备，NAS设备转发认证请求到RADIUS服务器进行认证。 |
| 上网用户内置Portal认证 | FW提供内置Portal认证页面（缺省为https://接口IP地址:8887）对用户进行认证。FW可转发认证请求至本地用户数据库、认证服务器。此种方式适用于通过FW对用户进行认证的场景。 | 会话认证：当用户访问HTTP业务时，FW向用户推送认证页面，触发身份认证。事前认证：当用户访问非HTTP业务时，只能主动访问认证页面进行身份认证。 |
| 上网用户自定义Portal认证 | FW与自定义Portal联动对用户进行认证。例如：Agile Controller可以作为外部Portal服务器对用户进行认证。目前存在两种类型的自定义Portal认证，具体请参见自定义Portal认证。 | 用户访问HTTP业务时，FW向用户推送自定义Portal认证页面，触发身份认证。 |
| 上网用户免认证 | 用户不输入用户名和密码就可以完成认证并访问网络资源。免认证与不需要认证有差别，免认证是指用户无需输入用户名、密码，但是FW可以获取用户和IP对应关系，从而基于用户进行策略管理。 | 将用户名与IP或MAC地址双向绑定，FW通过识别IP/MAC地址与用户的绑定关系，使用户自动通过认证。此种方式一般适用于高级管理者。 |
| 接入用户认证 | VPN接入用户接入过程中FW对用户进行认证。如果期望接入认证成功后、访问资源前再次进行认证，可以配置二次认证。 | 本地认证、服务器认证。 |
上网用户Portal认证
Portal认证是指由FW或第三方服务器提供Portal认证页面对用户进行认证。
FW内置Portal认证
内置Portal认证的触发方式包括：
- 会话认证如果实际网络环境中访问者只使用单一的HTTP/HTTPS业务访问网络资源，建议使用会话认证方式来触发FW上的认证。会话认证是指访问者不主动进行身份认证，先进行HTTP/HTTPS业务访问，在访问过程中进行认证。认证通过后，再进行业务访问。FW缺省支持向目的端口为80的HTTP业务访问推送认证页面，可以通过配置实现向目的端口为443的HTTPS业务访问推送认证页面。其余业务报文包括通过端口映射（port-mapping）功能识别出的HTTP/HTTPS报文，均会被FW丢弃。用户使用URL地址来进行HTTP业务访问时，首先需要与DNS服务器交互DNS业务报文来解析URL地址。如果用户与DNS服务器交互的DNS业务报文经过FW转发，则需要管理员在FW上配置安全策略，允许DNS业务报文通过。如图1所示，当FW收到访问者的第一条目的端口为80的HTTP业务访问数据流时，将HTTP请求重定向到认证页面，触发访问者身份认证。认证通过后，就可以访问HTTP业务以及其他业务。FW的认证方式包括本地认证、转发认证请求至认证服务器进行代理认证。本地认证和服务器认证使用的是用户名、密码认证的Portal页面。图1 会话认证示意图
- 事前认证如果实际网络环境中访问者需要通过多种业务形式访问网络资源，可以使用事前认证方式来触发FW上的认证。事前认证是指访问者在访问网络资源之前，先主动进行身份认证，认证通过后，再访问网络资源。如图2所示，访问者主动向FW提供的认证页面发起认证请求。FW收到认证请求后，对其进行身份认证。认证通过后，就可以访问Internet。FW的认证方式包括本地认证、转发认证请求至认证服务器进行代理认证。本地认证和服务器认证使用的是用户名、密码认证的Portal页面。图2 事前认证示意图
自定义Portal认证
FW还支持自定义Portal认证，目前存在两种类型的自定义Portal认证。
采用这两种类型的自定义Portal认证时，企业需要单独部署外部Portal服务器，例如，都可以部署Agile Controller作为Portal服务器。
- 方式一：FW不参与用户认证（Agile Controller单点登录方式）此类型的Portal认证中，由Portal服务器独立完成用户认证。具体原理请参见Agile Controller单点登录的“方式二：访问者访问HTTP业务触发Agile Controller单点登录”。用户访问HTTP业务时被重定向至Agile Controller的Portal认证页面，由Agile Controller认证用户然后告知FW用户和IP的对应关系。
- 方式二：FW参与用户认证此类型的Portal认证中，由Portal服务器和FW共同完成用户认证。FW收到访问者的HTTP业务数据流时，将HTTP请求重定向到Agile Controller的Portal认证页面。Portal服务器接收到用户认证请求后，将认证请求转发给FW，由FW向RADIUS服务器请求用户认证。认证通过后用户在FW中上线。具体如图3所示。Portal服务器和RADIUS服务器是Agile Controller的两个组件，两个组件可以安装在一台服务器中，也可分开安装。目前只支持使用RADIUS服务器作为认证服务器。此场景下Portal服务器与FW之间采用Portal2.0协议进行交互，Portal2.0协议是华为公司宽带产品所采用的Portal协议标准(V2.01)。Agile Controller可以向FW下发用户的安全组，FW可以基于安全组对用户进行策略控制。图3 自定义Portal认证（FW参与用户认证过程）示意图
访问者注销时，用户先在Portal服务器上下线，再由Portal服务器通知FW用户下线。
自定义Portal认证生效依赖于在认证策略中引用自定义Portal认证模板，自定义Portal认证模板中指定了自定义Portal地址参数。
用户在FW中首次上线后，如果用户终端的IP地址频繁变更，当FW收到访问者的请求时仍可能提示用户再次认证，此时可采用方式二：FW参与用户认证与MAC优先认证结合的认证方案。
在此种结合的认证方案中，用户经过方式二：FW参与用户认证方式认证后，如果用户终端的IP地址发生变更，FW将在一段时间内（Agile Controller中配置的MAC地址有效时间内）对用户进行MAC认证。在MAC认证过程中无需用户输入认证信息（用户无感知），方便用户访问业务。
FW处理用户请求的具体过程如图4所示。FW收到访问者的HTTP业务数据流时，若用户不在线或用户IP地址与MAC对应关系变更，则向Agile Controller发送MAC认证请求。
如果MAC认证成功，用户可直接访问业务。
如果Agile Controller在一定时间内无响应或MAC认证失败，FW将向用户推送Portal认证页面，用户进入如图3所示的认证过程，认证成功后用户上线，可正常访问业务。
图4 自定义Portal认证（FW参与用户认证过程）+MAC优先认证
免认证
对于企业的高级管理者，他们希望可以简化操作过程，不输入用户名和密码就可以完成认证并访问网络资源，同时对安全要求又更加严格。此种情况下，这类访问者可以使用免认证的方式来触发FW上的认证。
将本地用户名与IP、MAC或IP-MAC进行双向绑定，FW通过识别IP/MAC和用户的双向绑定关系，确定访问者的身份。进行免认证的访问者只能使用特定的IP/MAC地址来访问网络资源。
NTLM认证
当已经登录AD域的用户通过浏览器上网时，FW作为NTLM认证代理，触发并中转浏览器与AD服务器之间的NTLM认证，在认证过程中获取用户身份。NTLM认证是一种用户对输入用户名、密码无感知的Portal认证，具体原理如图5所示。
- 访问者登录AD域。
- 访问者通过浏览器访问HTTP/HTTPS业务。
- FW发现流量未经过认证，而且流量匹配的认证策略是NTLM认证。FW对访问者进行重定向认证。
- 访问者访问防火墙重定向的Portal页面。此过程由浏览器和FW进行内部交互，并不弹出有要求输入用户名、密码的Portal认证页面。
- FW拒绝浏览器访问，要求浏览器进行NTLM认证。
- 浏览器发送NTLM协商请求。
- FW将协商请求转发至AD服务器。
- AD服务器产生一个随机数作为挑战字发给浏览器。
- FW将挑战字转发至浏览器。
- 浏览器再次发送NTLM协商数据，包括用户名、域名、response数据等。其中response是通过密码的HASH值加密挑战字的方式计算出来的。这样做的好处是不在网络上直接传输密码，确保密码的安全性。要求浏览器必须支持NTLM认证，否则浏览器无法自动提供用户登录信息。
- FW提取用户名。
- FW转发NTLM协商数据至AD服务器。
- AD服务器回复认证结果。AD服务器在本地查找用户名对应的密码HASH值，用这个HASH值加密之前产生的挑战字，然后将计算结果与浏览器发来的responce进行比较，如果相等则用户认证通过。
- 如果认证成功，FW使对应的用户在FW上线。
- FW转发认证结果至浏览器。
- 如果认证成功，访问者成功访问HTTP业务。
用户在FW上线后，FW根据在线用户超时时间使用户下线。
上网用户单点登录
单点登录是指FW不是认证点，FW通过获取其他认证系统的用户登录消息，使用户在FW上线。
AD单点登录
在AD环境中，访问者通常希望经过AD服务器的认证后，就会自动通过FW的认证，然后可以访问所有的网络资源。此种情况下，访问者可以使用AD单点登录的方式来触发FW上的认证。
AD单点登录时，FW支持通过多种方式获取用户认证通过的消息，如表1所示，请根据具体需求选择。
| 对比项 | 安装单点登录服务程序接收PC的消息 | 安装单点登录服务程序查询AD服务器安全日志 | FW监控AD认证报文 |
|---|---|---|---|
| 安装部署 | 部署复杂，需要单独安装单点登录服务程序，并在AD服务器上部署登录注销脚本下发给PC。 | 需要单独安装单点登录服务程序。无需部署脚本。 | 免安装额外程序。要求FW必须能获取到用户与AD服务器之间的认证交互报文。 |
| 客户端（登录PC）兼容性 | 仅支持Windows系统，其他系统不支持执行登录注销脚本。 | 操作系统不限。 | 操作系统不限。 |
| 获取上线消息 | 开机、注销、重启后的登录消息。 | 开机、注销、重启、锁屏后的登录消息。 | 开机、注销、重启后的登录消息。 |
| 获取下线消息 | 关机、注销、重启的下线消息。 | 不支持。 | 不支持。 |
| 多台AD服务器 | 一个域部署多台AD服务器，不同AD服务器之间建立了同步关系时，可部署一个单点登录服务程序和一套登录注销脚本。部署多个域组成一个域林，不同域之间建立了信任关系时，可部署一个单点登录服务程序，但需要为每个域部署一套登录注销脚本。 | 最多支持获取16台AD服务器的消息。当网络中部署多台AD服务器组成域林时，可以同时获取多台AD服务器消息。 | 最多支持获取32台AD服务器的消息。当网络中部署多台AD服务器组成域林时，可以同时获取多台AD服务器消息。 |
| 安全性 | 单点登录服务器程序与FW之间的消息通过共享密钥加密。 | 单点登录服务器程序与FW之间的消息通过共享密钥加密。 | FW直接解析认证报文，存在认证报文被恶意篡改、用户身份被伪造的风险。 |
AD单点登录服务程序只有一个，支持两种模式设置：接收PC消息模式、查询AD服务器安全日志模式。
方式一：安装单点登录服务程序接收PC的消息
管理员需要在AD监控器（可以是AD域控制器也可以是AD域中其他机器）上部署AD单点登录服务，在AD服务器（AD域控制器）上设置登录脚本和注销脚本，同时在FW上配置AD单点登录参数，接收AD单点登录服务发送的用户登录/注销消息。
如图1所示，以登录过程为例进行说明。
- 访问者登录AD域，AD服务器向用户返回登录成功消息并下发登录脚本。
- 访问者PC执行登录脚本，将用户登录信息发送给AD监控器。
- AD监控器连接到AD服务器查询登录用户信息，如果能查询到该用户的信息则转发用户登录信息到FW。
- FW从登录信息中提取用户和IP的对应关系添加到在线用户表。
图1 AD单点登录示意图（安装单点登录服务程序接收PC的消息）
访问者注销流程与登录流程类似，不再赘述。
如果访问者与AD服务器、访问者与AD监控器、AD监控器与AD服务器之间的交互报文经过了FW，则需要确保FW上的认证策略不对这些报文进行认证，同时在安全策略中保证这类报文可以正常通过FW。
方式二：安装单点登录服务程序查询AD服务器安全日志
管理员需要在AD监控器（可以是AD域控制器也可以是AD域中其他机器）上部署AD单点登录服务，同时在FW上配置AD单点登录参数，接收AD单点登录服务发送的用户登录消息。
用户在FW的上线过程如图2所示。
- 访问者登录AD域，AD服务器记录用户上线信息到安全日志中。
- AD监控器通过AD服务器提供的WMI（Windows Management Instrumentation）接口，连接到AD服务器查询安全日志，获取用户登录消息。AD监控器从AD单点登录服务开始启动的时间点为起点，定时查询AD服务器上产生的安全日志。FW调用的具体WMI接口为Win32_NTlogEvent接口，通过EventCode参数获取如下ID的安全日志，然后解析用户名、IP地址和域名信息（ADPath）：Windows 2003 Server：
- 672：成功发出并验证身份验证服务（AS）票证
- 673：授予票证授权服务（TGS）票证
- 674：安全主体续订 AS 票证或 TGS 票证。
- 4768：请求Kerberos身份验证票证（TGT）
- 4769：请求Kerberos服务票证
- 4770：更新Kerberos服务票证
- 4624：用户登录成功
FW获取用户上线信息的先决条件是AD服务器能够产生上述ID的日志（在Windows事件查看器中可以查看），并且FW可以正常调用Win32_NTlogEvent接口，请确保AD服务器满足上述条件。Windows接口的详细介绍请参见Windows帮助文档。 - AD监控器转发用户登录消息到FW，用户在FW上线。
图2 AD单点登录示意图（安装单点登录服务程序查询AD服务器安全日志）
该方式下，FW无法获取用户的注销消息，因此只能根据在线用户超时时间使用户下线。
方式三：FW监控AD认证报文
- 该方式下的认证报文特指AS-REP报文。在AD认证过程中，用户需要与Kerberos服务器（集成在AD服务器中）进行报文交互，FW只有获取到Kerberos服务器向用户返回的AS-REP报文，才能使用户在FW上线。
- 该方式下，FW无法获取用户的注销消息，因此只能根据在线用户超时时间使用户下线。
- 该方式存在认证报文被恶意篡改、用户身份被伪造的风险，请谨慎使用。
- FW需要使用独立的二层接口接收镜像认证报文，该接口不能与其他业务口共用。不支持配置管理口（GigabitEthernet 0/0/0）接收镜像报文。
该方式下，无需在AD服务器上安装程序。FW通过监控访问者登录AD服务器（AD域控制器）的认证报文获取认证结果，如果认证成功将用户和IP对应关系添加到在线用户表。
当FW部署在访问者和AD服务器之间时，FW可以直接获取认证报文；如果认证报文未经过FW（如图3所示），则需要将AD服务器发给访问者的认证结果报文镜像到FW。
Agile Controller单点登录
在Agile Controller环境中，访问者通常希望经过Agile Controller服务器的认证后，就会自动通过FW的认证，然后可以访问所有的网络资源。此种情况下，访问者可以使用Agile Controller单点登录的方式来触发FW上的认证。
为了实现Agile Controller单点登录，管理员需要在Agile Controller服务器上配置与FW的通信参数，确保Agile Controller服务器可以将用户的登录信息发送至FW。同时在FW上配置Agile Controller服务器以及Agile Controller单点登录参数，接收Agile Controller服务器发送的用户登录/注销消息。
如果FW部署在访问者和Agile Controller服务器之间，则需要在FW上配置认证策略时，不对访问者与Agile Controller服务器之间的认证报文进行认证，同时在安全策略中保证这类报文可以正常通过FW。
FW支持与多个Agile Controller服务器通信，此处以一台Agile Controller服务器为例进行描述。
Agile Controller单点登录提供以下两种触发方式：
方式一：访问者主动触发Agile Controller单点登录
如图4所示，以登录过程为例进行说明。访问者访问业务之前首先通过Agile Controller客户端或Portal认证页面登录到Agile Controller中，然后由Agile Controller服务器将登录信息（包括访问者使用的用户名和IP地址）发送给FW。
图4 访问者主动触发Agile Controller单点登录示意图
访问者注销时，Agile Controller服务器将注销信息发送给FW，完成注销过程。
方式二：访问者访问HTTP业务触发Agile Controller单点登录
如图5所示，FW收到访问者的第一条目的端口为80的HTTP业务访问数据流时，将HTTP请求重定向到Agile Controller的Portal认证页面，触发Agile Controller对访问者进行身份认证。认证通过后，Agile Controller服务器将登录信息（包括访问者使用的用户名和IP地址）发送给FW，然后访问者就可以访问HTTP业务以及其他业务。
图5 HTTP业务触发Agile Controller单点登录示意图
访问者注销时，Agile Controller服务器将注销信息发送给FW，完成注销过程。
FW与Agile Controller服务器的在线用户同步
在Agile Controller单点登录中，FW的在线用户与Agile Controller服务器的在线用户保持同步，是保证用户权限控制正常的关键因素。但是实际使用中如下几种情况将导致两端在线用户不同步：
- 用户在Agile Controller服务器认证通过后，Agile Controller服务器发给FW的用户上线消息丢失，用户无法在FW上线，导致用户无法访问网络。
- FW具有在线用户老化机制，即如果在线用户在一定时间内没有流量经过FW，则FW会将其主动下线。此时可能出现用户在Agile Controller服务器没下线，而在FW提前下线的问题，导致用户无法访问网络。
- 用户已经从Agile Controller服务器下线，Agile Controller服务器发给FW的用户下线消息丢失，FW仍存在此在线用户，可能存在用户被仿冒的风险。
针对以上问题，当用户在FW上线、老化时，FW向Agile Controller服务器主动查询在线用户，以保持两端同步：
- 当经过FW的流量没有对应的在线用户表项时，FW主动向Agile Controller服务器查询源IP对应的在线用户。如果Agile Controller服务器上存在该IP对应的在线用户，则Agile Controller服务器将此用户上线信息发送给FW。此机制解决了上述第一个问题。为避免不需要Agile Controller单点登录的流量也到Agile Controller服务器查询，FW支持指定查询流量的源IP范围，符合范围的流量才会触发FW向Agile Controller服务器发起查询。
- 当FW上的在线用户即将老化时（剩余在线时间为老化时间的四分之一），FW向Agile Controller服务器发起查询，如果该用户在Agile Controller服务器上在线，则刷新用户在FW的剩余在线时间为最大值；如果用户在Agile Controller服务器上不在线，FW上的该用户被正常老化。此机制解决了第二个问题，FW的在线用户不会先于Agile Controller服务器上的在线用户下线。另外第三个问题，FW的在线用户老化机制就是解决这个问题的，在线用户一定时间内没有流量，FW会将其主动下线。
Agile Controller单点登录支持IPv4和IPv6地址。Agile Controller服务器对用户进行认证后可获取用户的IPv4和IPv6地址，并将获取的IP地址发送给FW，使用户在FW中上线。一个用户经过一次认证后最多可对应11个IP地址上线（最多1个IPv4地址和最多10个IPv6地址）。
当FW获取到一个用户的多个IP地址时，请保证已配置允许用户同时在多台计算机（IP地址）上登录，否则一个用户不能对应多个IP地址上线。
IPv6地址的在线用户信息不能在不同FW之间同步，但可以在FW与Agile Controller服务器之间同步。
RADIUS单点登录
在RADIUS环境中，访问者通常希望经过RADIUS服务器的认证后，就会自动通过FW的认证，然后可以访问所有的网络资源。此种情况下，访问者可以使用RADIUS单点登录的方式来触发FW上的认证。
为了实现RADIUS单点登录，FW需要解析NAS（Network Access Server）设备和RADIUS服务器之间的RADIUS计费报文，获取用户和IP地址的对应关系。根据FW部署位置的不同，FW获取RADIUS计费报文的途径也不同，具体如图6、图7和图8所示。
如果访问者与NAS设备、NAS设备与RADIUS服务器之间交互的报文经过了FW，需要在FW上配置认证策略，不对这些报文进行认证，同时在安全策略中保证这类报文可以正常通过FW。
以登录过程为例，RADIUS单点登录交互过程如下:
- 访问者向接入设备NAS发起认证请求。
- NAS设备转发认证请求到RADIUS服务器，RADIUS服务器对用户账号和密码进行校验，并将认证通过的结果返回给NAS设备。NAS设备向RADIUS服务器发送计费开始报文，标识用户上线。
- FW解析计费开始报文获取用户和IP地址的对应关系，同时在本地生成在线用户信息。不同部署方式，FW获取计费开始报文的方式不同：
- 直路：FW直接对经过自身的RADIUS计费开始报文进行解析。
- 旁路：NAS设备向RADIUS服务器发送计费开始报文的同时还会向FW发送一份，FW对计费开始报文进行解析并对NAS设备做出应答。此种部署方式需要NAS设备支持向FW发送计费开始报文的功能。
- 镜像引流：NAS设备和RADIUS服务器之间交互的计费开始报文不经过FW，需要通过交换机镜像或分光器分光的方式复制一份计费开始报文到FW。FW对计费开始报文进行解析后丢弃。
访问者注销时，NAS设备向RADIUS服务器发送计费结束报文，标识用户下线。FW获取计费结束报文并解析用户和IP对应关系，然后删除本地保存的在线用户信息，完成注销过程。
另外在用户在线期间，NAS设备还会定时向RADIUS服务器发送计费更新报文维持计费过程，FW获取计费更新报文后将刷新在线用户的剩余时间。
RADIUS单点登录支持IPv4和IPv6地址。FW可以解析RADIUS计费报文获取用户的IPv4地址和IPv6地址，并生成在线用户信息。一个用户经过一次认证后最多可对应11个IP地址上线（最多1个IPv4地址和最多10个IPv6地址）。
当FW从RADIUS计费报文中解析出多个IP地址时，请保证已配置允许用户同时在多台计算机（IP地址）上登录，否则一个用户不能对应多个IP地址上线。
IPv6地址的在线用户信息不能在不同FW之间同步。
用户经过RADIUS服务器认证但还没有获取到IP地址时，NAS设备向RADIUS服务器发送的计费开始报文中没有用户的IP地址，此时FW通过获取计费开始报文并不能使用户上线。当用户后续通过DHCP服务器获取到IP地址后，NAS设备向RADIUS服务器发送的计费更新报文中将含有用户的IP地址，FW通过获取计费更新报文使用户上线。
接入用户认证
接入用户认证指的是对各类VPN接入用户进行认证。
接入用户触发认证的方式由接入方式决定，包括SSL VPN、L2TP VPN、IPSec VPN和PPPoE：
- SSL VPN接入用户访问者登录SSL VPN模块提供的认证页面来触发认证过程，认证完成后，SSL VPN接入用户可以访问总部的网络资源。
- L2TP VPN接入用户对于LAC自主拨号方式，在接入阶段，分支机构的LAC通过拨号方式触发认证过程，与LNS建立L2TP VPN隧道。在访问资源阶段，分支机构中的访问者可以使用事前认证、会话认证等方式触发认证过程，认证完成后，L2TP VPN接入用户可以访问总部的网络资源。对于NAS-Initiated/Client-Initiated方式，在接入阶段，访问者通过拨号方式触发认证过程，与LNS建立L2TP VPN隧道。在访问资源阶段，分支机构中的访问者可以直接访问总部的网络资源；也可以使用事前认证、会话认证等方式触发二次认证，通过二次认证后，访问总部的网络资源。
- IPSec VPN接入用户分支机构与总部建立IPSec VPN隧道后，分支机构中的访问者可以使用事前认证、会话认证等方式触发认证过程，认证完成后，IPSec VPN接入用户可以访问总部的网络资源。
除了VPN接入阶段的认证，在资源访问阶段如需再次对用户进行认证，此时的认证过程与上网用户认证过程相同，用户IP地址为VPN解封装后的私网IP地址。
认证策略
认证策略用于决定FW需要对哪些数据流进行认证，匹配认证策略的数据流必须经过FW的身份认证才能通过。
缺省情况下，FW不对经过自身的数据流进行认证，需要通过认证策略选出需要进行认证的数据流。如果经过FW的流量匹配了认证策略将触发如下动作：
- 会话认证：访问者访问HTTP业务时，如果数据流匹配了认证策略，FW会推送认证页面要求访问者进行认证。
- 事前认证：访问者访问非HTTP业务时必须主动访问认证页面进行认证，否则匹配认证策略的业务数据流访问将被FW禁止。
- 免认证：访问者访问业务时，如果匹配了免认证的认证策略，则无需输入用户名、密码直接访问网络资源。FW根据用户与IP/MAC地址的绑定关系来识别用户。
- 单点登录：单点登录用户上线不受认证策略控制，但是用户业务流量必须匹配认证策略才能基于用户进行策略管控。
以下流量即使匹配了认证策略也不会触发认证：
- 访问设备或设备发起的流量
- DHCP、BGP、OSPF、LDP报文
- 触发认证的第一条HTTP业务数据流对应的DNS报文不受认证策略控制，用户认证通过上线后的DNS报文受认证策略控制
组成信息
认证策略是多个认证策略规则的集合，认证策略决定是否对一条流量进行认证。
认证策略规则由条件和动作组成，条件指的是FW匹配报文的依据，包括：
- 源安全区域
- 目的安全区域
- 源地址/地区
- 目的地址/地区
动作指的是FW对匹配到的数据流采取的处理方式，包括：
- Portal认证对符合条件的数据流进行Portal认证。
- 免认证对符合条件的数据流进行免认证，FW通过其他手段识别用户身份。主要应用于以下情况：
- 对于企业的高级管理者来说，一方面他们希望省略认证过程；另一方面，他们可以访问机密数据，对安全要求又更加严格。为此，管理员可将这类用户与IP/MAC地址双向绑定，对这类数据流进行免认证，但是要求其只能使用指定的IP或者MAC地址访问网络资源。FW通过用户与IP/MAC地址的绑定关系来识别该数据流所属的用户。
- 在AD/Agile Controller/RADIUS单点登录的场景中，FW已经从其他认证系统中获取到用户信息，对单点登录用户的业务流量进行免认证。
- 不认证对符合条件的数据流不进行认证，主要应用于以下情况：
- 不需要经过FW认证的数据流，例如内网之间互访的数据流。
- 在AD/Agile Controller/RADIUS单点登录的场景中，如果待认证的访问者与认证服务器之间交互的数据流经过FW，则要求不对这类数据流进行认证。
- 匿名认证对匹配该策略的流量进行匿名认证，用户无需输入用户名和密码即可完成认证，此时设备将用户的IP地址识别为用户身份。
匹配顺序
FW匹配报文时总是在多条认证策略规则之间进行，从上往下进行匹配，如图1所示。当数据流的属性和某条规则的所有条件匹配时，认为匹配该条规则成功，就不会再匹配后续的规则。如果所有规则都没有匹配到，则按照缺省认证策略进行处理。
FW上存在一条缺省的认证策略，所有匹配条件均为任意（any），动作为不认证。
认证域
认证域是认证流程中的重要环节，认证域上的配置决定了对用户的认证方式以及用户的组织结构。
概述
认证域主要有两个作用：
- 作为用户组织结构的容器用户、用户组和安全组均隶属于某个认证域，具体参见用户组织结构。
- 决定对用户的认证方式认证域中的认证方式针对接入用户、事前认证的上网用户、会话认证的上网用户生效。同一个认证域下的用户的认证方式相同，可以是本地认证或服务器认证。
不同场景下FW识别用户所属认证域的方式不同，如表1所示。
| 认证分类 | 认证域的作用 | 用户所属认证域 |
|---|---|---|
| 上网用户内置Portal认证（包括本地和服务器认证）、接入用户认证 | FW通过识别用户名中包含的认证域，将所有待认证的用户“分流”到对应的认证域中，根据认证域中的配置来对用户进行本地或服务器认证。 | 用户属于哪个认证域是由用户名中携带的“@”后的字符串来决定的。如“user1@bj”属于“bj”认证域，“user2@hz”属于“hz”认证域。如果认证域如“bj”，“hz”不存在，则用户无法登录。如果用户名中没有携带“@”，则属于缺省的default认证域。如果使用新创建的认证域，用户登录时需要输入“登录名@认证域名”；如果使用缺省的default认证域，则用户登录时只需要输入登录名，便于记忆。说明：对于LDAP和AD服务器认证，如果需要将服务器用户导入FW进行策略控制，则只能使用与服务器中域名同名的认证域或default认证域，否则用户无法导入。 |
| 上网用户单点登录 | FW不参与单点登录用户的认证过程，只是被动接收用户登录/注销消息，因此认证域中的认证配置对单点登录不起作用。单点登录用户需要在FW上线、基于用户进行策略控制，因此单点登录用户也必须隶属于某个认证域。 | AD单点登录：用户优先在FW上与服务器中用户域名同名的认证域上线，如果不存在则在default认证域上线。Agile Controller/RADIUS单点登录：当服务器用户名不包含“@”时，用户在default认证域上线；当服务器用户名包含“@”时，“@”后边的字符串作为用户域名，用户优先在FW上与该字符串同名的认证域上线，如果不存在则在default认证域上线。 |
| 上网用户自定义Portal认证（FW参与用户认证） | FW通过识别用户名中包含的认证域，将所有待认证的用户“分流”到对应的认证域中，根据认证域中的配置对用户进行认证、计费、授权。 | 用户属于哪个认证域是由用户名中携带的“@”后的字符串来决定的。如“user1@bj”属于“bj”认证域，“user2@hz”属于“hz”认证域。如果认证域如“bj”，“hz”不存在，则用户无法登录。如果用户名中没有携带“@”，则属于缺省的default认证域。如果使用新创建的认证域，用户登录时需要输入“登录名@认证域名”；如果使用缺省的default认证域，则用户登录时只需要输入登录名，便于记忆。 |
| 上网用户免认证 | 仅作为免认证用户的顶级父组。 | FW根据IP/MAC地址与用户的绑定关系，识别本地用户所属的认证域。 |
| 上网用户NTLM认证 | 仅作为NTLM认证用户的顶级父组。 | 用户优先在FW上与用户登录Windows的域名同名的认证域上线，如果不存在则在default认证域上线。 |
FW上的用户上线与认证域下的授权方案无关。当配置对用户进行服务器认证、本地授权时，即使用户在FW不存在，用户也可以授权通过正常上线。
接入控制
认证域可以对不同的用户进行接入控制：
- 上网行为管理针对上网用户进行基于安全策略、策略路由、带宽策略的控制。
- VPN接入针对接入用户的控制，包括SSL VPN接入、L2TP/L2TP over IPSec和远程用户的IPSec接入。此外，还可以根据实际情况来选择认证域是否允许对用户进行上网行为管理。如果认证域同时允许对用户进行上网行为管理，接入用户接入FW后，可以基于VPN接入用户进行策略控制，无需进行二次认证。如果认证域只允许VPN接入，则接入用户接入FW后，无法直接基于VPN接入用户进行策略控制，此时还需要创建一个类型为“上网行为管理”的认证域对用户进行二次认证。
- 管理员接入针对管理员的控制。如果认证域允许管理员接入，表示该认证域可以对接入的管理员进行认证。
认证方式和认证服务器
认证域决定了认证时采用本地认证方式还是服务器认证方式：
- 采用本地认证方式时，由FW来完成用户名和密码的验证过程，无需配置认证服务器。
- 采用服务器认证方式时，需要在FW上配置相应的认证服务器，然后由第三方认证服务器来完成用户名和密码的验证过程。
网络参数
对于VPN接入用户，FW会使用认证域中配置的地址池、DNS服务器、DHCP服务器等为用户分配私网IP及网络服务器，然后用户即可以使用分配到的网络参数来访问网络资源。
对于类型为“上网行为管理”的认证域，不需要配置地址池及网络服务器。
新用户选项
新用户指的是通过了服务器认证或单点登录，但是在FW上不存在的用户。例如，在AD服务器上为新员工创建了相应的用户名和密码，但没有在FW中同步创建。这些用户可以通过认证，但是FW中并没有存储这些用户。
FW根据新用户选项来决定对新用户的处理方式，包括：
- 不允许新用户登录不允许添加新用户到FW的本地用户组中。即不管该用户是否通过了认证服务器的认证，FW都不允许新用户登录。
- SSL VPN用户如果在自定义域上线，受该配置控制，不能成功登录。
- SSL VPN用户如果是在default域上线，不受该配置控制，SSL VPN用户仍可以登录成功并上线。
- 仅作为临时用户，不添加到本地用户列表中新用户认证通过后只能作为临时用户，不添加到FW的本地用户组中，但可以临时拥有FW上某个组的权限。临时用户只在一次登录中有效，用户下线或FW重启后该用户的信息就会消失，下次登录时仍然被识别为新用户。为保证用户上线效率，推荐将新用户仅作为临时用户，不添加到本地用户列表中。
用户权限控制
用户认证的最终目的是基于用户进行权限控制，FW通过在策略中引用用户作为匹配条件，对认证通过的用户进行权限控制。
用户权限控制与认证方式
FW进行用户权限控制的前提如下：
- 用户认证通过，在FW的上网用户在线列表上线。
- FW本地需要存在用户、用户组或安全组，供策略配置引用。
- 用户发起的业务流量必须匹配认证策略。
不同认证方式的权限控制规划不尽相同，如表1所示。
| 认证方式 | FW的用户存储方式 | 策略配置方式 | 新用户选项的处理 |
|---|---|---|---|
| 本地认证 | 用户、用户组和安全组都存在于本地。 | 管理员可以基于用户组/安全组/用户配置各类策略。 | 不涉及 |
| 服务器认证/单点登录 | 服务器上用户数据量非常大，只将服务器上的用户组/安全组导入到FW，具体用户信息不导入。 | 管理员基于用户组/安全组配置各类策略，不能基于具体用户配置策略。 | 因为FW上不保存用户信息，所有用户对于FW来说都是新用户。新用户选项指定为“仅作为临时用户，不添加到本地用户列表中”。 |
| 将服务器上全部组织结构导入FW | 管理员可以基于用户组/安全组/用户配置各类策略。 | 新用户作为临时用户，新用户选项指定为“仅作为临时用户，不添加到本地用户列表中”。 |
只有AD/LDAP/Agile Controller服务器支持用户导入，其他类型的服务器需要手动创建用户或通过CSV文件导入用户。
认证服务器与导入服务器分离
某些场景下，认证服务器只负责认证，然后通过另外一台服务器上组织结构控制用户权限。FW通过在认证域下的新用户选项中指定另外一台服务器的导入策略来满足此场景。
对于通过认证服务器认证，但是在FW上不存在的用户，FW根据新用户选项决定用户所属的用户组和安全组，其中如下处理方式涉及指定导入策略，如果此时导入策略对应的服务器与认证服务器不同，就实现了认证服务器与导入服务器分离。
作为临时用户并指定导入策略
用户通过认证服务器认证后，FW根据导入策略获取用户在导入服务器上的组织结构，用户在FW上与导入服务器对应的用户组和安全组临时上线。
这种用法有一个前提，导入服务器的组织结构需要提前导入FW，否则无法在与导入服务器对应的用户组和安全组上线。
认证服务器与导入服务器分离的支持情况如表2所示。
| 认证方式 | 认证服务器类型 | 导入服务器类型 |
|---|---|---|
| Portal认证 | AD | AD |
| AD | Sun ONE LDAP | |
| Sun ONE LDAP | Sun ONE LDAP | |
| 单点登录 | AD | AD |
| AD | Sun ONE LDAP | |
| Agile Controller | AD | |
| Agile Controller | Sun ONE LDAP | |
| RADIUS | AD | |
| RADIUS | Sun ONE LDAP |
用户与策略匹配
安全策略、策略路由、带宽策略、SSL加密流量检测策略、审计策略以及配额控制策略中可以引用用户组/安全组/用户作为匹配条件，用户权限是所属用户组和安全组权限的并集。如果策略中引用了用户组/安全组，组下用户的策略继承关系为：
- 用户组：用户组下的直属用户、所有下级子组的用户都继承用户组的策略。
- 安全组：只有安全组下的直属用户继承安全组的策略，安全组下的子安全组用户不继承上级安全组的策略。
但是由于策略的匹配顺序是“按照策略列表顺序从上到下匹配，匹配到一条策略则停止匹配”，当需要为某个用户/用户组配置除继承策略以外的策略时，用户/用户组策略并不是绝对按照树形组织结构继承。以如图1所示的树状组织结构为例，要求所有“研发部”员工都拥有相同的基础权限，在此基础上“研发1部”还拥有特有的权限，此时需要按照如下顺序配置策略。
| 策略名称 | 部门 | 权限 |
|---|---|---|
| policy1 | 研发1部 | 基础权限+独有权限 |
| policy2 | 研发部 | 基础权限 |
配置要点如下：
- 先配置“研发1部”的策略policy1，再配置“研发部”的公共策略policy2。如果不按此顺序配置，“研发1部”的用户将会先匹配到公共策略，不会再继续匹配独有的策略。
- 配置“研发1部”的策略policy1时必须同时指定基础权限和独有权限，因为此时“研发1部”的用户匹配到独有策略后不会再继续匹配公共策略，也就是子组无法继承父组的策略。
CLI举例：上网用户+本地认证（Portal认证）
介绍了FW作为企业的出口网关时，在FW本地存储用户信息，对上网用户进行本地认证和管理的举例。
组网需求
如图1所示，某企业在网络边界处部署了FW作为出口网关，连接内部网络与Internet。
企业内部网络中的访问者角色包括研发部员工、市场部员工和来访客户，这些人员均动态获取IP地址。
企业的网络管理员希望利用FW提供的用户管理与认证机制，将内部网络中的IP地址识别为用户，为实现基于用户的网络行为控制和网络权限分配提供基础。具体需求如下：
- 在FW上存储用户和部门的信息，体现公司的组织结构，供策略引用。
- 研发部员工和市场部员工访问网络资源之前必须通过FW的认证。
- 对于来访客户，访问网络资源之前必须通过FW的认证，并且只能使用特定的用户Guest来进行认证。
- 访问者使用会话认证的方式来触发认证过程，即访问者使用IE浏览器访问某个Web页面，FW会将IE浏览器重定向到认证页面。认证通过后，IE浏览器的界面会自动跳转到先前访问的Web页面。
配置思路
本举例只介绍配置用户与认证相关的内容。
- 创建用户组和用户，同时设置用户的密码。
- 创建认证策略，配置匹配条件和认证动作。
- 配置default认证域，将接入控制设置为“上网行为管理”。
- 配置安全策略，允许访问者访问认证页面。
数据规划
操作步骤
- 配置接口IP地址，并将接口加入安全区域。如下以接口GigabitEthernet 1/0/3为例介绍，其他接口请根据组网图数据配置。<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
- 创建研发部员工对应的组和用户。[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
- 创建市场部员工对应的组和用户。[FW] user-manage group /default/marketing [FW-usergroup-/default/marketing] quit [FW] user-manage user user_0002 [FW-localuser-user_0002] alias Jack [FW-localuser-user_0002] parent-group /default/marketing [FW-localuser-user_0002] password Admin@123 [FW-localuser-user_0002] undo multi-ip online enable [FW-localuser-user_0002] quit
- 创建来访客户对应的用户。[FW] user-manage user guest [FW-localuser-user_guest] parent-group /default [FW-localuser-user_guest] password Admin@123 [FW-localuser-user_guest] quit
- 设置用户认证通过后自动跳转到先前访问的Web页面。[FW] user-manage redirect
- 配置认证策略。[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
- 配置认证域。[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注意开放Trust到Untrust的DNS服务，允许解析HTTP业务域名的DNS报文通过。
- 配置允许用户访问外网的安全策略。[FW-policy-security] rule name policy_sec_02 [FW-policy-security-rule-policy_sec_02] source-zone trust [FW-policy-security-rule-policy_sec_02] source-address 10.3.0.0 24 [FW-policy-security-rule-policy_sec_02] destination-zone untrust [FW-policy-security-rule-policy_sec_02] action permit [FW-policy-security-rule-policy_sec_02] quit
- 配置允许用户访问服务器区的安全策略。[FW-policy-security] rule name policy_sec_03 [FW-policy-security-rule-policy_sec_03] source-zone trust [FW-policy-security-rule-policy_sec_03] source-address 10.3.0.0 24 [FW-policy-security-rule-policy_sec_03] destination-zone dmz [FW-policy-security-rule-policy_sec_03] action permit [FW-policy-security-rule-policy_sec_03] quit [FW-policy-security] 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
- 完成上述配置后，管理员在配置安全策略、策略路由、带宽策略、配额控制策略、代理策略以及审计策略时引用用户/组。
结果验证
- 研发部员工Tom使用IE浏览器访问www.example.org，将会重定向至认证页面，输入用户名user_0001和密码Admin@123进行认证。通过认证后，IE浏览器的界面会自动跳转到www.example.org页面。
- 市场部员工Jack使用IE浏览器访问www.example.org，将会重定向至认证页面，输入用户名user_0002和密码Admin@123进行认证。通过认证后，IE浏览器的界面会自动跳转到www.example.org页面。
- 来访客户使用IE浏览器访问www.example.org，将会重定向至认证页面，输入用户名guest和密码Admin@123进行认证。通过认证后，IE浏览器的界面会自动跳转到www.example.org页面。
- 员工或来访客户访问非HTTP类业务，例如访问FTP服务器时需要首先主动访问认证页面https://10.3.0.1:8887，通过认证后才能访问。其中认证页面的IP地址必须是FW接口IP地址，并且用户与该地址之间路由可达。
- 在FW上执行命令display user-manage online-user可以查看到在线用户信息。<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 IP Address: 10.3.0.5 Login Time: 2015-01-21 14:58:54 Online Time: 00:00:31 State: Active TTL: 00:30:00 Left Time: 00:30:17 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_0002 Parent User Group: /default/marketing IP Address: 10.3.0.10 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: guest Parent User Group: /default ——————————————————————————–
配置脚本
# sysname FW # user-manage redirect # interface GigabitEthernet1/0/1 ip address 1.1.1.1 255.255.255.0 # interface GigabitEthernet1/0/2 ip address 10.2.0.1 255.255.255.0 # interface GigabitEthernet1/0/3 ip address 10.3.0.1 255.255.255.0 # firewall zone trust add interface GigabitEthernet1/0/3 # firewall zone untrust add interface GigabitEthernet1/0/1 # firewall zone dmz add interface GigabitEthernet1/0/2 # aaa # domain default service-type internetaccess # # 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 rule name policy_sec_02 source-zone trust source-address 10.3.0.0 24 destination-zone untrust action permit rule name policy_sec_03 source-zone trust source-address 10.3.0.0 24 destination-zone dmz action permit # auth-policy rule name policy_auth_01 source-zone trust source-address 10.3.0.0 24 action auth # 以下创建用户/组的配置保存于数据库，不在配置文件体现 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 user-manage user user_0002 alias Jack parent-group /default/marketing password ********* undo multi-ip online enable user-manage user guest parent-group /default password *********