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.

7170
Views
26
Helpful
25
Replies
martucci
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

2 ACCEPTED SOLUTIONS

Accepted Solutions
Jason Kunst
Cisco Employee

This document has an example of ISE pointing to itself. Could you check this

ISE 1.3-2.0 Sponsor Authorization on Secondary Attributes_v5.pdf

View solution in original post

You can define the attribute to map, but what ISE does is create a new dictionary attribute under the external ID store (similar to what you would expect for the definition of significant attributes for AD/LDAP attribute mapping).

By returning the attribute from Token server in the form cisco-av-pair = ACS:Filter-Id=<value>, you can pass the value to local server as shown in a condition, or as a RADIUS authorization such as Radius:Filter-Id=EXTRADIUS:Filter-Id.

Craig

View solution in original post

25 REPLIES 25
Jason Kunst
Cisco Employee

This document has an example of ISE pointing to itself. Could you check this

ISE 1.3-2.0 Sponsor Authorization on Secondary Attributes_v5.pdf

View solution in original post

Thanks Jason,

I have seen it now and I have configured the second ISE as an external RADIUS, not as a RADIUs token.

Should I try to make it RAIDUs token?

I thought that for proxy need to use external radius

Thanks a lot

Francy

==========================================================

Francesca Martucci – CISSP # 481718

CONSULTING SYSTEMS ENGINEER.SECURITY SALES

UKI

martucci@cisco.com<mailto:martucci@cisco.com>

Phone: +44 20 8824 6984

Mobile: +44 77 47476000

==========================================================

Correct RADIUS Token from what i remember

Thanks Jason,

That made the trick and I can now authenticate successfully, but I have another question.

It seems that I will get a success as long as the MAC that I am requesting to ISE2 is in the internal DB.

I have some MAC inone enpoint group (phones), and some in enother (printr or oher). Can I distinguish?

I tried to sue the below

But does not seem to work as I get a success even if the MAC is not in the Avaya Endpoint group, so the Secure-Group-ID must be something else

Thanks a lot

Maybe you are hitting a default policy on external server which returns simple Access-Accept.

If need to match the RADIUS Token condition provided, make sure the RADIUS Token Server (ISE2) matches a policy where following is returned in authorization profile:   cisco-av-pair = ACS:CiscoSecure-Group-Id=avaya

When using RADIUS Token, the ISE server is specifically looking for cisco av-pair where attribute has ACS: prefix.

RADIUS Proxy should also work. RADIUS secrets must match between originating NAD and Proxy and separately between Proxy and External RADIUS server.  In other words, ISE1 must have NAD defined and ISE2 nus have ISE1 defined, but not required for ISE2 to have info on NAD.

Craig

Hello Craig,

Thanks for the help.

With regards to the RAIDUS proxy, I have double checked multiple times.

I have ISE 1 with ISE2 defined ad RADIUS proxy, and ISE2 with ISE1 defined as NAD. In order to make sure that I have the right key in both, (which is the same for NAD, ISE1 and ISE2), I did write it in notepad and then copied it in all the places in the GUI as key.

On ISE 1 I get no response from ISE2 (so I get the message that no RADIUS is available)

, and on ISE2 I get the following

It looks wrong to me, as I do not think I made a configuration error.

Instead if I use the RADIUS Token, I see an authentication sucees on ISE1, but no message at all on ISE2.

But I hit the right AuthC policy going to ISE2

Not sure if I am doing anything wrong here.

Thanks a lot

Francy

==========================================================

Francesca Martucci – CISSP # 481718

CONSULTING SYSTEMS ENGINEER.SECURITY SALES

UKI

==========================================================

RADIUS Proxy config replaces "Allowed Protocols" selection.  RADIUS Token is configured like other external ID stores.

HI Craig,

Yes, this is what I have done, but still I get the issues that I mentioned.

Do you have some tie to quickly take a look at it by any chance?

We have also a couple of question son profiling if you do not mind

Thanks

Francesca

I ran into the same issue today on my ISE 2.2 lab.  I am migrating an ACS 5.4 deployment to ISE 2.2 and the way that ISE processes the Radius Token server's Access-Accept is quite different 

In ACS it was possible to specify a reply attribute like Filter-Id (11) and then ACS binds its value to an internal attribute that was then used in an AuthZ rule

e.g.

ACS 5.4:

Access-Accept

