RADIUS ACL Override on WS6512

Dear experts!
Does any body know is there a possibility to apply ACL (locally configured on AC or downloadable ACL, doesn't matter) by RADIUS Authorization results, i.e. apply ACL  that is pointed in Radius ACCESS-ACCEPT packet?
I have tried both variants:

• locally configured Extended ACL on AC, and point its name in radius:Filter-ID attribute
• downloadable ACL configured on RADIUS server side, like on Cisco or Huawei products
  

• In case of local ACL, controller does not apply it, and looks like it just ignored Filter-ID attribute:
• In case of dACL all much interesting: I have uses Cisco-style dACL, I see the corresponding vendor-specific attribute in ACCESS-ACCEPT. Moreover, controller recognizes it, and answers with new request for getting this ACL. The problem is that in a new ACCESS-REQUEST there is no mandatory Message-Authenticator attribute, and Radius-server rejects this request (sending ACCESS-REJECT with the reason "11024 The Access-Request for the requested dACL is missing a Message-Authenticator attribute. The request is rejected
  ")
  

So, the QUESTION: how I can apply per-user ACL by the radius authentication result in 802.1x wireless network?

GTAC-Ross replied at 2024-5-20 15:09
Dear sir

1.For the first method, the AC locally configures the extended ACL and specifies the ACL ...

Dear Ross!!

OK, #1 is working perfectly!! Thank you very much, it is enough for me! We can mark this topic as "solved'!

Best regards,
Alexey

Alexey Savkin replied at 2024-5-17 22:10
GTAC-Ross replied at 2024-5-17 13:47
Dear sir

Dear sir

1.For the first method, the AC locally configures the extended ACL and specifies the ACL name to be changed in the Filter-ID attribute. After packet capture, it is found that the AC does not apply this attribute
A policy needs to configur on the device. The server delivers the policy name through attribute 11
you may refer to this configuration

2.For the second method, our device is not suitable for Cisco dacl, so it cannot be implemented at present
Best regards,
Ross

Dear sir

May I confirm the current issue is 802.1x authenticaiton
on the device was rejected?
if so, you can check this configuration refer to this link
https://community.ruijienetworks.com/forum.php?mod=viewthread&tid=5071&extra=page%3D1

May I know mode details about this alarm?
coz we didn't find the similar alarm on WS6816

Best regards,

GTAC-Ross replied at 2024-5-17 13:47
Dear sir

May I confirm the current issue is 802.1x authenticaiton

First of all, my device is Access Controller RG-WS6512
Second, the problem is not with 802.1x authentication, it works just fine. The problem with getting/downloading ACL from RADIUS server after successful 802.1x auth (again, look at the topic and initial question more carefully, all described above).
Let me try to explain one more time:

• We have:
  
  • Ruijie Controller WS6512 + several Access Points in fit mode (AP840-I + AP880-AR)
  • Cisco ISE acts as RADIUS server
    
• What we need:
  
  • On the controller: enterprise SSID (i.e. 802.1x SSID) with authentication on Cisco ISE (aka RADIUS server) is configured
  • On Cisco ISE (i.e. RADIUS server): there are several dACLs (Downloadable Access Lists) that must be implemented for particular user during final phase of authorization. Several politics configured for sending particular dACL while particular user is authorizing
    
• How it must act:
  
  • In case of successful authorization, Cisco ISE (RADIUS server) must include vendor-specific (26) attribute with dACL name into final ACCESS-ACCEPT packet destined to controller (authenticator)
  • Controller, when receives and recognizes dACL name, must send a new ACCESS-REQUEST packet to Cisco ISE (RADIUS server) with the dACL name (into attribute User-Name), for getting full dACL
  • Cisco ISE (RADIUS server), when receives new request from controller, must send full dACL to controller into a new ACCESS-ACCEPT packet(s)
  • Controller, when receives dACL, must apply it to particular wireless user
    
• How it acts now:
  
  • Cisco ISE (RADIUS server) successfully includes vendor-specific (26) attribute with dACL name into final ACCESS-ACCEPT packet destined to controller (authenticator). Please, find second ACCESS-ACCEPT screenshoot in my initial post
    
    
  • Controller sends a new ACCESS-REQUEST to Cisco ISE (look at the ACCESS-REQUEST screenshot in my initial post) with dACL name in the Radius-User-Name (as expected), but:
    
    • does not include
      Message-Authenticator attribute that is mandatory
    • does not include vendor-specific attribute "aaa:service=ip_admission"
    • does not include vendor-specific attribute "aaa:event=acl-download"
      
  • Cisco ISE (RADIUS server) receives ACCESS-ACCEPT from the controller, does not find Message-Authenticator attribute (that is mandatory attribute), and rejects it with sending ACCESS-REJECT to controller, with description "11024 The Access-Request for the requested dACL is missing a Message-Authenticator attribute. The request is rejected
    "
    
• What we want:
  to get recommendation how to configure Ruijie Controller for sending all necessary information to RADIUS server for properly requesting ACL while user authentication
  

This algorithm describes Cisco-style procedure of getting dACL from RADIUS. As Ruijie controller tries to request dACL, I assume that is must support this procedure, but now it works a little bit incorrectly. We wants to fix it in our deployment.
Please, let me know if you have any additional questions or misunderstood something from above.