环境：Clearpass 6.7, ArubaOS 8.5

需求：

1. 直接采用localuser来认证，可以直接利用localuser的属性来实现授权。

2. 比较特殊一种，本文主要记录的：客户需求认证源采用AD的账号密码，但是授权不想改动AD，这时候也可以采用localuser的属性来实现授权。

这两种有什么区别呢？比如，AD上也有一个user1，在localuser也创建了一个user1，并且赋予一些授权属性：

Department:xx-VPN

Department:xx-TEST

实现第一种需求：直接采用localuser来作为认证和授权

测试发现，如果你直接用localuser来认证可以在认证请求里面的computer属性找到localuser的department属性，比如下面的截图可以看到Authentication Source是Local的，展开Computer属性就可以直接读取到该localuser的Department属性，通过该属性来实现Role Mapping或者Enforcement Policy的策略。

实现第二种需求：认证的账号密码来自于AD，通过Localuser的属性来授权

（测试发现，如果认证来自于AD，Computer属性无法直接读取Localuser的属性，这时候我们就需要在Localuser的授权源里做一些手脚，让这两个数据库关联起来就可以实现：AD认证、Local授权）

先看一下认证源是AD的Computer属性：

还是一样的环境，只是换了认证源，因为认证是在AD上的，我们需要把本地的user关联起来！

默认的授权源Authorization:[Local User Repository]只能看到两个属性Role_Name和Enable状态：

实际上，你采用了默认的授权源Authorization:[Local User Repository]就已经把AD和localuser两个表关联起来了，只是默认的授权属性还不够，我们稍微修改一下这个授权源就可以了。

打开Source的编辑页面，展开[Local User Repository]，在Attribute下增加一个新的filter即可：

然后再新建一个Role-mapping或者Enforcement Policy来调用它：

效果：

简单总结一下思路：

1. 因为认证是在AD上，所以本地创建的user1默认情况是不会有关联的。

2. 因为Radius认证和授权是分开做的，所以可以在Clearpass认证完成后，调用授权来实现授权的目的。

3. 最关键一步就是如何把AD和本地的账号关联起来？这里就是在本地授权源新增一个SQL语句：WHERE user_id = ‘%{Authentication:Username}’把本地的user_id和认证的Username关联起来。

4. 通过SELECT把这个user_id的属性查出来，这样就可以实现根据属性授权了。

5. 直接 SELECT 表tips_auth_local_users的属性，会是一个JOSN格式并且包含了所有的属性，如果希望仅显示Department的属性，可以通过attributes ->> ‘Department’ AS Dep 把仅包含 ‘Department’的属性查出来。

6. AS 就是把SQL查出来的Column Name换一个别名。

7. 不要用 insightdb 里面的，因为这个可能不全，而且有过期的可能，要用tips_auth_local_users，这个数据库会同步到Cluster。