cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

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.

1935
Views
25
Helpful
8
Replies
Highlighted

Use Cases for various RADIUS Attributes in Cisco ISE

I have been trying to study Cisco ISE for quite sometime.I have come to a observation that only specific RADIUS attributes are being used in authentication and authorization policies in multiple use cases.They are 

  • Normalised Radius·RadiusFlowType
  • Normalised Radius·SSID
  • Radius·Called-Station-ID
  • Radius·Called-Station-ID 

Can I get to know about any use cases where attributes like 

  • Callback-number
  • Connect-Info
  • Error Cause
  • Digest Response
  • Login
  • LAT
  • NAS(Port,ID.Type.Limit)
  • Service-type
  • Tunnel....
  • Vendor specific

are being used.

I have come across a RFC explaining attributes but it is not much helpful. I would be grateful if someone points out how to use those attributes with Cisco ISE.

 

 

 

Regards.

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted
Cisco Employee

Highlighted
Rising star

When it comes to RADIUS attributes, the common ones that you listed are used in most policies for processing the incoming request.  For example, a policy set that is specific to the "Guest" SSID would look at the "called-station-id" attribute and match on the SSID name.

You will use more RADIUS attributes in your authorization profiles to push down specific settings after authentication is complete.  For example, setting the ASA VPN group policy by using the Cisco "Class" attribute.  Or assigning the specific interface you want a wireless client to be dumped onto ("airespace-interface-name").  Most of the common ones are already defined as selectable fields in the authorization profiles.  For example, "ASA VPN" is actually using the "Class" attribute.  And dynamic VLAN assignment uses a couple of attributes.  You can see the details at the bottom of your authorization profile when you are creating it.  It is very rare to need to use anything else beyond what ISE provides.

If you are curious as to what attributes you can use in your policies for your specific environment, just go to RADIUS Live Logs and pick an entry.  Click on the details icon.  You will see the authentication details and it basically shows you everything that was presented by the endpoint.  If you see a specific attribute there that you want to use in your policies, try it out.  If you test and are not hitting your rule, check the details of the endpoint again and make sure the attribute is there.

Also, keep in mind that RADIUS has a lot of attributes defined in the RFC's; however, that doesn't mean vendors will use them all or even stick to what the RFC says.  Vendors will use what they want/need and that's it.  When working with ISE policies, think of your use cases first, without diving into the technical details of attributes.  Then make your policy as simple as possible to achieve your desired use cases.  The more complex your policy is, the harder it is to troubleshoot and the more room for error or differences across vendors.

View solution in original post

8 REPLIES 8
Highlighted

Hi Raj,

 

Have you checked this RADIUS Attributes Overview and RADIUS IETF Attributes

Regards,
Sathiyanarayanan Ravindran

Please rate the post and accept as solution, if my response satisfied your question:)
Highlighted

Yes I have but I don't find it helpful.

Highlighted
Cisco Employee

Highlighted
Rising star

When it comes to RADIUS attributes, the common ones that you listed are used in most policies for processing the incoming request.  For example, a policy set that is specific to the "Guest" SSID would look at the "called-station-id" attribute and match on the SSID name.

You will use more RADIUS attributes in your authorization profiles to push down specific settings after authentication is complete.  For example, setting the ASA VPN group policy by using the Cisco "Class" attribute.  Or assigning the specific interface you want a wireless client to be dumped onto ("airespace-interface-name").  Most of the common ones are already defined as selectable fields in the authorization profiles.  For example, "ASA VPN" is actually using the "Class" attribute.  And dynamic VLAN assignment uses a couple of attributes.  You can see the details at the bottom of your authorization profile when you are creating it.  It is very rare to need to use anything else beyond what ISE provides.

If you are curious as to what attributes you can use in your policies for your specific environment, just go to RADIUS Live Logs and pick an entry.  Click on the details icon.  You will see the authentication details and it basically shows you everything that was presented by the endpoint.  If you see a specific attribute there that you want to use in your policies, try it out.  If you test and are not hitting your rule, check the details of the endpoint again and make sure the attribute is there.

Also, keep in mind that RADIUS has a lot of attributes defined in the RFC's; however, that doesn't mean vendors will use them all or even stick to what the RFC says.  Vendors will use what they want/need and that's it.  When working with ISE policies, think of your use cases first, without diving into the technical details of attributes.  Then make your policy as simple as possible to achieve your desired use cases.  The more complex your policy is, the harder it is to troubleshoot and the more room for error or differences across vendors.

View solution in original post

Highlighted

Great reply from @Colby LeMaire  - I would add to this that tcpdump is your friend here.  Enable it and perform some authentications with various types of NAS's and you'll get an idea of what is going on.  For Cisco routers/switches there are many additional radius attributes that need to be manually specified in the IOS config - that means there is no "default IOS" behaviour.  It all depends on what that NAS is configured to send.

There should be some RFC2865 conformance in terms of minimum attributes that constitute a valid request (e.g. sending an Access-Request requires at least a User-Name etc.)

 

Example snippet From RFC2865 ...

An Access-Request SHOULD contain a User-Name attribute. It MUST contain either a NAS-IP-Address attribute or a NAS-Identifier attribute (or both). An Access-Request MUST contain either a User-Password or a CHAP- Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password. An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type attribute or both unless the type of access being requested does not involve a port or the NAS does not distinguish among its ports.

And then other representations like this

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-1       0-1      0        0            1   User-Name
   0-1       0        0        0            2   User-Password [Note 1]
   0-1       0        0        0            3   CHAP-Password [Note 1]
   0-1       0        0        0            4   NAS-IP-Address [Note 2]
   0-1       0        0        0            5   NAS-Port
   0-1       0-1      0        0            6   Service-Type
   0-1       0-1      0        0            7   Framed-Protocol
   0-1       0-1      0        0            8   Framed-IP-Address
   0-1       0-1      0        0            9   Framed-IP-Netmask
   0         0-1      0        0           10   Framed-Routing
   0         0+       0        0           11   Filter-Id
   0-1       0-1      0        0           12   Framed-MTU
   0+        0+       0        0           13   Framed-Compression
   0+        0+       0        0           14   Login-IP-Host
Highlighted

What is the difference between an ISE normalized radius attribute vs an ISE radius attribute?

Highlighted

Hi @Maurice Ball 

 

A Normalised RADIUS attribute in ISE is a convenient abstraction that allows us to use a common attribute in our Policy Set Logic in a multi-vendor environment. E.g. if you have a mix of Cisco and Aruba WLC's, then you can either do it the hard way, by checking for the vendor specific attributes used, e.g. Cisco uses attribute Called-Station-ID for the SSID, and Aruba uses Aruba-Essid-Name.  Perhaps a bad example, because I am no Aruba guru ;-) - but you get the point. There are other instances where vendor A signals a MAB Auth request with Service-Type = "Call-Check" and another vendor uses Service-Type = "Blah".  Cisco ISE has multi-vendor support, and as long as you set the NAS with the correct Device Vendor Type ("Device Profile") then ISE does the internal mapping for you. Then you can use abstractions like Normalised Radius SSID which is vendor agnostic. You no longer need to care how it works under the hood.

Other abstractions are things like the Compound Conditions like Wireless_8021X and Wired_802.1X - have a look at those in detail and you can see that each vendor does it slightly differently.

 

ISE-conditions.PNG

 

 

Highlighted

Great answer. Thanks for the help.