Radio PTP 670 - Cisco ISE as Radius Server

Products PTP
1

Hello,

We are curently remplacing our old Cisco ACS by a Cisco ISE. 

Unfortunately, it’s not working as expected as the radius attribute is not well interpreted by the Radio.

Can you please confirm us if ISE is fully support as RADIUS server by Cambium (especialy PTP devices) ?

Thank you.

2

Hi,

We haven't checked the integration of PTP 670 with ISE.

PTP 670 is compatible with the standard RADIUS protocol, but ISE is a supremely flexible and sophisticated product, and it's not surprising that it is difficult to configure.

If you are able to capture the RADIUS interactions using WireShark, we'd be happy to take a look at the traces.

Mark

3

Hi Mark,

Thank you for your response. I have an open  ticket with the support  (159215) with a wireshark capture attached.

I cannot attach the capture here as .pcap is not accepted.

Thanks,

4

Here is a screenshot with the dictionnary added to wireshark.

5

Can you check what message is left in the local syslog when you attempt to login using RADIUS please?

6

Here is the syslog message. I'm not an expert with Cambium. Can I run debug commands to see more detail ?

The authentication works but the authorization does't.

Also, I see a significant fixe for ISE authentication on cnMaestro. May be something related.

CNSSNG-8385

Cisco ISE support for RADIUS Authentication.

https://community.cambiumnetworks.com/t5/cnMaestro/cnMaestro-1-6-3-Release-On-Premises-and-Cloud/td-p/89666

7

There are no debug commands on PTP 670 that will show you more detail.

Looking at the Wireshark and Syslog, things look okay. Is the user logged in at the end of the protocol exchange?

If so, is he/she logged in with Security Officer permissions?

Mark

8

Yes the user is logged but in read-only.

Actually not matter which attribute is send (1,2 or 3) the user is always logged as Read-Only user as if the attribute was not well received by the radio.

9

The Cambium vendor-specific attribute (VSA) in the Access Accept message from Cisco ISE appears to be correctly formatted in the PCAP provided, and identical to the VSA when we use Free RADIUS. At the moment, it is not clear why the VSA does not have the expected effect when the message is generated in ISE. We are investigating further, and will provide an update here when we have some answers.

1 Like
10

Thank you Mark.

I will wait for your answers.

Thanks,

11

We have a solution to this problem. It will be fixed in System Release 670-02-65.

The problem arises because ISE sends a State (type 24) TLV with a 65 byte variable. 670-02-60 expects a variable up to 64 bytes. In 670-02-65, we have extended the maximum size to 128 bytes.

1 Like
12

Thank you Mark !

13

You're welcome.

The changes in 670-02-65 will ensure that you can use the Cisco ISE with PTP 670. We plan to include the same fix in PTP 650 in a future release. We expect that the same problem will arise in PTP 300/500/600/800 and here we don't have an opportunity for a bug fix.

It would be good to know if the ISE can be configured to avoid sending the State attribute, or at least to send a value that is not more than 64 bytes? Do you have any experience here?

14

I asked the question to Cisco, I'm waiting for their answer on this point.

I will let you know.

15

Hi Mark,

Here is the answer from Cisco 

I understand that you are interested in removing the State attribute (24) from the Radius Access-accept packet and I will do my best to help you. Unfortunately we can't disable the default radius attributes. However, there is a workaround that you may find suitable. The State attribute in Radius  is applicable only to CHAP challenges. I went through the packet capture you provided and I noticed that you are using MS-CHAP2. With this in mind, you can avoid including the State attribute in the packets simply by using a different type of protocol than CHAP. Please, refer to the following document, Table 32 RADIUS IETF Attributes (continued) https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfrdat1.pdf

1 Like
16

Hi,

I'm a bit puzzled by the Cisco response. In the table referenced, we have this:

State - Allows state information to be maintained between the network access server and the RADIUS server. This attribute is applicable only to CHAP challenges.

As they point out, we are using MS-CHAPv2 here. I guess they are saying that MS-CHAPv2 is a variant of CHAP, so the State attribute is included with MS-CHAPv2 just like plain old CHAP. In this case, it appears that there is no solution available by configuring the ISE server.

670-02-65 has been released with this as a bug fix, so at least the problem should have been solved for PTP 670.