Authen session timed out: Challenge not provided by client

Unanswered Question
Mar 11th, 2009
User Badges:

Hi,

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).


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
SJessulat_2 Wed, 03/11/2009 - 06:12
User Badges:

Hi,


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:


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_configuration_example09186a00805e7a18.shtml


Problem


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."

Solution


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.


Greets,

Sebastian

staalebotnen Wed, 03/11/2009 - 06:38
User Badges:

Hi,

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.


Regards

Staale

j.drosyk_2 Mon, 04/27/2009 - 11:28
User Badges:

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?

mgriffit Mon, 09/07/2009 - 05:26
User Badges:

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 4.0.1.27) and the other (alos running 4.0.1.27) stopped working several months ago.

I am currently going through an upgrade to 4.2.0.124 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.

staalebotnen Mon, 09/07/2009 - 22:54
User Badges:

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.

shinosaito Mon, 09/07/2009 - 23:30
User Badges:

Hi,

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.

mgriffit Thu, 09/17/2009 - 02:24
User Badges:

Hello

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.

best regards

Martyn

Jagdeep Gambhir Tue, 09/22/2009 - 08:41
User Badges:
  • Red, 2250 points or more

Martyn,

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 4.2.0.124.12 cumulative patch.'


http://www.cisco.com/cgi-bin/tablebuild.pl/acs-win-3des


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"

turned OFF.

* 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.



Regards,

~JG


Do rate helpful posts


jolicoeur Mon, 10/19/2009 - 08:51
User Badges:

JG


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?

Actions

This Discussion

 

 

Trending Topics - Security & Network