Filter-Id = 'somestring'

ISE:

Access-Accept

Cisco-AVPair = 'ACS:Filter-Id=somestring'

The problem is that I cannot control the external radius token server to send this new fancy value that ISE expects (with the added twisted irony that it must contain the prefix 'ACS').  The mind boggles.  I couldn't even find this in the official documentation.

Is there any way to get the ACS type behaviour in ISE?  Or do some attribute manipulation on the radius reply to convert the Filter-Id into a CiscoAVPair to make ISE happy?

It’s not totally clear what problem you are experiencing Arne. Are you saying the authz rule isn’t matching the ACS:Filter-Id or that the other radius server doesn’t populate that attribute? Maybe screenshots from 5.4 or pcap version of the radius conversation to help clarify what functionality you are looking for?

If you are simply trying to match “somestring” in the Filter-Id, maybe you can do something like this:

George

If external RADIUS Server is able to return the desired value for Filter-Id, then make sure it is populating value in attribute ACS:CiscoSecure-Group-Id (or whichever attribute you select under the Token Server definition).  Then you can apply directly in ISE in authorization profile as Radius:Filter-Id=RadToken:CiscoSecure-Group-Id  (where RadToken is name assigned to the RADIUS Token Server).

Craig

Hi George

Craig Hyps hit the nail on the head - the difference between ACS and ISE is that ISE has a hard coded expectation of what Radius attribute shall be used to pass into the Policy Condition.

An example from ACS 5.4 below - my customer uses an external radius server to authenticate third party TACACS users, and in the Access-Accept they fish out the TACACS authorization policy conditions using the values found in an IETF Filter-Id.  There is no significance in the reason why Filter-Id was used - it's been running like that for years.

And this is where ACS differs from ISE - ISE does not seem to allow us to do the same thing as below.  ISE has a hard coded expectation of the Radius attribute that can be used to map the Policy Condition.  As chyps pointed out, it MUST be a CiscoAVPair, containing ACS:<somevar>

Filterid-1.PNG

And this is where ACS differs from ISE - ISE does not seem to allow us to do the same thing as below.  ISE has a hard coded expectation of the Radius attribute that can be used to map the Policy Condition.  As pointed out, it MUST be a CiscoAVPair, containing ACS:<somevar> - expressed in ACS, this is what it looks like

Filterid-2.PNG

Unless I am mistaken, there is no way to get this flexibility in ISE.  In ISE 2.2 You can customise the Attribute Name or leave it blank (then ISE defaults to expecting to receive CiscoAVPair ACS:Cisco-Secure-Group-Id)

In my lab I successfully tested as such (I am looking for a value of "Network" in the CiscoAVPair):

ISE1.PNG

ISE2.PNG

The external Radius reply looks something like this:

(0) Sending Access-Accept packet to host 192.168.21.101 port 62525, id=71, length=0

(0)  Cisco-AVPair = 'ACS:Filter-Id=Network'

0) Finished request

You can define the attribute to map, but what ISE does is create a new dictionary attribute under the external ID store (similar to what you would expect for the definition of significant attributes for AD/LDAP attribute mapping).

By returning the attribute from Token server in the form cisco-av-pair = ACS:Filter-Id=<value>, you can pass the value to local server as shown in a condition, or as a RADIUS authorization such as Radius:Filter-Id=EXTRADIUS:Filter-Id.

Craig

View solution in original post

Hi;

Unfortunately, for several days I have been struggling with a similar topic. I have configured ISE as a proxy. Inquiries are sent to the FreeRadius server, which works as a tokenSMS. The scenario is this:

Client> ASA> ISE> FreeRadius (TokenSMS)
FreeRADIS id configured as External Radius Server, not as a RadiusToken
Communication looks like this:

1. acces-request (password)
2. <- access-challenge (session)
3. access-request (pin + session)
4. <- access-accept (session + class)
and then
5.access-request (authorize-only)
6. acces-reject

in ISE logs it looks like this:
(first request .ACCEPT, second is DROPPED) finally, on anyconnect user received Login Failed error

Bez tytułu.png

TCPDUMP on ISE:

126.16.36.100 -ASA

126.16.36.200 -ISE

126.16.18.137 -  FreeRADIUS

 

Bez tytułu2.png

Can anyone help? maybe some tips?  can I attach some additional info?

Content for Community-Ad