cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3908
Views
2
Helpful
8
Replies

ISE as RADIUS Proxy and Attribute "Reply-Message"

kaiychen
Cisco Employee
Cisco Employee

HI,

One of our customer would like to use ISE as RADIUS proxy and forward the requests to external RADIUS

(to check username/password against DB and responds with "group" information in "Reply-Message" attribute).

When the response is received by ISE, they want to compare the "Reply-Message" sent by the external RADIUS

with some value and do authorization based on the comparison result.

Our questions are:

1) Is "Reply-Message" attribute supported in ISE Authorization process ? We couldn't find it in the attribute options.

2) If "Reply-Message" it not supported, any way we can achieve it using ISE ? (The setup currently works with 3-rd party RADIUS server).

Is "Continue to authorization policy" setting the way to go ? We know there is RADIUS proxy enhancements in new ISE release but aren't quite sure if it supports the "Reply-Message" attribute.

Please advise or comment. Thanks.

Jim

1 Accepted Solution

Accepted Solutions

Craig Hyps
Level 10
Level 10

Per RFC2865, this attribute is only valid for responses, not requests...

5.44.  Table of Attributes

   The following table provides a guide to which attributes may be found

   in which kinds of packets, and in what quantity.

   Request     Accept     Reject     Challenge     #     Attribute

   0                  0+            0+               0+          18     Reply-Message

To change the "direction" specified for this default System dictionary attribute would require enhancement request, but due to nature, would require ability to override standard dictionary rules.  Another option would be to have customer leverage a different attribute in RADIUS response from external server which has been flagged for "both" directions, i.e. inbound and outbound.

Craig

View solution in original post

8 Replies 8

Craig Hyps
Level 10
Level 10

Per RFC2865, this attribute is only valid for responses, not requests...

5.44.  Table of Attributes

   The following table provides a guide to which attributes may be found

   in which kinds of packets, and in what quantity.

   Request     Accept     Reject     Challenge     #     Attribute

   0                  0+            0+               0+          18     Reply-Message

To change the "direction" specified for this default System dictionary attribute would require enhancement request, but due to nature, would require ability to override standard dictionary rules.  Another option would be to have customer leverage a different attribute in RADIUS response from external server which has been flagged for "both" directions, i.e. inbound and outbound.

Craig

Isn't the external radius server in this case following the rfc? It appears to be responding with an accept which includes the reply message. Seems to conform to the rfc.

Warning: I either dictated this to my device, or typed it with my thumbs. Erroneous words are a feature, not a typo.

Correct.  The external server is using it in a response, but the ask is to now to have ISE interpret the response as an INBOUND attribute in order to allow Authorization Policy matching.  This capability would require dictionary change.

Is the remote Radius server defined as a RADIUS Token server in ISE?  If yes, then the answer is simple.  The remote server will have to reply with a Cisco AVPair   ACS:<whatever_attr_name_you_want> - and then you define that under RADIUS Token Identity Sources 'Authorization'.  You will have the <whatever_attr_name_you_want> available in your AuthZ policies.  If you don't use a custom name, then ISE defaults to CiscoSecure-Group-Id.

That means your external radius server needs to return a Cisco AVPair that looks like this (the User is in GroupXYZ) - you can't use anything other than a CiscoAVPair containing ACS...

Cisco-AVPair = 'ACS:CiscoSecure-Group-Id=GroupXYZ'

If your ISE 'RADIUS Token server' definition is called 'MyExtRadius' then create a new Rule, containing a new Condition (using policy Condition 'Advance Option) and select the attribute from the 'MyExtRadius' dictionary. Your AuthZ policy rule looks something like

If MyExtRadius:CiscoSecure-Group-Id EQUALS blah then <Permissions>

Hi Arne,

Thanks for the information and detail instructions.

We will try it out to see if it helps in our case. Appreciate the input and help.

Jim

Hi Arne,

We have same issue for ISE and FreeRadius Server.

We try the "RADIUS Token" with freeradius. It's work. The ISE RADIUS log can see the attribute  "CiscoSecure-Group-Id = GroupXYZ'.

But I have other issue, RADIUS Token only support EAP-GTC.  So, when I use the iPhone auth method is PEAP (EAP-MSCHAPv2), the authentication method is no supported.

If use the External Radius proxy, the Authentication is pass for windows NB and iPhone.

We try add the attribute in freeRadius users file, but the ISE Radius log can't see anyone attribute value.

Our question is which one attribute support freeradius reply value to ISE?

eq:

aa05 Cleartext-Password := "qazxsw"

        service-type = NAS-Prompt-User,

        Cisco-AVPair = "ACS:Campus-GroupInfo=GroupXYZ"

#

aa06 Cleartext-Password := "qazxsw"

        Filter-ID = GroupXYZ

#

aa07 Auth-Type := EAP,Cleartext-Password := "qazxsw"

        Service-Type = Framed-User,

        Tunnel-Type = 13,

        Tunnel-Medium-Type = 6,

        Tunnel-Private-Group-ID := "GroupXYZ"

Jimmy

IOS devices do support PEAP(GTC). However, you have no way of selecting it on the client. You have to modify Allowed Protocols authentication result to only allow GTC.

Apple tries to make it easier for users to use their devices, so they don't let you choose the authentication scheme.

This can be exploited like shown in this video: Stealing 802.1x Credentials with Rogue AP & RADIUS server - YouTube

Hi Craig,

Thanks for the clarification and suggestion. It helps.

Jim