iMC EIA与深信服VSP配合实现用户组下发问题的解决办法

用户接入认证服务器由思科ACS4.0迁移到H3C iMC V7的测试中发现，深信服VSP设备与iMC配合无法实现用户组的下发，而这个功能在VSP与ACS4.0配合时是可以完成的。

无

1、通过抓包分析及与深信服确认，VSP是通过解析服务器通过RADIUS 2号认证接受报文（Access-Accept）中下发的25号标准属性（Class），将该属性的值作为用户组名处理实现的。如下图：

Class属性在RFC2865中的规定：This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported.  The client MUST NOT interpret the attribute locally.

根据RFC的规定，该属性由服务器在2号认证接受报文（Access-Accept）下发给接入设备，接入设备“必须不能”做解析，并“应该”在后续的计费请求（Accounting-Request）报文中原样上传。而VSP设备将该属性的值做了解析，作为用户组来进行了进一步的处理，是不符合RADIUS协议规范的。一旦与之配合使用的RADIUS服务器根据自己的其他业务逻辑（如后续所述的iMC的处理）下发了该属性，而该属性的值并不是VSP需要的用户组信息可能会导致用户上线失败等异常。

ACS4.0没有用户组下发的功能，也没有说明Class属性是与用户组有关系的，其本身各业务流程中没有使用该属性，因此它的自定义属性下发功能可以让用户自己定义该属性的值并在2号报文中下发给设备。

2、iMC目前只提供RADIUS厂商私有属性的用户自定义下发，对于标准属性是不你自定义的。即使iMC支持了标准属性的自定义，也不能自定义Class属性，这是因为在iMC更新的版本的内部流程中已经用了该属性来唯一标识一个在线用户，用于匹配同一个在线用户的认证和计费会话，因此会根据内部业务逻辑在每一次用户认证时都下发一个不同值的该属性给接入设备。

方案一：iMC参考ACS4.0的处理方式进行修改，允许用户自己定义Class属性的值进行下发。

该方案在现场测试版本基础上可以修改，因为这个版本的iMC的内部业务逻辑还没有用到该属性。但由于后续版本为了提高软件的性能和效率对内部业务流程进行了较大的调整和优化，使用了该属性进行会话标识，这个标识的作用贯穿iMC认证业务的整个流程，如果去掉对整体流程影响很大，也会大大降低软件的性能和效率。因此如果在当前测试版本上修改后解决了这个问题，会导致后续无法升级到更新版本。

方案二：VSP修改用于接收下发用户组的属性为私有属性。

因为私有属性完全由各厂商在RFC框架内自主定义，支持私有属性自定义下发的RADIUS服务器种类更多，且使用私有属性符合RADIUS协议规范，不会出现与其他设备/服务器冲突的问题（根据RFC对Class属性的规定，不排除有其他服务器厂商有iMC类似的处理）。修改后VSP可以有更广的适配范围，与iMC适配时只需在iMC上配置私有属性下发策略即可实现VSP用户组功能。

建议采用方案二（VSP修改用于接收下发用户组的属性为私有属性)，实现思路如下：

为保证兼容，VSP在保留目前对Class属性的处理的基础上，增加一个私有属性（该私有属性挂在深信服的Vendor-ID下面，由深信服自己定义属性号、类型、长度、值的格式等）的处理，解析出该私有属性的值，将其作为用户组应用给当前认证用户即可。该新增属性的优先级高于Class属性，即服务器同时下发该私有属性和Class时，以该私有属性为准。如下图所示，将0x002710替换为深信服的Vendor-ID，0x19替换为新定义的私有属性的type，0x313638替换为要下发的用户组名称。