cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

6907
Views
26
Helpful
25
Replies
Highlighted
Cisco Employee

ISE as RADIUS proxy to another ISE

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:

Event5405 RADIUS Request dropped
Failure Reason11036 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

25 REPLIES 25
Highlighted

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.

Highlighted

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.

 

Highlighted

 
Highlighted

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.

Highlighted

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

Highlighted

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

 

Highlighted

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

 

 

 

Highlighted

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?

Highlighted

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.

Highlighted

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.

Highlighted

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  

Content for Community-Ad