cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
30685
Views
1
Helpful
7
Replies

error "5440 Endpoint abandoned EAP session and started new"

welmjendel
Level 1
Level 1

Hello ,

i faced this error "5440 Endpoint abandoned EAP session and started new"when users try to authoticate to network ( wired 802.1X) with ISE 2.3 .

FYI: before rebooting client machine users can authenticate normaly to the network.

In event manager on windows 10 i have this error: "Unable to identify a user for 802.1X authentication"

any idea please ???

Regards,

1 Accepted Solution

Accepted Solutions

I do advise opening TAC case to assist with troubleshooting, but certainly need to ask if any change to config.  Was it solely an upgrade to ISE 2.3 or other MS update or GPO policy push?  You mention that auth works until reboot, which would imply a change to client software being applied on reboot.

There are also refs to this particular log on MS and other forums such as Why Unable to identify a user for 802.1X authentication (0x50001)?

Check to make sure settings the same on client.  If working under previous version of ISE, check allowed protocol settings to verify config same as prior version.  Could be one of the EAP or TLS negotiation settings/ciphers set after upgrade.

Also make sure that the clients trust the PSN certificate, especially if changed after upgrade.  You can also try setting option on supplicant to not require Trust for Server as a quick test.

/Craig

View solution in original post

7 Replies 7

paul
Level 10
Level 10

Are you running PEAP user or computer?  EAP-TLS? 

Hi,

I'm running peap user.

Get Outlook for iOS<https://aka.ms/o0ukef>

Try doing windows update or look for windows supplicant related bug.

Same issue here.

The system has been working since April,

suddenly Peap started failing authentication with microsoft supplicant (both Win7 and Win10).

Microsoft OS is updated.

I tried with anyconnect NAM on an test endpoints and authentication works.

EAP-TLS authentications are working fine.

Opened a TAC case. This has been the answer.

"

I did a research and I found that there is a problem with windows endpoints. There are starting new session even they have already one.

It is possible to do some test like rollback last windows update and check windows authentication?

As I said we cannot support third party endpoints.

Does customer has licence for NAM module?

Please let me know if there is anything else I can do for you.

"

Correct me if I'm wrong but Cisco states full compatibility with Microsoft Supplicant till it uses standard protocols, so actually it's a Cisco's problem not a Microsoft problem.

Hello,

can you share  the solution from MS.

I do advise opening TAC case to assist with troubleshooting, but certainly need to ask if any change to config.  Was it solely an upgrade to ISE 2.3 or other MS update or GPO policy push?  You mention that auth works until reboot, which would imply a change to client software being applied on reboot.

There are also refs to this particular log on MS and other forums such as Why Unable to identify a user for 802.1X authentication (0x50001)?

Check to make sure settings the same on client.  If working under previous version of ISE, check allowed protocol settings to verify config same as prior version.  Could be one of the EAP or TLS negotiation settings/ciphers set after upgrade.

Also make sure that the clients trust the PSN certificate, especially if changed after upgrade.  You can also try setting option on supplicant to not require Trust for Server as a quick test.

/Craig

We certainly do support the use of standard supplicants.  However, there is a point where TAC may be limited in being able to troubleshoot 3rd-party software or potential defects.  Similarly, I would expect Microsoft support to attempt to troubleshoot connection of their client to Cisco switch, but do not expect them to own comprehensive troubleshooting of Cisco equipment.  Ultimately our goal is to support customer in best possible way and try to go overboard to do so.  If you ever get a response like "it is not our problem", I suggest escalating to TAC Duty Manager so they can either redirect, escalate, or provide clear explanation why there may be a limit in our ability to address specific issue related to 3rd-party vendor hardware/software.

Regards,

Craig