Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

ISE 1.2 Authentication Failures at First time Connection

Hi,

 I have a trouble with ISE 1.2 when trying to authenticate for first time an end-device, this device might be either a Workstation or IP Phone or Printer,etc. it fails or staying in running mode. The result is the same it can not access the network.  hopefully I'm still in open mode :)

As i described in the beginning everything has status Running or Authz Failed. and after a time of period usually one day finally succeeds.

This happens mostly for workstations and printers, but in case of phones does not have the same behavior. I unplug plug the phones or I shut/ no shut the ports in order to trigger it to succeed. For some phones worked but other obstinately declined.

The phones which are not Cisco phones authenticated with MD5 (a simple username and pass  ) i think the problem should not related with the auth protocol.

Below are some logs from one phone. For me coming to a short conclusion this must be related with the switches which are 3750e (15.02 SE 4 IOS)

or with the same the ISE, why because i have almost the same behavior for all end-devices.

I kindly remain your comments...

-------------------------------------------------------------------------------------------------------------------------------

2169669: Apr 16 18:02:20.573 EEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/35, changed state to up
2169670: Apr 16 18:02:20.783 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3ddf) on Interface Gi1/0/34 AuditSessionID 0A114D0D0000D5E8855C01DE
2169671: Apr 16 18:02:20.791 EEST: %AUTHMGR-7-RESULT: Authentication result 'timeout' from 'dot1x' for client (0080.9f7d.3ddf) on Interface Gi1/0/34 AuditSessionID 0A114D0D0000D5E8855C01DE
S301#
2169672: Apr 16 18:02:20.992 EEST: %AUTHMGR-5-START: Starting 'dot1x' for client (0080.9f7d.3ddf) on Interface Gi1/0/34 AuditSessionID 0A114D0D0000D5F0855DE0EF
2169673: Apr 16 18:02:21.580 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to up
S301#
2169674: Apr 16 18:02:24.289 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to down
S301#
2169675: Apr 16 18:02:25.288 EEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/35, changed state to down
2169676: Apr 16 18:02:26.269 EEST: %AUTHMGR-5-START: Starting 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169677: Apr 16 18:02:26.294 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169678: Apr 16 18:02:26.294 EEST: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169679: Apr 16 18:02:26.303 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169680: Apr 16 18:02:26.303 EEST: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169681: Apr 16 18:02:26.319 EEST: %DOT1X-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169682: Apr 16 18:02:26.319 EEST: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169683: Apr 16 18:02:26.319 EEST: %AUTHMGR-7-FAILOVER: Failing over from 'dot1x' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169684: Apr 16 18:02:26.319 EEST: %AUTHMGR-5-START: Starting 'mab' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169685: Apr 16 18:02:26.328 EEST: %MAB-5-FAIL: Authentication failed for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169686: Apr 16 18:02:26.328 EEST: %AUTHMGR-7-RESULT: Authentication result 'no-response' from 'mab' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169687: Apr 16 18:02:26.328 EEST: %AUTHMGR-7-FAILOVER: Failing over from 'mab' for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
2169688: Apr 16 18:02:26.328 EEST: %AUTHMGR-7-NOMOREMETHODS: Exhausted all authentication methods for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
S301#
2169689: Apr 16 18:02:26.336 EEST: %AUTHMGR-5-FAIL: Authorization failed or unapplied for client (0080.9f7d.3e6f) on Interface Gi1/0/35 AuditSessionID 0A114D0D0000D5F1855DF3BE
S301#
2169690: Apr 16 18:02:27.737 EEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/35, changed state to up
2169691: Apr 16 18:02:28.744 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/35, changed state to up

-------------------------------------------------------------------------------------------------------------------------------------

 

Regards

T.C

 

5 REPLIES
Community Member

You'd need to take a look at

You'd need to take a look at your authentication profile and maybe provide a bit more with regards to what you're trying to accomplish.

 

Both 802.1x and MAB authentication is failing for these clients according to the logs you've provided.  I would be interested to know what protocols you're using with your 802.1x deployment.  I'd also be curious to how you're referencing clients with MAB.

 

There a number of things it could be, but I would check to make sure that my root certificates are trusted both on the client and server.

 

As for the MAB failover what you could do is just make sure the endpoint is in whatever database you're referencing.  Then you'd have to make sure you have an Authorization profile that includes this device.

 

Either way in my opinion there's too many variables out there still.  You should, if possible, post your port config, authentication and authorization profiles.

 

Community Member

 I'm not using authentication

 

I'm not using authentication method with certificates for none end-devices

Workstations with the windows default authentication protocol EAP/MSCHAPv2

In front of them there are non Cisco IP-phones with auth. method EAP/MD5

Finally I also have some printers again with option EAP/MD5

For all of these devices I received the same behavior, after many hours finally the authenticated with ISE. But is this the expected behavior?

