Use Cases for various RADIUS Attributes in Cisco ISE

[Rajkeen Chamanshaikh]

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.

[Sathiyanarayanan Ravindran]

Hi Raj,

Have you checked this RADIUS Attributes Overview and RADIUS IETF Attributes

[Rajkeen Chamanshaikh]

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

[howon · Accepted solution]

https://community.cisco.com/t5/security-documents/ise-network-access-attributes/ta-p/3616253

Tried to fill in information for well used attributes here.

[Colby LeMaire · Accepted solution]

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.

[Arne Bier]

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

[Maurice Ball]

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

[Arne Bier]

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.

[Maurice Ball]

Great answer. Thanks for the help.