cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1109
Views
0
Helpful
4
Replies

Two Cisco ISE feature requests

silla
Level 1
Level 1

Hello,

I'd like to share a couple of ideas for features I'd like to see in the next versions of ISE: as far as I know, they are not available, but feel free to correct me if I'm wrong!

 

1) Ability to modify Policy Sets via REST API:  it is already possible to modify lots of things via API (complete list here); however, policy sets cannot be created/modified/deleted via API. This is like having a bathtub full of lego bricks and not being able to play with them!

 

2) Ability to use references to attributes in authorization profiles: that would allow for some pretty neat tricks. Let's suppose, for example, that you want to use the Identity PSK feature of Cisco WLC 8.5; this is a new feature that allows you to set different pre-shared keys for different clients for an SSID using WPA-PSK (see here for an overview). However, if I'm not mistaken, you have to write a new authorization rule and a new authorization profile for every different PSK.

It would be much better, in my opinion, to simply add an attribute to the Endpoints (let's call it ipsk) and reference it in a single authorization profile.

 

Instead of having multiple authorization profiles like these, each with its own authorization rule...

 

Access Type = ACCESS_ACCEPT
cisco-av-pair = psk-mode=ascii
cisco-av-pair = psk=SharedPassword1

 

Access Type = ACCESS_ACCEPT
cisco-av-pair = psk-mode=ascii
cisco-av-pair = psk=SharedPassword2

 

Access Type = ACCESS_ACCEPT
cisco-av-pair = psk-mode=ascii
cisco-av-pair = psk=SharedPassword3

 

You would have a single authorization profile, with a reference to the attribute and a single authorization rule, referencing the "dynamic" authorization profile.

 

Access Type = ACCESS_ACCEPT
cisco-av-pair = psk-mode=ascii
cisco-av-pair = psk=$InternalEndpoint.ipsk

 

This feature would not be strictly necessary if we had feature #1, but would still allow for much more compact authorization rules.

The predefined authorization profile Cisco_WebAuth already has something like that:

 

Access Type = ACCESS_ACCEPT
cisco-av-pair = url-redirect-acl=ACL_WEBAUTH_REDIRECT
cisco-av-pair = url-redirect=https://ip:port/portal/gateway?sessionId=SessionIdValue&portal=404e0f70-2e02-11e8-ba71-005056872c7f&action=cwa

 

The references ip, port and SessionIdValue are populated at runtime.

 

Is there some Cisco overlord out there that can tell us if something like this has ever been considered?

 

Best regards,

Silla

1 Accepted Solution

Accepted Solutions

Hi,

You might have better luck reaching out to Cisco here.

 

In regard to your scenario you mentioned, I previously labbed a similar scenario for management of FlexVPN PSK, normally I'd have created a unique Authorization Profile per VPN peer which can become very tedious. What you can do is create a User Custom Attribute e.g VPN-PSK, then create an Internal ISE user, fill in the string value as your PSK in the custom attribute field VPN-PSK. Create 1 Authorization Profile and define an advanced attribute setting:- Radius:Tunnel-Password = InternalUser:VPN-PSK. You would then use this Authorization Profile in a rule and it would query the defined in the VPN-PSK field under the user/vpn peer being authorized.

 

This may be helpful to you.

View solution in original post

4 Replies 4

Hi,

You might have better luck reaching out to Cisco here.

 

In regard to your scenario you mentioned, I previously labbed a similar scenario for management of FlexVPN PSK, normally I'd have created a unique Authorization Profile per VPN peer which can become very tedious. What you can do is create a User Custom Attribute e.g VPN-PSK, then create an Internal ISE user, fill in the string value as your PSK in the custom attribute field VPN-PSK. Create 1 Authorization Profile and define an advanced attribute setting:- Radius:Tunnel-Password = InternalUser:VPN-PSK. You would then use this Authorization Profile in a rule and it would query the defined in the VPN-PSK field under the user/vpn peer being authorized.

 

This may be helpful to you.

Hello,

thank you very much for your answer!

 

 


What you can do is create a User Custom Attribute e.g VPN-PSK, then create an Internal ISE user, fill in the string value as your PSK in the custom attribute field VPN-PSK. Create 1 Authorization Profile and define an advanced attribute setting:- Radius:Tunnel-Password = InternalUser:VPN-PSK. You would then use this Authorization Profile in a rule and it would query the defined in the VPN-PSK field under the user/vpn peer being authorized.

I've tried doing something very similar using a custom attribute for an endpoint, instead of a user, but I couldn't get it to work. But if it works in your case, maybe I can get it to work in mine!

Best regards,

Silla Rizzoli

I got it to work in my case too! So I guess we already have feature #1, so #2 is not strictly needed...

 

Ciao!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: