首先，要在这里感谢李磊的耐心帮助和答疑。通过操作学习完了一些Lab Guider，从中学到了很多。对我个人来说至少从一个刚接触aruba一无所知的小白，变成一个好歹可以做一些简单配置的不那么白。 做这篇学习心得目的是将一些过程中粗浅的理解向和我一样刚接触的同志们做一些分享，抛砖引玉。以下是我做实验过程中一些心得，包括三部分：做实验中的体会，Clearpass配置项的理解，以及Portal无感知的实验流程理解。且只作为个人理解，有问题的地方欢迎并感谢大家指正！

一、做实验的体会

首先，需要理解着做。一开始我用按照实验手册一步一步地往下操作（或者说只是各种点鼠标）。做完之后实验现象出来了，不知道为什么成功。实验现象失败了，不知道为何失败。所以后来我做了两件事，第一个先看Seclub网站关于lab的视频，先理解实验。其次做实验的时候尝试对每个步骤进行理解，不论对错，现有总结一个自己的理解，再找人答疑或者纠错。

其次，尽量一个实验有了一些理解之后再做下一个，一股脑全做了就相当于点鼠标，即使当时记住了配置步骤，久而久之也会忘记的。而且点完一遍实验之后因为没去理解可能懒得再回顾了。这种情况觉得做了一次也是白做。

最后，反复多次做，当然条件允许的情况下每个都重复去做最好。在有限的情况下，建议可以把个人觉得最复杂，最难理解的实验反复做，对其中的步骤用法加深理解。

二、Clearpass配置项的理解：

1、关于“服务”：

个人理解，匹配认证流条件，“服务”是用来在对多种认证方式或者同一认证方式下（如portal，802.1x，MAC地址等），根据（包括但不限于）SSID，NAS-ID，用户名是否为mac等信息来匹配一条唯一的radius认证流量（不填则默认匹配所有）。

如需要匹配用户是Portal认证还是802.1x认证等等。又如Portal无感知认证中，需要区分是第一次portal上来的认证流量还是后续的mac认证流。（要注意“匹配项”中选择了“任意”还是“以下所有条件”）

2、关于“认证”：

认证方法：匹配该认证流使用的认证方法，如MAC认证为“MAC AUTH”，802.1X认证为“EAP”等

认证源：匹配认证账号存放的数据库，查找是否存在对认证流量上来的用户名

3、关于“强制执行”：

强制执行中的“配置文件”和“策略”的关系。“配置文件”是想要执行什么动作，“策略”是在什么条件下执行上述“配置文件”的动作。

如在Portal无感知认证中，对用户上来的认证流执行数据库更新动作，使用户mac与用户名绑定，给定用户缓存时间等，这就是“配置文件”中的内容。而“策略”要做的是规定只属某个组的用户名执行这个动作。

三、Portal无感知的实验流程理解

1、流程概述：

用户做无感知认证，实现认证分为两个步骤：第一步用户第一次认证做portal认证，这时用户名和mac将绑定。第二步，用户连接网络，由于mac与用户名绑定，用户允接入网络，此过程用户无感知。

由此clearpass先匹配用户第一次portal认证流，认证成功将用户名和mac等信息做绑定，缓存时间等信息存放在endpoint中。 等终端下次接入时，clearpass匹配匹配用户的mac认证流，匹配到该用户mac在endpoint中绑定了用户名，在缓存时间内等信息时（即满足条件），允许上线，若不匹配则用户需要重新进行portal认证。

2、配置概述

（1）同一个SSID下在“服务”中匹配出portal认证流

（2）“服务”匹配到portal认证流之后，用户允许接入，并且执通过“强制执行”文件对该用户执行更新endpoint数据库动作

（3）同一个SSID下在“服务”中匹配出mac认证流

（4）“服务”匹配到mac认证流之后执行动作，通过“强制执行”中的“策略”匹配第2步用户信息在endpoint数据库更新后的条件，允许接入。

（5）若是第4步“策略”失败，则拒绝用户接入，用户需要重新进行第1步操作。

3、配置详解（以下为阐述个人理解，配置并未按实验文档顺序）

（1）同一个SSID下在“服务”中匹配出Portal认证流

如上图，我们在“服务”中，匹配用户Portal认证流。由于Portal无感知中Portal认证和mac认证使用的是同一个SSID，所以为了区分，我们在“服务”中需做两个条件来匹配：第一个是SSID为我们设定用户无感知连接的SSID，第二个是用户名不等于mac地址。

如上图，我们在“服务 — 认证”中，需要配置认证流的认证方法和认证源数据库。因为控制器终结用户portal认证，和clearpass交互的radius报文采用CHAP、PAP等进行认证所以采用图上认证方法（具体详见radius相关资料）。认证源为local SQL DB，因为配置的用户名存在此数据库中。

（2）“服务”匹配到portal认证流之后，用户允许接入，并且执通过“强制执行”文件对该用户执行更新endpoint数据库动作

如上图，这里是“强制执行-策略”。当匹配到portal认证流之后，我们需要对这个认证流执行一些动作，更新endpoint库。但是在这之前需要先进行筛选，谁能够进行endpoint更新上图是筛选的配置，我们对匹配上来的portal认证流，需要满足两个条件，才进行endpoint更新。第一个是认证使用的用户名属于在clearpass中设置好的属性“guest-role”，第二个是用户名已经在clearpass认证过。这样的话，首先可以针对不同用户名区分是否做无感知，其次未认证过的用户当然不应该直接允许无感知认证了不是。

如上图，这里是“强制执行—配置文件”。继续跟着上述两张图，两个步骤的思路。刚刚我们匹配了唯一的portal认证流，也匹配了portal认证上来的用户谁允许执行无感知（endpoint更新动作）。接下来这里便是我们要执行什么样的动作，才是用户无感知动作。如图我们绑定了mac与用户名（portal认证时），也规定了缓存时间（允许无感知时间），以及用户在clearpass中的属性属于什么role，标识我们已经知道该用户信息等等。如此后续进行mac的用户只有匹配了这些条件才能够进行无感知（此为后话）

（3）同一个SSID下在“服务”中匹配出mac认证流

如上图， 上述我们将portal认证服务配置完，用户第一次连接进行portal认证后，将在endpoint中更新。现在我们需要做的是匹配一条mac认证流。“服务”中，当我们设定匹配了上述SSID以及用户名为MAC地址后，则确认匹配了这条mac认证流。

如上图，“服务—认证”中不做冗述，不同认证，radius报文交互认证方式有区别，注意portal认证与mac认证，认证源不是一个库

如上图，关于“服务—授权”，利用已知的数据库里的信息作为判断条件，比如前面所述，我们对portal认证完的用户进行了数据库的更新，设定了无感知时间，引入了时间数据库，此时需要通过时间数据库判断该用户上次上线时间，是否超期。即前面引用了什么库，后续则需要调用什么库。

（5）“服务”匹配到mac认证流之后执行动作，通过“强制执行”中的“策略”匹配第2步用户信息在endpoint数据库更新后的条件，允许接入。

如上图， 上述我们匹配到了用户的mac认证流，但是并不是所有都能通过认证，此时我们需要在“强制执行—策略”里头，筛选合适用户通过该mac认证，即上述流程中通过了portal认证，在endpoint更新且未超期的用户。匹配的条件如图所示，当mac认证上来的用户，clearpass知道该终端认证过，endpoint中mac与用户名等信息绑定且缓存时间未到，以及用户名在clearpass所属的role-ID是“guest-role”时（这个role-ID属性，在前头portal认证下放的执行文件中给了）。则允许用户通过mac认证。