Hello,
Thanks for your detailed response!
The switch doesn't need a host certificate for PEAP. A server certificate on the server side is sufficient. That means installing the root CA as a trusted anchor should be sufficient on the switch side.
I had a little time to have a look. It looks like the second Access-Challenge from the RADIUS server (where the things break) should be containing TLS handshake messages sent from NPS to the switch. This are Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done. Maybe you could verify if it is the same in your case?
Could you please try to capture the RADIUS packets exchanged between switch and NPS in the problem episode? Then please open the capture in Wireshark and select the second Access-Challenge. Extend RADIUS protocol -> Attribute-Value Pairs, Extend the EAP message which is marked as the Last Segment, then Extensible Authentication Protocol ->Secure Socket Layer -> TLSv1.2 Record Layer. Extend the section Handshake Protocol: Certificate.
Please check in this section if the RADIUS NPS is sending the expected certificate to the switch. Extend Certificates ->Certificate, here you can see the details of the sent certificate like common name etc.
Extend signedCertificate for more details. Under extensions you can find if there is a BasicContraints.
If you see a different certificate maybe you can check if the Connection Request Policy in NPS is overriding the settings of the Network Access Policy.
Please also the next time when you test enable some additional switch debugging commands.
debug security radius-server
debug security login-attempts
debug security crypto
debug security ssl
------------------------------
Emil Gogushev
------------------------------
Original Message:
Sent: May 12, 2022 09:59 AM
From: Riku Pessinen
Subject: Aruba 2530/2540 Management Radius PEAP-MSCHAPv2
NPS is configured correctly with Protected EAP (PEAP) and a certificate in this network policy. We are also using PEAP in Wifi access network policy, so problem should not be on the server side.
I cannot find any instructions how to configure PEAP-MSCHAPv2 radius authentication for management connection. I tried to include CA certificate in ta-profile and I created a certificate for the switch, but it made no difference.
Aruba-2540-24G-PoEP-4SFPP(config)# show crypto pki local-certificate
Name Usage Expiration Parent / Profile
-------------------- ------------- -------------- --------------------
CN88JYK1F4 All 2025/05/12 AD-2-CA
CA certificate has Basic Constraits:
Subject Type=CA
Path Length Constraint=None
But not the server certificate used on NPS.
Original Message:
Sent: May 12, 2022 07:43 AM
From: Emil Gogushev
Subject: Aruba 2530/2540 Management Radius PEAP-MSCHAPv2
Hello,
If the RADIUS authentication stops after the second Access Challenge then I suspect that the issue may be either due to authentication method negotiation failing between switch and NPS or a certificate issue.
Please make sure that you have configured a NPS network policy with the correct Authentication Method in Properties -> Contrains. It should be Microsoft: Protected EAP(PEAP).
When you are adding this method you should be prompted to select a certificate the server should use to prove its identity to the client. You can also modify this setting if you select the EAP type Microsoft: Protected EAP(PEAP) and click on Edit. Make also sure that the selected certiticate doesnt have a BasisConstrait on CA. And of course it should be a valid certificate (not expired). Since this is PEAP the server certificate is inevitable.
------------------------------
Emil Gogushev
Original Message:
Sent: May 10, 2022 07:27 AM
From: Riku Pessinen
Subject: Aruba 2530/2540 Management Radius PEAP-MSCHAPv2
I have Aruba 2530/2540 switches with software YC.16.07 - YC.16.10 tracks. I have tried to configure radius authentication with peap-mschapv2 support, but for some reason switch fails the authentication after second access-challenge message sent by the radius server (Microsoft NPS 2019).
I have only found that timestamp could affect this, but NTP is in use and switch and NPS logs have max. 10s difference in timestamps. Could this have an impact on this?
PAP works well, below are logs for both PAP and peap-mschapv2. 1.1.1.1 is source PC, 2.2.2.2 is NPS and 3.3.3.3 is Aruba switch.
PAP:
0355:23:58:29.64 LOGA tSsh0:user_login_lookup: name='username' addr=1.1.1.1
priv=noauth status=SUCCESS
0355:23:58:35.00 RAD mRadiusCtrl:Received RADIUS MSG: AUTH REQUEST, session:
29, access method: SSH.
0355:23:58:35.00 LOGA mSshAlrm:user_login_lookup: name='username'
addr=1.1.1.1 priv=noauth status=SUCCESS
0355:23:58:35.00 RAD mRadiusCtrl:Received RADIUS MSG: DATA, session: 29.
0355:23:58:35.00 RAD mRadiusCtrl:Received RADIUS MSG: DATA, session: 29.
0355:23:58:35.00 RAD mRadiusCtrl:ACCESS REQUEST id: 28 to 2.2.2.2 session:
29, access method: SSH, User-Name: username, Calling-Station-Id: 1.1.1.1,
NAS-IP-Address: 3.3.3.3.
0355:23:58:35.17 RAD tRadiusR:ACCESS ACCEPT id: 28 from 2.2.2.2 received.
0355:23:58:35.17 LOGA tRadiusR:user_login_lookup: name='username'
addr=1.1.1.1 priv=manager status=SUCCESS
0355:23:58:35.17 RAD tRadiusR:Removing RADIUS REQUEST id: 28 from queue.
0355:23:58:35.18 LOGA tSsh0:user_login_lookup: name='username' addr=1.1.1.1
priv=manager status=SUCCESS
PEAP:
0356:00:12:54.46 LOGA tSsh0:user_login_lookup: name='username' addr=1.1.1.1
priv=noauth status=SUCCESS
0356:00:12:57.61 RAD mRadiusCtrl:Received RADIUS MSG: AUTH REQUEST, session:
33, access method: SSH.
0356:00:12:57.61 LOGA mSshAlrm:user_login_lookup: name='username'
addr=1.1.1.1 priv=noauth status=SUCCESS
0356:00:12:57.61 RAD mRadiusCtrl:Received RADIUS MSG: DATA, session: 33.
0356:00:12:57.61 RAD mRadiusCtrl:Received RADIUS MSG: DATA, session: 33.
0356:00:12:57.61 RAD mRadiusCtrl:ACCESS REQUEST id: 44 to 2.2.2.2 session:
33, access method: SSH, User-Name: username, Calling-Station-Id: 1.1.1.1,
NAS-IP-Address: 3.3.3.3.
0356:00:12:57.79 RAD tRadiusR:ACCESS CHALLENGE id: 44 from 2.2.2.2 received.
0356:00:12:57.80 RAD tRadiusR:ACCESS REQUEST id: 45 to 2.2.2.2 session: 33,
access method: SSH, User-Name: username, Calling-Station-Id: 1.1.1.1,
NAS-IP-Address: 3.3.3.3.
0356:00:12:57.98 RAD tRadiusR:ACCESS CHALLENGE id: 45 from 2.2.2.2 received.
0356:00:12:57.98 LOGA tRadiusR:user_login_lookup: name='username'
addr=1.1.1.1 priv=none status=FAILURE
0356:00:12:57.98 RAD tRadiusR:Removing RADIUS REQUEST id: 45 from queue.
Related switch config:
sntp unicast
sntp server priority 1 x.x.x.x
sntp server priority 2 y.y.y.y
radius-server host 2.2.2.2 key abcde
aaa server-group radius "NPS" host 2.2.2.2
aaa authentication login privilege-mode
aaa authentication ssh login peap-mschapv2 server-group NPS local
aaa authentication ssh enable peap-mschapv2 server-group NPS local