We have recently upgraded our ACS servers to version 4.1(4) Build 13. After upgrade we receive a lot of error messages in our "Failed Attempts" log of the type:
Authen session timed out: Challenge not provided by client
These started right after the upgrade. But we have had clients with connectivity problems for quite a while before the upgrade, but never any entries like these in our logs. So I'm beginning to suspect that the new ACS is logging more than the old version and that this error message might be the reason our clients have experienced drops in WLAN connection before.
The RADIUS session timeout is identical on both our WLCs and ACS (set to default of 3600). I'm considering disabling the session timeout on both ACS and WLC to see if this will have an affect.
Is there any other reason why these messages would appear?
When I examine the logs on the ACS server I can see that it sends the challenge but never receives an answer from the client. WLAN coverage should be good (radio survey performed and no coverage holes reported in WLC/WCS).
sounds like a different authentication configured on both ends (ACS <-> Client).
What Authentication do you use? Maybe it's just a box you didn't check while configuring the client.
Otherwise, there is a problem with redundant ACS-Servers, when the dead timer on the switches is not configured:
The switch fails to contact the secondary ACS server when the primary ACS server goes down at Dot1x authentication; this error occurs:"Authen session timed out: Challenge not provided by client."
This error occurs when the dead-timer is not configured on the switch, which causes the switch to continue to try the primary server that is down. This causes the authentication to fail. In order to resolve this problem, configure the dead-timer on the switch so that the switch contacts the secondary ACS server after it waits for the configured time (in seconds) or the number of retries to reach the primary server before considers the primary server to be declared dead or unavailable. Now authentication succeeds with the secondary server, which is active. The dead-time can be configured with this command: radius-server dead-criteria [time seconds [tries number] | tries number in global configuration mode.
The client we use are normal XP clients configured to use EAP-TLS to connect to a WPA/TKIP network (configured with 802.1x). All the client have a machine certificate and the ACS servers trusts the issuer of this certificate.
The WLAN is based on Cisco WLC technology and LWAPP APs.
Overall this seems to work very well, but these error messages and reports of some clients disconnecting several times a day has given us cause to investigate.
As far as I understand the dead-timer is only used when you use 802.1x to authenticate clients connecting to a switchport or admin authentication on a switch? The dead-timer does not exist on Cisco 4402 WLC platform.
We have ensured that the session timeout is identical on both WLC and ACS (3600 seconds). Next step would be to disable session timeout completely.
I am experiencing the same exact issue and I plan on opening a TAC case on it now. I have recently upgraded from 4.1(3) build 12 to 4.1(4) build 13 and immediately noticed these error messages coming from our Cisco WLC. I never saw these messages before upgrading to 4.1(4) build 13. I have (2) ACS servers in a redundant architecture for AAA. The WLC knows about both servers, but should only send requests to the secondary if the primary is offline. The only difference that I see is that our XP clients use PEAP instead of EAP-TLS.
Anyone else experiencing these issues?
Yes, I'm also receiving this error.
In our case we are receiving it in association with HOST authentication to Active Directory. We have 2 ACS servers. One is working (running 188.8.131.52) and the other (alos running 184.108.40.206) stopped working several months ago.
I am currently going through an upgrade to 220.127.116.11 hoping that the failing server will right itself, but so far it still isn't working.
Previously we weren't getting any error messages with the failures but since I installed 4.2 at least I'm seeing something happening. If anybody has "fixed" such a problem any feedback or experiences would be most appreciated.
We think that we identified the problem. The locations that show this error message are locations where the users of the WLAN are those small truck things that they use in a warehouse (zipping all about loading stuff). The problem seems to be that the client is roaming to fast between APs. It does not manage to complete the assossiation process with one AP before it has roamed to another AP and lost connection. So far we have been unable to find a way around this issue.
Same logs are senn under WIRED environment.
Our ACS(4.1.13) authenticates wired windows XP clients using IEEE802.1x machine authentication and no wireless clients exist.
The logs may not be so many as the case of wireless client but considerable number of logs are shown in "failed attempt". Additionally, computers seen in these logs are already authenticated or are authenticated just after the failed log appeared. No problem on connection and data transfer.
Any help will be appreciated.
I think I may have discovered what is causing this issue.
I suspect that the error "Authen session timed out: Challenge not provided by client" is related to a certificate negotiation issue between the wireless client and the ACS server.
Will do some further investigations and get back asap.
Please refer to this bug,
Bug was filed: CSCsv04715
Externally found moderate defect: Resolved (R)
Excessive logging with "no challenge provided by client"
Now if you are seeing a lot of this message, but in the same time you have
the clients authenticating --> you are hitting this bug, it is just logging
issue which will not affect the authentication.
To fix it you need to install ACS 18.104.22.168.12 cumulative patch.'
A new checkbox is provided (Extra Logging For Authen-Failure-Code) which
will be 'OFF' by default. When turned 'ON' and if an authentication request
times out ACS will log it into failed attempt report.
* Install Acs with this fix.
* Configure Failed Attempts CSV with "Extra Logging For Authen-Failure-Code"
* Send an authentication request and dont provide a challenge.
* Observe the Failed report CSV to see "Authen session timed out: Challenge
not provided by client" not getting logged.
Do rate helpful posts
Can you cofirm if the cumulative patch resolves any authentication issues or if it just suppresses the "Authentication Failure" messages?
We are receiving the same messages on ACS from WLC. Has anyone figured how to resolve the underlying cause?
Please check the readme file for patch 12. It shows the list of bug that are fixed.
Do rate helpful posts