ISE as RADIUS proxy to another ISE

[martucci]

Hello,

I am trying to setup for a PoC an ISE server proxying to an external RADIUS (in my case another ISE instance)

Client -> NAD -> ISE1 -> ISE2

ISE1 is proxying the requests for the NAD and I have added ISE2 as external RADIUS server with its RADIUS sequence

ISE2, has ISE1 added as a NAD (but also the original NAD), and a list of MAC addresses imported statically.

The shared secret is the same for ISE1, ISE2 and NAD.

I keep having errors on ISE2 when receiving the proxied messages from ISE1 sayig that:

Event	5405 RADIUS Request dropped
Failure Reason	11036 The Message-Authenticator RADIUS attribute is invalid
Resolution	Check whether the Shared Secrets on the AAA Client and ISE Server, match. Ensure that the AAA Client and the network device, have no hardware problems or problems with RADIUS compatibility. Also ensure that the network that connects the device to the ISE, has no hardware problems.

I have checked and the Shared secret is the correct one, and I do not believe I have any other problem.

I am not sure what could be the issue.

The 2 ISEs are having full communication

Any hint?

Regards

Francesca

[Cristian Matei]

Hi,

   You would have to look in the FreeRADIUS logs and policies and understand why you get an "Access-Reject" on the authorisation Access-Request.

Regards,

Cristian Matei.

[rajczmic]

Hi Cristian;

I enclose all communication in six steps ( six attachments) Step 5 is to send access-request from ISE to FreeRadius with the Authorize-Only option. Then I received Reject in response.

[rajczmic]

Hi Cristian;

I enclose all communication in six steps .Step 5 is to send access-request from ISE to FreeRadius with the Authorize-Only option. Then I received Reject in response.

[Cristian Matei]

Hi,

   There is something missconfigured on FreeRADIUS and you get Access-Reject, look in those logs and see what you find out.

Regards,

Cristian Matei

[rajczmic]

the problem is that the logs I have attached do not see anything that would indicate a problem. In my opinion, ISE unnecessarily sends the Authorize-Only option to FreeRadius. I have the authorization policy at ISE. What should I change here on the ISE side?

Best Regards

[rajczmic]

in my case, I have an authorization policy at ISE. The question is, should I even send something like this to another Radius?

Packet-Type = Access-Request
        User-Name = "rajczmic"
        NAS-IP-Address = 126.16.36.100
        NAS-Port = 0
        Service-Type = Authorize-Only

then in response I will get Reject

[rajczmic]

Maybe should I configure Freeradius as a RadiusToken server? If so, can I use conditions based on external Radius at the same time in ISE policy?

[PrzemyslawPPazik]

Hi Craig, 

This is a few years old post but still something I'm battling right now with ISE 2.7.
I'm not sure if I understand.
Are your confirming Arne's finding, that attribute received from Radius Token server must be cisco-av-pair=ACS:... 
Or are you saying Radius Token server's Attribute Name can be defined in a way to not expect cisco-av-pair=ACS:...

I have a Radius Token server configured in ISE for Device Admin (T+) with MFA and authentication&authorisation works well. Until I configured my upstream Radius to send a group membership name with the access accept message. That upstream Radius is hard coded to send group name as part of Filter-Id (11). 
So my Radius Token server is configured with Attribute Name:Filter-Id but that doesn't work if I specify group membership as part of the authorisation condition. 

I can see the dictionary being automatically created and it is not referencing any cisco-av-pair=ACS:Filter-Id=...
If I negate the condition, it is not working too and that makes me think ISE is not "seeing" the attribute to judge if it "is" or "is not" and consequently failing. 

btw. packet capture on ISE confirms Filter-Id (11) = ... being sent from Radius Token to ISE. 

I appreciate any suggestions.

[Arne Bier]

Hi Peter

I have not worked on this customer for some years - sorry - it's a bit of a blur to me now. All I can recall is what I last wrote on the Forum about the fact that ISE EXPECTS the mapping token server to use Cisco AVPair ACS:xxxxx where X is Filter-ID 

https://community.cisco.com/t5/network-access-control/ise-as-radius-proxy-to-another-ise/m-p/3507445/highlight/true#M537677

I left that customer project before I had a chance to implement this - it was all still running on the old ACS for that part of the setup. I am sure it would have worked, but I would have had to ask the 3rd party RADIUS vendor (telco) to modify their Access-Accept attribute - well actually, my proposal was to allow interoperability with ACS (so keep the current Attribute Filter-Id) and then add ISE support by additionally returning Cisco AVPair ACS:Filter-ID ... so the telco needed to do some work to allow ISE to function properly - there was no other way. I guess this is where you are stuck?

cheers

Arne

PS: Craig Hyps left Cisco last year or the year before. In general, keep asking in the open forum - you will get a reply for sure.

[PrzemyslawPPazik]

Thanks Arne for answering. 

It is exactly where I'm stuck - Okta Radius is hard coded to provide group membership via Filter-Id (11) but ISE doesn't really like it. 
I have a potential backup plan to differentiate authorisation by AD group membership lookup in authorisation conditions but that means hooking up ISE to more ADs then anyone wants... Anyway, thanks for responding to such old post  

[cisco.13]

hello @PrzemyslawPPazik 

Sorry to repeat this old post, did you solve the ISE/OKTA problem please ?

I opened this post but still no solution : https://community.cisco.com/t5/network-access-control/ise-okta-as-radius-token-server-authorization-group-okta/td-p/4557646

Thank you very much for your help