S7700 V200R019C10 配置指南-用户接入与认证
本文档介绍了用户接入与认证的配置，具体包括AAA配置、NAC配置、策略联动配置、PPPoE配置、DAA配置、IP Session配置和和Kerberos Snooping配置。
Portal认证原理描述
Portal认证简介
定义
Portal认证通常也称为Web认证，一般将Portal认证网站称为门户网站。用户上网时，必须在门户网站进行认证，如果未认证成功，仅可以访问特定的网络资源，认证成功后，才可以访问其他网络资源。
优点
- 一般情况下，客户端不需要安装额外的软件，直接在Web页面上认证，简单方便。
- 便于运营，可以在Portal页面上进行业务拓展，如广告推送、企业宣传等。
- 技术成熟，被广泛应用于运营商、连锁快餐、酒店、学校等网络。
- 部署位置灵活，可以在接入层或关键数据的入口作访问控制。
- 用户管理灵活，可基于用户名与VLAN/IP地址/MAC地址的组合对用户进行认证。
认证系统
Portal认证系统如图2-18所示，其主要包括四个基本要素：客户端、接入设备、Portal服务器与认证服务器。
- 客户端：安装有运行HTTP/HTTPS协议的浏览器的主机。
- 接入设备：交换机、路由器等接入设备的统称，主要有三方面的作用。
- 在认证之前，将认证网段内用户的所有HTTP/HTTPS请求都重定向到Portal服务器。
- 在认证过程中，与Portal服务器、认证服务器交互，完成对用户身份认证、授权与计费的功能。
- 在认证通过后，允许用户访问被管理员授权的网络资源。
- Portal服务器：接收客户端认证请求的服务器系统，提供免费门户服务和认证界面，与接入设备交互客户端的认证信息。
- 认证服务器：与接入设备进行交互，完成对用户的认证、授权与计费。
Portal认证协议
Portal接入协议：HTTP/HTTPS协议，描述了客户端和Portal服务器之间的协议交互。
客户端通过HTTP/HTTPS协议依次向Portal服务器发起连接请求和Portal认证请求。具体认证流程请参见基于Portal协议的Portal认证流程或基于HTTP/HTTPS协议的Portal认证流程。
Portal认证协议：支持如下两种认证协议。
Portal协议：描述了Portal服务器和接入设备之间的协议交互，可以用来传递用户名和密码等参数。其兼容中国移动Portal 2.0协议，支持该协议的基本功能。
收到客户端的Portal认证请求后，Portal服务器通过Portal协议向接入设备发起Portal认证请求(携带用户名和密码)。具体认证流程请参见基于Portal协议的Portal认证流程。
HTTP/HTTPS协议：描述了客户端和接入设备之间的协议交互，可以用来传递用户名和密码等参数。
收到客户端的Portal认证请求后，Portal服务器通过HTTP/HTTPS协议通知客户端向接入设备发起Portal认证请求，然后客户端通过HTTP/HTTPS协议向接入设备发起Portal认证请求(携带用户名和密码)。具体认证流程请参见基于HTTP/HTTPS协议的Portal认证流程。
建议接入设备使用Portal协议与Portal服务器对接，如果Portal服务器不支持Portal协议，则接入设备可以使用HTTP/HTTPS协议。
使用内置Portal服务器进行Portal认证时，接入设备仅支持Portal协议。
HTTP/HTTPS协议可以作为Portal接入协议，也可以作为Portal认证协议。这里重点介绍接入设备支持的Portal认证协议的相关内容。
Portal协议
报文字段
Version
Portal协议的版本号，长度为1字节，默认取值为0x02。
Type
Portal协议的报文类型，长度为1字节。
报文类型 |
取值 |
含义 |
|---|---|---|
REQ_CHALLENGE |
0x01 |
Portal服务器向接入设备发送的Challenge请求报文 |
ACK_CHALLENGE |
0x02 |
接入设备对Portal服务器Challenge请求的响应报文 |
REQ_AUTH |
0x03 |
Portal服务器向接入设备发送的认证请求报文 |
ACK_AUTH |
0x04 |
接入设备对Portal服务器认证请求的响应报文 |
REQ_LOGOUT |
0x05 |
Portal服务器向接入设备发送的下线请求报文 |
ACK_LOGOUT |
0x06 |
接入设备对Portal服务器下线请求的响应报文 |
AFF_ACK_AUTH |
0x07 |
Portal服务器向接入设备发送的认证成功响应报文 |
NTF_LOGOUT |
0x08 |
接入设备向Portal服务器发送的用户被强制下线通知报文 |
REQ_INFO |
0x09 |
Portal服务器向接入设备发送的信息询问报文 |
ACK_INFO |
0x0a |
接入设备对Portal服务器信息询问的应答报文 |
ACK_NTF_LOGOUT |
0x0e |
Portal服务器通知接入设备用户强制下线成功 |
USER_SYN |
0x10 |
Portal服务器向接入设备发送的用户信息同步请求报文 |
ACK_USER_SYN |
0x11 |
接入设备对Portal服务器用户信息同步请求的响应报文 |
STATUS_NOTIFY |
0x81 |
Portal服务器定时向接入设备发送的状态通知报文 |
ACK_STATUS_NOTIFY |
0x82 |
接入设备对Portal服务器状态通知报文的响应报文 |
MAC_QUERY |
0x30 |
接入设备对Portal服务器查询MAC缓存报文 |
ACK_MAC_QUERY |
0x31 |
Portal服务器给接入设备发送的MAC缓存查询回应报文 |
AuthType
认证方式，长度为1字节。设备支持两种认证方式：
CHAP认证：取值为0，是一种三次握手认证，它采用密文方式传输用户名和密码。
PAP认证：取值为0x01，是一种两次握手认证，它采用明文方式传输用户名和密码。
CHAP认证方式才有REQ_CHALLENGE和ACK_CHALLENGE的交互步骤。CHAP认证保密性较好，更为安全可靠。如果是基于安全性的考虑，建议采用该方式。
Rsvd
目前为保留字段，长度为1字节，在所有报文中取值为0。
SerialNo
报文的序列号，长度为2字节，由Portal服务器随机生成。Portal服务器必须保证在同一个认证流程中所有报文的序列号相同；在不同认证流程中的报文序列号在一定时间内不得重复。
RequestID
报文ID，长度为2字节，由接入设备生成，RequestID不会重复。
UserIP
Portal用户的IP地址，长度为4字节。
UserPort
目前为保留字段，长度为2字节，在所有报文中取值为0。
ErrCode
错误码，长度为1字节。其和Type字段一起表示一定的意义。
Type值为0x01、0x03、0x07、0x09、0x0e、0x10、0x11、0x30、0x31、0x81、0x82时
ErrCode字段无意义，取值为0。
Type值为0x02时
- ErrCode值为0，表示接入设备通知Portal服务器Challenge请求成功。
- ErrCode值为0x01，表示接入设备通知Portal服务器Challenge请求被拒绝。
- ErrCode值为0x02，表示接入设备通知Portal服务器此链接已建立。
- ErrCode值为0x03，表示接入设备通知Portal服务器有一个用户正在认证过程中，请稍后再试。
- ErrCode值为0x04，表示接入设备通知Portal服务器此用户Challenge请求失败。
- ErrCode值为0xfd，表示接入设备通知Portal服务器未找到此用户（用户已漫游或下线）。
Type值为0x04时
- ErrCode值为0，表示接入设备通知Portal服务器此用户认证成功。
- ErrCode值为0x01，表示接入设备通知Portal服务器此用户认证请求被拒绝。
- ErrCode值为0x02，表示接入设备通知Portal服务器此链接已建立。
- ErrCode值为0x03，表示接入设备通知Portal服务器有一个用户正在认证过程中，请稍后再试。
- ErrCode值为0x04，表示接入设备通知Portal服务器此用户认证失败（发生错误，例如用户名错误）。
- ErrCode值为0x05，表示接入设备通知Portal服务器此用户认证失败（Portal在线用户数已达到最大值）。
- ErrCode值为0x06，表示接入设备通知Portal服务器此用户认证失败（设备正在对该终端进行其他方式的认证）。
- ErrCode值为0xfd，表示接入设备通知Portal服务器未找到此用户（用户已漫游或下线）。
Type值为0x05时
- ErrCode值为0，表示Portal服务器发给接入设备的请求下线报文。
- ErrCode值为0x01，表示Portal服务器没有收到接入设备对各种请求的响应报文时，定时器超时后Portal服务器发给接入设备的报文。
Type值为0x06时
- ErrCode值为0，表示接入设备通知Portal服务器此用户下线成功。
- ErrCode值为0x01，表示接入设备通知Portal服务器此用户下线被拒绝。
- ErrCode值为0x02，表示接入设备通知Portal服务器此用户下线失败。
Type值为0x08时
ErrCode值为0x02，表示接入设备通知Portal服务器此用户被强制下线。
Type值为0x0a时
- ErrCode值为0，表示接入设备通知Portal服务器此询问消息处理成功。
- ErrCode值为0x01，表示接入设备通知Portal服务器此询问消息处理失败（不支持该功能）。
- ErrCode值为0x02，表示接入设备通知Portal服务器此询问消息处理失败（发生错误，例如询问消息格式错误）。
AttrNum
属性字段中属性的个数，长度为1字节，属性字段中最多有255个属性。
Authenticator
验证字，长度为16字节。其是通过MD5算法对各字段计算后得出的数据。
Attribute
一个可变长字段，由多个属性组合而成，每个属性的格式为TLV格式。
AttrType：属性类型，长度为1字节。
AttrLen：属性字段的长度，长度为1字节，其值是AttrType、AttrLen、AttrValue三个字段的长度之和。
AttrValue：具体的属性值，如下表所示。例如用户名、密码等，长度有些可变，有些固定，但最长不能超过253字节。
Attribute |
AttrType |
AttrValue长度 |
说明 |
使用该属性的消息类型 |
|---|---|---|---|---|
UserName |
0x01 |
1～253 |
用户名，具体格式为：“用户名”＋“@”+“域名”，例如test@huawei.com |
REQ_AUTH |
PassWord |
0x02 |
1～128 |
用户提交的密码 |
REQ_AUTH |
Challenge |
0x03 |
16 |
CHAP方式加密的认证字 |
ACK_CHALLENGE |
ChapPassWord |
0x04 |
16 |
经过CHAP方式加密后的密码 |
REQ_AUTH |
TextInfo |
0x05 |
2～253 |
用于将RADIUS等第三方鉴权设备的提示信息透传到Portal服务器。该属性所携带的内容为字符串，但是不包括字符串结束符‘\0’。该属性在同一个报文中允许出现多个，建议只携带1个该属性。 |
ACK_AUTH、REQ_AUTH（仅Portal 1.0版本） |
Port |
0x08 |
1～51 |
端口号，其格式为：
|
REQ_INFO、ACK_INFO |
Bas_IP |
0x0a |
4 |
用户漫游后的AC IP地址 |
ACK_AUTH、ACK_CHALLENGE |
User_Mac |
0x0b |
6 |
用户的MAC地址 |
ACK_AUTH、ACK_LOGOUT、NTF_LOGOUT、ACK_CHALLENGE、ACK_INFO、REQ_CHALLENGE、REQ_AUTH、REQ_LOGOUT |
User_Private_IP |
0x0d |
4～252 |
用户的IPv4地址 |
USER_SYN、ACK_USER_SYN |
WebAuthenInfo |
0x40 |
1～247 |
用于将用户在Web页面上的输入传递给RADIUS服务器，可携带多个 |
REQ_AUTH |
User_IPV6 |
0xf1 |
16 |
用户的IPv6地址 |
REQ_CHALLENGE、ACK_CHALLENGE、REQ_AUTH、ACK_AUTH、REQ_LOGOUT、ACK_LOGOUT、AFF_ACK_AUTH、NTF_LOGOUT、REQ_INFO、ACK_INFO |
HTTP/HTTPS协议
简介
超文本传输协议HTTP（HyperText Transfer Protocol）是一种用于传送万维网WWW（World Wide Web）数据的传输协议。
超文本传输安全协议HTTPS（Hypertext Transfer Protocol Secure），也常称为HTTP over TLS（Hyper Text Transfer Protocol over Transport Layer Security）或HTTP over SSL（Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。HTTPS通过HTTP进行通信，并使用SSL/TLS来加密数据。
HTTPS主要用来身份认证，保护数据的隐私与完整性。
客户端请求方法
Portal认证时，Portal服务器会通知客户端使用HTTP/HTTPS协议向接入设备发起Portal认证请求，然后客户端将Portal认证请求转发给接入设备，请求报文中会携带HTTP请求方法、HTTP请求正文（即请求的数据，包含用户名和密码等参数）等内容。
目前设备支持两种HTTP请求方法：
POST：请求的数据放置在HTTP请求包的包体中，不作为URL的一部分，不易被窃取，安全性较高。设备默认支持此请求方法。
GET：请求的数据会附加在URL之后，以?分割URL和数据。数据在URL中对所有人都是可见的，易被窃取，安全性较差。
设备收到认证请求后，会根据参数名称解析请求报文来获取用户名和密码等参数，然后将获取的用户名和密码向RADIUS服务器进行认证。请求报文中的参数名称必须符合特定的规范（如表2-10所示），否则设备无法解析请求报文，导致用户认证失败。例如设备收到的POST报文参数（username=abc&password=abc&client_mac=112233445566&initurl=http://portalserver.example.com/login），设备解析POST报文失败，因为POST报文中的用户MAC地址参数名称client_mac与设备默认的用户MAC地址参数名称macaddress不一致。
因此，使用HTTP/HTTPS协议进行Portal认证时，用户必须确保Portal服务器上设置的参数名称与设备一致。
默认参数名称 |
描述 |
是否必须携带 |
|---|---|---|
cmd |
用户操作命令 |
必选 |
login |
用户登录 |
用户登录操作：可选 |
logout |
用户注销 |
用户注销操作：必选 |
initurl |
用户初始登录的URL |
可选 |
username |
用户名 |
用户登录操作：必选 用户注销操作：无需携带 |
password |
密码 |
用户登录操作：必选 用户注销操作：无需携带 |
ipaddress |
用户IP地址 |
可选（设备使用HTTP报文源IP地址识别用户） |
macaddress |
用户MAC地址 |
可选 |
如上参数取值不能包含空格和“&”。
如下是GET方式的URL示例，HTTPS请求数据会附加在URL之后：
- 用户登录操作：http://192.168.1.1:8000/login?username=example&password=example@123
- 用户注销操作：http://192.168.1.1:8000/login?cmd=logout&ipaddress=10.1.1.1
如下是POST方式的URL示例，HTTPS请求数据放置在HTTP请求包的包体中，不作为URL的一部分。比如上述GET方式的用户登录操作示例中，“username=example”，“password=example@123”数据会被放置在HTTP请求包的包体中：
- 用户登录操作：http://192.168.1.1:8000/login
Portal认证方式
按照网络中实施Portal认证的网络层次来分，Portal认证方式分为两种：二层认证方式和三层认证方式。
当客户端与接入设备之间为二层网络时，即客户端与接入设备直连（或之间只有二层设备存在），接入设备可以学习到客户端的MAC地址，则接入设备可以利用IP地址和MAC地址来识别用户，此时可配置Portal认证为二层认证方式。
二层认证流程简单，安全性高，但由于限制了用户只能与接入设备处于同一网段，所以组网灵活性不高。
当客户端与接入设备之间包含三层网络时，即客户端与接入设备之间存在三层转发设备，接入设备不能获取到认证客户端的MAC地址，只能以IP地址作为用户的唯一标识，此时需要将Portal认证配置为三层认证方式。
三层认证组网灵活，容易实现远程控制，但由于只能以IP地址作为用户的唯一标识，所以安全性不高。
Portal认证流程
认证的第一件事情就是发起认证，有两种认证触发方式：
主动认证
用户通过浏览器主动访问Portal认证网站时，即在浏览器中直接输入Portal服务器的网络地址，然后在显示的网页中输入用户名和密码进行认证，这种开始Portal认证过程的方式即为主动认证，即由用户自己主动访问Portal服务器发起的身份认证。
重定向认证
用户输入的访问地址不是Portal认证网站地址时，将被强制访问Portal认证网站（通常称为重定向），从而开始Portal认证过程，这种方式称作重定向认证。
基于Portal协议的Portal认证流程
在二层认证方式下，用户上线时的报文交互流程如图2-20所示。对于三层认证方式，客户端与接入设备之间没有建立预连接过程，其余报文处理流程跟二层认证完全一致。
在认证之前客户端与接入设备之间建立起预连接，即客户端用户在认证成功之前在接入设备上已建立用户在线表项，并且只有部分网络访问权限。
客户端发起HTTP连接请求。
接入设备收到HTTP连接请求报文时，如果是访问Portal服务器或免认证网络资源的HTTP报文，则接入设备允许其通过；如果是访问其它地址的HTTP报文，则接入设备将其URL地址重定向到Portal认证页面。
客户端根据获得的URL地址向Portal服务器发起HTTP连接请求。
Portal服务器向客户端返回Portal认证页面。
- 用户在Portal认证页面输入用户名和密码后，客户端向Portal服务器发起Portal认证请求。
- （可选）Portal服务器收到Portal认证请求后，如果Portal服务器与接入设备之间采用CHAP认证，则Portal服务器向接入设备发起Portal挑战字请求报文（REQ_CHALLENGE）；如果Portal服务器与接入设备之间采用PAP认证，则接入设备直接进行第9步。
- （可选）接入设备向Portal服务器回应Portal挑战字应答报文（ACK_CHALLENGE）。
- Portal服务器将用户输入的用户名和密码封装在Portal认证请求报文（REQ_AUTH）中，并发送给接入设备。
- 接入设备根据获取到的用户名和密码，向RADIUS服务器发送RADIUS认证请求（ACCESS-REQUEST）。
RADIUS服务器对用户名和密码进行认证。如果认证成功，则RADIUS服务器向接入设备发送认证接受报文（ACCESS-ACCEPT）；如果认证失败，则RADIUS服务器返回认证拒绝报文（ACCESS-REJECT）。
由于RADIUS协议合并了认证和授权的过程，因此认证接受报文中也包含了用户的授权信息。
- 接入设备根据接收到的认证结果接入/拒绝用户。如果允许用户接入，则接入设备向RADIUS服务器发送计费开始请求报文（ACCOUNTING-REQUEST）。
- RADIUS服务器返回计费开始响应报文（ACCOUNTING-RESPONSE），并开始计费，将用户加入自身在线用户列表。
- 接入设备向Portal服务器返回Portal认证结果（ACK_AUTH），并将用户加入自身在线用户列表。
- Portal服务器向客户端发送认证结果报文，通知客户端认证成功，并将用户加入自身在线用户列表。
- Portal服务器向接入设备发送认证应答确认（AFF_ACK_AUTH）。
基于HTTP/HTTPS协议的Portal认证流程
在二层认证方式下，用户上线时的HTTP协议认证报文交互过程如图2-21所示。对于三层认证方式，客户端与接入设备之间没有建立预连接过程，其余报文处理流程跟二层认证完全一致。
HTTPS协议认证报文交互过程与HTTP类似，区别在于HTTPS报文经过加解密处理。
在认证之前客户端与接入设备之间建立起预连接，即客户端用户在认证成功之前在接入设备上已建立用户在线表项，并且只有部分网络访问权限。
客户端发起HTTP连接请求。
接入设备收到HTTP连接请求时，如果是访问Portal服务器或免认证网络资源的HTTP报文，则接入设备允许其通过；如果是访问其它地址的HTTP报文，则接入设备将其URL地址重定向到Portal认证页面。
客户端根据获得的URL地址向Portal服务器发起HTTP连接请求。
Portal服务器向客户端返回Portal认证页面。
- 用户在Portal认证页面输入用户名和密码后，客户端向Portal服务器发起Portal认证请求。
- Portal服务器通知客户端向接入设备发起Portal认证请求。
- 客户端向接入设备发起Portal认证请求（HTTP POST/GET）。
- 接入设备根据获取到的用户名和密码，向RADIUS服务器发送RADIUS认证请求（ACCESS-REQUEST）。
RADIUS服务器对用户名和密码进行认证。如果认证成功，则RADIUS服务器向接入设备发送认证接受报文（ACCESS-ACCEPT）；如果认证失败，则RADIUS服务器返回认证拒绝报文（ACCESS-REJECT）。
由于RADIUS协议合并了认证和授权的过程，因此认证接受报文中也包含了用户的授权信息。
- 接入设备根据接收到的认证结果接入/拒绝用户。如果允许用户接入，则接入设备向RADIUS服务器发送计费开始请求报文（ACCOUNTING-REQUEST）。
- RADIUS服务器返回计费开始响应报文（ACCOUNTING-RESPONSE），并开始计费，将用户加入自身在线用户列表。
- 接入设备向客户端返回Portal认证结果，并将用户加入自身在线用户列表。
Portal认证授权
认证用于确认尝试接入网络的用户身份是否合法，而授权则用于指定身份合法的用户所能拥有的网络访问权限，即用户能够访问哪些资源。授权最基础也是最常使用的参数是ACL和UCL组，此处以RADIUS授权进行说明，其他授权方式的授权方法以及更多可授权的参数请参见AAA授权方案。
UCL
- 授权UCL组名称：RADIUS服务器通过RADIUS标准属性Filter-Id将UCL组名称授权给指定用户。
- 授权UCL组ID：RADIUS服务器通过华为RADIUS扩展属性HW-UCL-Group将UCL组ID授权给指定用户。
用户组
用户组指具有相同角色、相同权限等属性的一组用户（终端）的集合。每个用户组可以关联不同的ACL、CAR、报文优先级，因而通过用户组授权，可以实现对每类用户进行基于ACL的访问控制、基于VLAN的访问控制、流量控制以及优先级控制，管理更灵活。
比如，由于ACL资源有限，当每用户需要的授权ACL较多时，上线授权的用户数无法达到规格，但实际用户数很大，用户权限的分类比较少的，此时可以使用用户组，每一组用户复用ACL，以利用有限的ACL支持较大规格的用户进行ACL授权。 用户组可以在RADIUS服务器上配置，也可以在设备端配置（需在AAA域下应用）。如果用户希望使用RADIUS服务器下发的用户组授权，需要保证RADIUS服务器上下发的用户组在设备上已经配置（不需在AAA域下应用）。
RADIUS服务器下发用户组授权的方式和下发ACL ID的方式一样，都是用11号标准属性Filter-Id来携带，属性值填充用户组名称。11号属性将优先被当成ACL编号处理。当设备上不存在该ACL编号的时候，则当成用户组处理，如果设备上也不存在该用户组时，则授权失败。
RADIUS服务器下发的用户组授权优先级高于设备端配置的用户组授权，当服务器下发的用户组授权失败后，用户会采用设备端配置的用户组授权。
free-rule
用户认证成功之前，为满足用户基本的网络访问需求，需要用户认证成功前就能获取部分网络访问权限。可在free-rule模板中配置free-rule规则，满足用户的认证成功前的网络访问需求。
用户的free-rule可以通过普通的free-rule定义，也可以通过ACL定义。普通的free-rule由IP地址、MAC地址、接口、VLAN等参数确定；通过ACL定义的free-rule由ACL规则确定。两种方式定义的free-rule都能够指定用户无需认证就可以访问的目的IP地址。除此之外，ACL定义的free-rule还能够指定用户认证成功前就可以访问的目的域名。
基于域名定义用户的free-rule有时要比基于IP地址简单方便。例如，某些认证用户由于没有认证账号，必须首先在运营商提供的官方网站上注册申请会员账号；或者通过微博、微信等第三方账号进行登录。这就要求用户认证通过前，能够访问特定的网站。由于用户记忆网站的域名要比记忆其IP地址容易的多，所以，此时可以通过ACL定义的free-rule，指定用户认证成功前即可访问以上网站域名。
Portal认证用户下线
- RADIUS服务器仍会对该用户进行计费，造成误计费。
- 存在非法用户仿冒合法用户IP地址和MAC地址接入网络的风险。
- 已下线用户数量过多的情况下，还会占用设备用户规格，可能会导致其他用户无法接入网络。
因此，接入设备要能够及时感知到用户已下线，删除该用户表项，并通知RADIUS服务器停止对该用户进行计费。
用户下线分为客户端主动下线、接入设备控制用户下线、认证服务器强制用户下线和Portal服务器强制用户下线。
客户端主动下线
由用户发起的主动下线，例如用户点击注销按钮，客户端向Portal服务器发送用户注销请求。
对于Portal协议，Portal服务器收到用户的下线请求后，会通知客户端下线成功，而不需要等待接入设备对下线的确认。对于HTTP/HTTPS协议，Portal服务器收到用户的下线请求后，会通知客户端向接入设备发送用户下线通知。
Portal协议
具体下线流程如图2-22所示。
- 客户端向Portal服务器发送用户注销请求。
- Portal服务器向客户端发送用户注销响应，并向接入设备发送用户下线通知报文（REQ_LOGOUT）。
接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST），并将用户下线。同时，接入设备向Portal服务器发送用户下线响应报文（ACK_LOGOUT）。
Portal服务器收到用户下线响应后，将用户下线。
- RADIUS服务器返回停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。
HTTP/HTTPS协议
- 客户端向Portal服务器发送用户注销请求。
- Portal服务器通知客户端向接入设备发送用户注销请求，并将用户下线。
- 客户端向接入设备发送用户注销请求。
- 接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST），并将用户下线。同时，接入设备向客户端发送用户注销响应报文。
- RADIUS服务器返回停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。
接入设备控制用户下线
接入设备控制用户下线有两种方式：
- 在接入设备上执行命令cut access-user强制指定用户下线。
- 在接入设备上配置用户探测功能，用于探测用户是否在线。当用户在指定的时间内无响应，则认为用户下线，删除用户表项。
具体下线流程如图2-24所示。这里以Portal协议为例介绍下线探测的下线流程，对于HTTP/HTTPS协议，接入设备不会向Portal服务器发送用户下线通知。
下线探测过程。
接入设备获取到客户端IP地址，启动下线探测定时器，周期为time-length（三层Portal认证的握手周期通过命令authentication timer handshake-period time-length进行配置，探测方式为ICMP报文探测；二层Portal认证用户的握手周期通过命令portal timer offline-detect time-length，探测方式为ARP报文探测）。假如握手周期为3T，则设备会在T、2T时刻进行用户探测。以0～T时间段为例，T～2T与之类似，不再赘述。
- 如果在0～T时间段内，有用户流量经过设备，则在T时刻，设备认为用户在线，该时刻设备不会再发送探测报文，并重置探测定时器（即3T）周期。
- 如果在0～T时间段内，没有用户流量经过设备，则在T时刻，设备无法感知到用户是否在线，该时刻设备会发送探测报文。如果设备收到用户的回应报文，则认为用户在线，并重置探测定时器；如果未收到，则认为用户已下线。
- 如果在2T～3T时间段内，有用户流量经过设备，则在3T时刻，设备认为用户在线，该时刻设备重置探测定时器。
- 如果在2T～3T时间段内，没有用户流量经过设备，则在3T时刻，设备无法感知到用户是否在线，认为用户已下线。
如果在T、2T、3T时刻，设备均认为用户已下线，则设备会删除该用户的所有相关表项。为防止用户PC闲置时被异常下线，请不要将握手周期设置的过小，推荐使用默认值。
接入设备向Portal服务器发送用户下线通知（NTF_LOGOUT），并将用户下线。同时，接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST）。
Portal服务器向接入设备发送用户下线响应报文（AFF_ACK_LOGOUT），并将用户下线。RADIUS服务器向接入设备发送停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。
认证服务器强制用户下线
服务器强制用户下线有以下方式：
- RADIUS服务器可通过DM报文（Disconnect Message）强制用户下线。DM是指用户离线报文，即由RADIUS服务器端主动发起的强制用户下线的报文。
- RADIUS服务器通过授权RADIUS标准属性Session-Timeout和Termination-Action。其中，Session-Timeout为用户在线时长定时器，Termination-Action属性值为0表示将用户下线。当用户在线的时长达到定时器指定的数值时，设备会将用户下线。
具体下线流程如图2-25所示，以RADIUS服务器通过DM报文强制用户下线为例。
RADIUS服务器向接入设备发送用户下线请求（DM Request）。
接入设备向Portal服务器发送下线通知（NTF_LOGOUT），并将用户下线。同时，接入设备向RADIUS服务器发送下线响应（DM ACK）及停止计费请求报文（ACCOUNTING-REQUEST）。
使用HTTP/HTTPS协议时，接入设备不会向Portal服务器发送下线通知。
Portal服务器向接入设备发送用户下线响应报文（AFF_ACK_LOGOUT），并将用户下线。RADIUS服务器向接入设备发送停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。
Portal服务器强制用户下线
当管理员注销用户或Portal服务器主动探测发现用户已经离线等事件发生时，Portal服务器将用户下线，并向接入设备发送下线通知。
具体下线流程如图2-26所示。这里以使用Portal协议的Portal服务器为例介绍下线流程，使用HTTP/HTTPS协议的Portal服务器强制用户下线时直接将用户下线，不会通知接入设备将用户下线。
- Portal服务器向接入设备发送用户下线通知报文（REQ_LOGOUT）。
接入设备向RADIUS服务器发送停止计费请求报文（ACCOUNTING-REQUEST），并将用户下线。同时，接入设备向Portal服务器发送用户下线响应报文（ACK_LOGOUT）。
Portal服务器收到用户下线响应后，将用户下线。
- RADIUS服务器返回停止计费响应报文（ACCOUNTING-RESPONSE），并将用户下线。
Portal定时器
如表2-11所示，接入设备支持以下Portal定时器。
Portal定时器 |
功能 |
适用场景 |
|---|---|---|
用来防止用户认证失败时频繁认证，形成了一种DoS攻击，浪费系统资源。 |
适用于使用Portal或HTTP/HTTPS协议的外置Portal服务器，或者使用Portal协议的内置Portal服务器场景。 |
|
用来防止接入设备与Portal服务器之间出现网络故障导致通信中断或Portal服务器本身出现故障时，已经在线的Portal用户无法正常下线或新的Portal认证用户无法上线。 |
适用于使用Portal协议或HTTP/HTTPS协议的外置Portal服务器场景。 |
|
用来防止接入设备与Portal服务器之间出现网络故障导致通信中断或Portal服务器本身出现故障时，已经在线的Portal用户无法正常下线，造成接入设备与Portal服务器用户信息不一致以及计费不准确问题。 |
适用于使用Portal协议的外置Portal服务器场景。 |
|
用来防止接入设备与Portal服务器之间的网络不稳定、存在丢包等现象时，Portal服务器接收不到接入设备发送的用户下线报文，出现用户在接入设备上显示已经下线，在Portal服务器上显示仍然在线的情况。 |
适用于使用Portal协议的外置Portal服务器场景。 |
用户静默定时器
用户在60秒内认证失败的次数超过指定的次数（通过命令portal quiet-times fail-times）时，接入设备会将该用户静默一段时间（通过命令portal timer quiet-period quiet-period-value配置），在静默期间，接入设备会丢弃该用户的Portal认证请求。具体静默流程如图2-27所示，以使用Portal协议认证为例。
Portal服务器探测定时器
设备对Portal服务器的探测方式有Portal方式和HTTP方式两种。对于采用Portal协议的Portal认证，设备两种探测方式都支持，对于HTTP/HTTPS方式的Portal认证，仅支持HTTP方式的探测。
Portal方式的Portal服务器探测：Portal服务器定期发送心跳报文给接入设备，接入设备通过检测此报文来判断服务器的可达状态，如果接入设备在指定的探测周期内（通过命令server-detect interval interval-period）收到Portal心跳报文或者其它认证报文，则认为此次探测成功且服务器可达（状态为Up），否则认为此次探测失败。当对某一Portal服务器连续探测失败次数超过最大次数（通过命令server-detect max-times times）时，接入设备会将该Portal服务器的状态由Up改变为Down。
HTTP方式的Portal服务器探测：设备按照探测周期发送HTTP报文给Portal服务器，Portal服务器进行回应，如果接入设备在指定的探测周期内（通过命令server-detect interval interval-period配置）收到回应报文，则认为探测成功。否则认为此次探测失败。连续探测失败次数超过最大次数（通过命令server-detect max-times times配置）时，接入设备会将该Portal服务器的状态由Up改变为Down。
建议在接入设备上配置的Portal服务器探测周期interval-period大于在Portal服务器上配置的心跳报文周期T。
同时，接入设备将会做出以下动作，使管理员能够实时掌握网络中Portal服务器的状态或保证用户一定的网络访问权限。
- 发送告警：Portal服务器可达或者不可达的状态改变时，发送告警信息给网管，其中记录了Portal服务器IP地址以及该服务器的当前状态。
- 发送日志：Portal服务器可达或者不可达的状态改变时，发送日志信息给网管，其中记录了Portal服务器IP地址以及该服务器的当前状态。
- 启用Portal逃生机制：状态为Up的Portal服务器数目小于或等于设置的最小值（通过命令server-detect critical-num critical-num）时，暂时取消接口的Portal认证，允许所有Portal用户访问指定的网络资源，请参见NAC逃生机制中的“Portal服务器Down”授权。之后，当接入设备收到某Portal服务器的心跳报文，或者收到其它认证报文（例如用户下线报文），或者HTTP探测成功时，接入设备会将该Portal服务器的状态由Down改变为Up，如果状态为Up的Portal服务器数目大于设置的最小值，则恢复该接口的Portal认证功能。
用户信息同步定时器
Portal服务器周期性地（周期为Tps）将在线用户信息通过用户信息同步请求报文（USER_SYN）发送给接入设备。接入设备在开启Portal用户信息同步功能之后，即启动用户信息同步定时器，在用户信息同步周期内（通过命令user-sync interval interval-period配置），收到用户同步请求报文后，将其中携带的在线用户信息与自己的在线用户信息进行对比。
- 同步请求报文中的用户信息与设备上实际用户信息相同时，则设备不对该同步请求报文进行响应，只是将这些用户标记为已同步。
- 设备上存在未同步用户时，回应同步请求报文。如果在达到同步最大次数（通过命令user-sync max-times times配置）仍未同步成功，设备会将该用户强制下线。
- 仅在Portal上存在的用户，设备回应同步请求报文，Portal服务器将其删除。
具体同步流程如图2-30所示。
该功能仅适用于使用Portal协议的外置Portal服务器认证场景。目前接入设备仅支持和华赛TSM Portal服务器同步用户信息。
建议接入设备配置的interval-period x times的值应该大于Portal服务器发送同步请求报文的时间间隔，否则设备可能会在达到最大失败次数后，由于收不到Portal服务器的同步请求报文，将用户强制下线。
用户下线重传定时器
为使Portal服务器能够接收到用户下线报文，保证Portal服务器上的用户在线信息正确，接入设备提供用户下线报文重传功能，在用户下线重传周期period内，接入设备没有收到Portal服务器的用户下线应答报文，会重传用户下线报文，最多重传times次（通过命令portal logout resend times timeout period配置）。
具体下线流程如图2-31所示。
