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

[Jason Kunst · Accepted solution]

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

[martucci]

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

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

[Jason Kunst]

Correct RADIUS Token from what i remember

[martucci]

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

[Craig Hyps]

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

[martucci]

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

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

[Craig Hyps]

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

[martucci]

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

[Arne Bier]

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?

[gbekmezi-DD]

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

[Craig Hyps]

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

[Arne Bier]

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>

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

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):

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

[Craig Hyps · Accepted solution]

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

[rajczmic]

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

TCPDUMP on ISE:

126.16.36.100 -ASA

126.16.36.200 -ISE

126.16.18.137 -  FreeRADIUS

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