ISE: test-radius user check fails

[tgrundbacher]

The ISE user guides suggest to use a username called 'test-radius' as option to the 'radius-server host' commands. This will cause the respective NAD (a Cat3560 in my case) to make an authentication check on each configured ISE every 60 minutes.

The problem is that every hour I see an authentication failure for this user, but ONLY on my second ISE (I'm running a Standalone HA deployment). Since both hosts should replicate the same user DB, why would it only fail on the second ISE? When I direct end-user login authentications to the second ISE exclusively, they will be passed normally.

See the attached screenshot of the failed authentication attempt for the test-radius user. I've been seeing this with ISE 1.1 as well as 1.1.1.

The relevant config on the switch is:

username test-radius secret 5 <snipped>

radius-server host 172.26.10.35 auth-port 1812 acct-port 1813 test username test-radius key 7 <snipped>

radius-server host 172.26.10.36 auth-port 1812 acct-port 1813 test username test-radius key 7 <snipped>

Questions:

- How can I get rid of that error?

- Is that test-radius option of much use at all in an ISE setup? As far as I could find out, it would be a measure to figure out if the second ISE policy server is running at all as long as the first one hasn't failed.

Thanks for any help.

Toni

[Tarik Admani]

I personally do not user this configuration in my ise deployment. However it should work fine since you have replication turned on. Do you experience any failures from users (or when you use the test aaa ... command?) If so, then try to force a sync up on the nodes and see if that fixes it.

Thanks,

Tarik Admani
*Please rate helpful posts*

[Stephan Spittaler]

Hi Toni,

I believe you do not see any Access-Requests with the 'test-radius' on your primary ISE PDP server at all. The reason is simply that this server is already known as alive due to the regular Access-Requests for user authentication, so there is really no reason for checking its availability.

Obviously this does not explain the behavior why the test request is failing. Anyhow,sniffing the RADIUS request packets from your switch towards the ISE should bring light into the darkness.

• If you are having a switch with software version 12.2X (Test switch: WS-C3560G-48PS, C3560-IPBASEK9-M, 12.2(53)SE2) the encrypted password contained does not match the one that you have locally configured on the switch (You may want to use Wireshark as proof).

• On the other hand, if you are having a switch with software version 15.0X (Test switch: WS-C3560X-48P, C3560E-UNIVERSALK9-M, 15.0(1)SE3) the encrypted password contained does match the one that you have locally configured. Side node: It will not work with an MD5 encrypted password, so you have to use 'username test-radius password '.

However, this whole behavior does not affect user authentication at all and is hence only cosmetic. For the switches itself it only matters if it gets a response from the ISE (RADIUS) to know if it is alive or not.

Hi Tarik,

Testing with the 'test aaa...' command does not result in the 'Authentication Failure', that Toni had mentioned.

Kind regards and hth,

Stephan

*Please rate helpful posts*

[tgrundbacher]

Hi Tarik and Stephan

Thanks for both your replies. Stephan's findings are interesting (though I haven't found time yet to do the sniffing with Wireshark), whereas I can confirm that I'm running it with IOS 12.2(55)SE6 on a Cat3560 (non-X). And yes, 'test aaa...' results in successful authentication attempts towards both policy servers. Just the error remains the same for that hourly check, only popping up for the second policy server.

I'd be fine with the fact that it's just a cosmetic thing if it only was a green entry and not a red one...customers don't like to see red in their logs As I can't upgrade the switching hardware or software right now (12.2 is the latest supported release train for the legacy Cat3560 platform) I guess I have to live with it...

Thank you guys anyway

Toni