cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
357
Views
0
Helpful
6
Replies

Cisco ISE External Radius modify response

P333EVS1
Frequent Visitor
Frequent Visitor

Hi, wondering if anyone can help.

We have a Cisco ISE deployment. We need to use an external RADIUS server for 1 of our SSIDs.  We want to control what VLAN that user is dropped into, however the external RADIUS is returning a VLAN ID. Normally I would set a statically set VLAN ID on our WLC however for what ever reason when we migrated to our vendors newer platform this is no longer supported.

What I'm thinking is in Cisco ISE > Radius server sequence - I can modify the Attribute before access accept, Which I have done. I've added Aruba-Named-User-VLAN and added what we needed along with updating the user-vlan ID from what is sent from the external radius to what I need it to be. This works because in the radius logs I can see the attributes have been changed. However the WLC is still accepting the External Radius VLAN ID. I think because Tunnel-Private-Group-ID is taking precedence over the Aruba-user-vlan-id.

Annoyingly the Tunnel-Private-Group-ID isnt available as an option in the modify attribute - anyone know if it can be added?

 

P333EVS1_0-1789724141362.png

 

6 Replies 6

aleabrahao
Meraki Community All-Star
Meraki Community All-Star

@P333EVS1 I suspect the WLC is still seeing Tunnel-Private-Group-ID from the external RADIUS response and giving that precedence over the Aruba VSA. Changing Aruba-User-Vlan or Aruba-Named-User-Vlan in the ISE RADIUS Server Sequence won't override the VLAN if Tunnel-Private-Group-ID is still present. Unfortunately, I don't believe ISE allows Tunnel-Private-Group-ID to be modified in the "Modify Attribute before Access-Accept" section. I'd either enable "On Access-Accept, continue to Authorization Policy" and have ISE return its own VLAN attributes via an Authorization Profile, or remove the VLAN attributes from the external RADIUS server altogether. The first thing I'd check is the final Access-Accept in the ISE Live Logs to confirm whether Tunnel-Private-Group-ID is still being sent, as that would explain exactly why the WLC continues to place users into the original VLAN.

I am not a Cisco employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

Ye i think tunnel-private-group-id has a higher preference over an Aruba VSA. I had tried On Access-Accept, continue to Authorization Policy then created my own authorisation profile with the vlan we wanted to use however somehow this still didnt work. 

Even checking the logs the only attribute being sent was Aruba-Named-User-Vlan which was correct. 

Unfortunately we have to point this SSID at an external radius server because we provide a service to another organisations users. In the end we were able to overcome this, I managed to get hold of someone in the external organisation and we applied a filter on the radius access-accept message which prevented the vlan attribute being sent back to any of our NAS IPs. Which seems to have worked. 

Hi

When you tried this, did you specify ISE as the authorization server? It seems strange that it wouldn't work...

Anyways, if it works now I suppose there's no need to do anything else.

What is the external RADIUS? Why are you using an external RADIUS for this SSID? EDURoam? Can you change the configuration of the external RADIUS?

Gagandeep Singh
Cisco Employee
Cisco Employee

The Tunnel-Private-Group-ID attribute (RADIUS attribute 81) is the standard attribute used by Cisco Wireless LAN Controllers (WLC) to assign VLANs dynamically to users. It takes precedence over other VLAN attributes such as Aruba-Named-User-VLAN. This attribute must be included in the RADIUS Access-Accept message with the correct Tunnel-Type (64) set to VLAN (value 13) and Tunnel-Medium-Type (65) set to 802 (value 6) for the WLC to honor the VLAN assignment.

 

Unfortunately, Cisco ISE's "Modify Attribute" feature in the RADIUS server sequence does not provide an option to directly modify or add the Tunnel-Private-Group-ID attribute. This attribute is not available as a modifiable attribute in the ISE GUI's attribute modification list.

 

To control VLAN assignment when using an external RADIUS server that returns a VLAN ID, and when the WLC is still honoring the Tunnel-Private-Group-ID from the external server, you have these options:

• Configure the external RADIUS server to send the desired Tunnel-Private-Group-ID VLAN value directly, since this attribute takes precedence on the WLC.

• If you want to override the external RADIUS server's VLAN assignment in Cisco ISE, you would need to ensure that Cisco ISE sends the Tunnel-Private-Group-ID attribute with the desired VLAN value. However, since this attribute is not available for modification in the ISE RADIUS server sequence, this is not straightforward.

• Alternatively, consider using Cisco ISE as the primary RADIUS server for that SSID, and configure the external RADIUS server as an external identity source or via pxGrid or other integration methods, so that ISE can control the VLAN assignment attributes it sends to the WLC.

• Another approach is to use the AAA override feature on the WLC to accept VLAN assignment from ISE, but this requires ISE to send the correct Tunnel-Private-Group-ID attribute.

If helped, Kudos and rate the solution!!!!

Arne Bier
VIP
VIP

This might potentially be possible with the ISE LUA script support. From what I can see, the only point at which we can trigger a script is prior to the point where the RADIUS attributes are returned to the NAS - that gives you programmatic control over all the attributes in that response.