Invalid Message Authenticator in EAP Request

Unanswered Question
Dec 11th, 2007


I am attemping to configure Infratructure authentication for WDS and WPA/PEAP Client authentication using ACS 4.1(1) Build 23 from an Aironet 1210 running IOS 12.3(8)JEC.

I have a production ACS server that has both LEAP and PEAP enabled under the global configuration options.

The access point has been correctly defined as a NAS using RADIUS-Aironet on the ACS server. The Access point has ACS defined as a RADIUS server and the shared secret set the same as the NAS definition within ACS.

For both WDS Infrastructure authentications(LEAP) and client authentication requests to the access point using PEAP I receive the following message in the ACS failed log:

"Invalid message authenticator in EAP request"

A search on CCO tells me that this is normally the result of a shared secret mismatch. I have however retyped the shared secret several times , and tested with simple strings such as "cisco" and the same result is received. Both the Radius definition on the AP and the NAS definition on ACS have bee re-created with no change in result.

As a test I ran up a clean install of ACS 4.1(1)23 in a VMware session. Configured a NAS object for the AP as I had previously done on the production system and it worked first go.

Would anyone have any clues on what could be wrong with my production ACS. ?

Many Thanks,


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
irisrios Tue, 12/18/2007 - 13:34

VMaware would work only if the client adaptor works successfully. I could guess no reason other than wrong key between AP and ACS that could have caused this issue. Nothing specific about the error.

lmslattery Thu, 12/27/2007 - 14:11

I ended up performing a clean install of ACS on another server to get around it.

I still have no idea what the root cause was.

Scott Fella Thu, 12/27/2007 - 18:12

One issue could of been a bad shared secret between the WLC and the ACS.... you would get the same error message that you did.

Scott Fella Thu, 12/27/2007 - 19:27

To be honest.... the cut and paste is the issue. we had to manually type out the shared secret for it to work. This was on the 4.1 code. Type it out on boththe ACS and WLC.

Scott Fella Thu, 12/27/2007 - 19:31

Are you using symbols? try setting the shared secret as something simple like testtest on both and see if that works. If not then it has to be a configuration on the ACS.

I got this resolved today and thought I would pass the workaround along. We opened a TAC case on the WLC and the engineer first suggested that we check the shared secret. Since I'd reset it so many times in so many ways my head almost exploded :-) She also mentioned this:

"We also sometimes see 'strange issues' in ACS if the device is part of a device-group, so if you would remove the WLC from any device group, put it in by itself (not in a group), be sure Aironet or Airespace is chosen for the device-type, & recycle the ACS services.

This turned out to be the solu^H^H^H^Hworkaround. Not sure yet if its in the pipeline to be fixed in ACS. FYI the case number is 607634169.

Scott Fella Fri, 01/04/2008 - 15:56

That is what I mentioned earlier. rule of thumb is to restart ACS when making major changes. Always worked for me.

lmslattery Fri, 01/04/2008 - 16:09

Thinking about it. The ACS I was originally having problem with was also setup for "Device Groups".

Even though I was having this issue with Autonomous AP's rather than WLC's I'd say our problems are related.

Scott Fella Fri, 01/04/2008 - 16:22

Device group doesn't have to be configured if you don't want to. One working and the other not is not very strange for some odd reason. At leats you got it to work.

apishko Fri, 02/01/2008 - 05:26

Just want to thank all for this post. Hae just brought up a new 4.1 install and have been fighting with EAP-FAST authentication off an on for the past day or so (should know by now to look here first). Anyway, I removed the WLC from a device group and it started working.

Premdeep Banga Thu, 08/28/2008 - 03:36

I have a question, when you placed the AAA client under a NDG, was there any Shared Key defined on the NDG level. Because it is an expected behavior, that if you define a Shared Key on the NDG level it over-rides key at the AAA Client level.

Refer to Step4.,

"Each device that is assigned to the Network Device Group will use the shared key that you enter here. The key that was assigned to the device when it was added to the system is ignored. If the key entry is null, the AAA client key is used."



Please rate if it helps!


This Discussion



Trending Topics - Security & Network