What I understand is that if the devices finally authenticated then it means that there isn’t anything wrong with the method.

The misunderstanding points are 3

  1. Why there is so much delay for all devices to authenticate?
  2. Why some devices, mostly IP phones (not all) continuing to fail to the authentication method. All my devices are identical with the same software / patch, same model etc.
  3. I have noticed randomly some devices one moment to succeed and the next moment to failed

So for my understanding there is an abnormal behavior and i cannot find the way /pattern to correct it or to understand the reason :)

---------------------

Port config

switchport access vlan xxx

 switchport mode access

 switchport voice vlan yyy

 ip access-group ACL-ALLOW in

 authentication event fail action next-method

 authentication event server dead action reinitialize vlan xxx

 authentication event server dead action authorize voice

 authentication event server alive action reinitialize

 authentication host-mode multi-domain

 authentication open

 authentication order dot1x mab

 authentication priority dot1x mab

 authentication port-control auto

 authentication periodic

 authentication timer reauthenticate server

 authentication violation restrict

 mab

 dot1x pae authenticator

 no cdp enable

 spanning-tree portfast

 

 

------------------------------------------------------

result template

Switch#sh auth sess int g1/0/46

            Interface:  GigabitEthernet1/0/46

          MAC Address:  xxxx.xxxx.xxxx

           IP Address:  xx.xxx.xx.xxx

            User-Name:  xxxxxxxxxxxx

               Status:  Authz Failed

               Domain:  DATA

      Security Policy:  Should Secure

      Security Status:  Unsecure

       Oper host mode:  multi-domain

     Oper control dir:  both

      Session timeout:  N/A

         Idle timeout:  N/A

    Common Session ID:  0A114D0A00001972016208E1

      Acct Session ID:  0x00001BB7

               Handle:  0x6D0009B6

 

Runnable methods list:

       Method   State

       dot1x    Failed over

       mab      Failed over

 

 

 

 

Community Member

First thing is it looks like

First thing is it looks like you're running your ports in "open" mode which means that even if everything fails it's going to still pass traffic based on whatever ACL you've applied to the port.  My assumption is if you pulled that command from your port configuration everything would fail.

That is my understanding of the process anyways.

From what you've posted authentication appears to be failing across the board.

I would verify your workstation supplicant settings: make sure the PSN has a cert that is trusted by the workstation, services is started, verify the authentication parameters under your network adapter.

 

You should also verify you active directory settings.

 

Here are some helpful resources:

http://www.cisco.com/en/US/docs/security/ise/1.2/user_guide/ise_ug.pdf

http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/TrustSec_2.0/trustsec_2.0_dig.pdf

 

 

 

 

 

Community Member

That's right otherwise if I

That's right otherwise if I had removed the open auth.  I could be in serious problems in my company J

I reviewed the docs that you send me and I didn't see anything to have omitted in my implementation.

  • What I didn’t understand is what you say about the PSN certs that is trusted by the workstations

 In my implementation I worked with 802.1x native Supplicants without certs

  • Wired Auto config Service EAP/MD5 for my workstations/laptops (XPsp3, Win7)
  • 802.1x EAP/MD5 for my phones and printers.

What I realized following your comments and what I checked from the docs is that it’s better to connect the end-devices with the following ways

IP-Phones, Printers = MAB

Laptops, Worksations = Cisco anyconnect

Otherwise if someone don’t follow this set could be in a continuously loops with incompatibility matters between vendors.

I cannot see anything else to my problem my devices at least these that works fine at the moment authenticated - authorized perfectly. that means that my general configuration works fine.

My problem is the instability that appears, the same devices could not authenticated while identical devices successful authenticated.

Maybe i need to move on closed mode for some devices 10-20 (a convenient number) and start observing the behaviors of these lucky - unlucky users.

 

Community Member

I may have misread but from

I may have misread but from what I saw was:

 

Workstations with the windows default authentication protocol EAP/MSCHAPv2

When I saw this I assumed:

 

Simplified supplicant configuration. For example, Microsoft Windows supplicant with PEAP-MSCHAPv2 and server certificate trust enabled requires that you specify each of the server certificate to trust, or the user may be prompted to trust each PSN certificate when the client connects using a different PSN. With wildcard certificates, a single server certificate can be trusted rather than individual certificates from each PSN.

 

You could always have an authorization policy that attempts to use 802.1x as the primary method and then failover to an internal database. 

What I did early in deployment was setup a switch on my desk and then grab as many device types as I could.  One by one I created my authorization policies for the devices and then tested them in closed mode.  When I was able to successfully authenticate each type then I gradually deployed out to larger groups.

 

Windows supplicants have the option to validate server certificate, if you disable this then your workstations will authenticate off of anything that offers.  I wouldn't recommend it as a production deployment type, but it could make troubleshooting pretty simple.

 

196
Views
0
Helpful
5
Replies
CreatePlease to create content