Ruijie Community

Title: RADIUS ACL Override on WS6512 [Print this page]

Author: liujunhui1@ruij Time: 2024-5-17 13:47
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,

Author: alexey.savkin1@ Time: 2024-5-17 22:10
Edited by Alexey Savkin at 2024-5-17 22:19

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.

Author: liujunhui1@ruij Time: 2024-5-20 15:09

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

Author: alexey.savkin1@ Time: 2024-5-20 21:33

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

Welcome to Ruijie Community (https://community.ruijienetworks.com/)