如何通过localuser授权

位置:

环境: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。

7+