ISE Alarm : Info : Misconfigured Supplicant Detected with EndpointID

[adamscottmaster2013]

I am running ISE 3.2 patch 4 and I am getting flooded with these messages:

Details :

Misconfigured Supplicant Detected with EndpointID=D4:BE:D9:9A:24:7F from user=host/gamble.mycompany.com

Description :

ISE has detected mis-configured supplicant on the network

Followed by another message:

ISE Alarm : Info : Misconfigured Supplicant Detected with EndpointID=D4:BE:D9:9A:24:7F is fixed.

I get that the first message had to do with this client failing 802.1x but I don't understand why the second message said that it is "fixed" because it is NOT fixed.  I didn't see the second message in ISE version 3.0.  Thoughts?

[Arne Bier]

I'd like to see a good explanation for this from someone else, but I suspect that you have a wired endpoint that is failing 802.1X, but then the same endpoint passes a MAB AuthZ Policy and stays in that state. Is that the case? But you're right, what does it mean "is fixed" ? I have seen this with other events too and wondered where the magic fairy dust came from that fixed it. Probably a badly worded, legacy message in ISE. 

[adamscottmaster2013]

Hi @Arne Bier:  The supplicant fails both dot1x and MAB, then after 120 seconds it said fixed but it is NOT fixed because the supplicant can not connect to the network

[Arne Bier]

Are you running Monitor Mode, Low Impact or Closed Mode?

Maybe you already know all this ...

In Monitor Mode, none of this should matter, because the MAB fallback should have an Access-Accept to authorize the endpoint. You should still see the 802.1X failures - but the user should be none the wiser. You can see in the LiveLogs that 802.1X is failing, but it should not have any impact to the user.

In Low Impact Mode, you ought to not reject the MAB either, but instead, Access-Accept with a restricted dACL (DHCP, DNS, SNMP, PING, and whatever you like - possibly allow traffic to AD as well) . Alternatively, I tend to have an Endpoint Identity Group that I throw endpoints into as a temporary solution to get these endpoints online. You will see the supplicant trying every 120 seconds, but by adding an AuthZ rule to allow this endpoint temporarily, the user will be happy.

In Closed Mode the user would not be a happy camper, unless you had a bypass rule to allow that endpoint on using MAB.

[adamscottmaster2013]

Hi @Arne Bier:  I am running "closed" mode.  That's why users are not happy but that's another story

[adrian.ciubotariu.lacatusu]

Hi @adamscottmaster2013

I have the same Issue with the version 3.2.0.542 Patch 4. 

After the update I made on Saturday we are bombarded with these warnings, even if the clients are authenticated on the network.

Have you by any chance solved the problem?

[adamscottmaster2013]

@adrian.ciubotariu.lacatusu:  Cisco is able to reproduce this issue and confirmed it is a BUG.  No ETA on a fix.   Bug ID is CSCwi43220

[Arne Bier]

@adamscottmaster2013 Thanks for the bug ID - the bug "details" are as vague as ever ... but I wonder if you disabled the Reject Repeated Failed Endpoints option in ISE - would that make the error go away?  I never reject repeated failed endpoints and I don't see this Alarm.

[adamscottmaster2013]

HI @Arne Bier:  I didn't disable the message because I want to see it.  I filtered these messages in splunk syslog.