Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
802.1x client that used to pass authentication is now failing.

Answered 802.1x client that used to pass authentication is now failing.

  • Monday, May 24, 2010 1:20 PM
     
     
    Sign In to Vote
    0

    We have been deploying 802.1x in our environment (~1500 workstations) over the course of the past two months, turning it on switch by switch, verifying that clients can authenticate successfully.  We now have about a half dozen workstations that previously passed authentication, but are now failing.  The event log on the IAS server shows that the client is trying to authenticate using its MAC address as user name instead of its computer name.  The Group Policies configuring the workstations were in place for months before we began activating 802.1x on the switches.  RSOP shows that the machines are receiving all the correct policy settings and examination of the Authentication Tab on the NiC shows the right settings as well. 

    A successful computer authentication looks like this in the logs:

    User host/ComputerName.DOMAIN.ORG was granted access.

    Fully-Qualified-User-Name=DOMAIN.ORG/OU1/OU2/ComputerName

     

    The failed computer authentication looks like this:

    User MACADDRESS was denied access

    Fully-Qualified-User-Name=DOMAIN.ORG\MACADDRESS

     

    In some cases, we have been able to get the machines to authenticate again by turning 802.1x off for their port (to allow them back on the network), running GP update /force on the client, waiting about 30 minutes, and then turning 802.1x back on again.  I'm not even sure why this works, because the machines already have the correct policy.

     

    A few more details about our configuration:

    IAS Servers=Windows 2003 SP2

    Clients=Windows XP SP3, Wired

    Switches= Alcatel 6600 and 6850

    Authentication Mode=PEAP, Computer Only, EAP-MSCHAP v2

     

    I'm starting to get really paranoid that something in our 802.1x set-up isn't right and it is going to cause the entire infrastructure to collapse and block everyone on the network.  Please Help!

     

All Replies

  • Monday, May 24, 2010 4:14 PM
     
     
    Sign In to Vote
    0

    NEW INFO:

    The clients involved all appear to have the same App Log event:  These are followed by entries indicating that the NiC will ignore/lockout subsequent EAP traffic for 1200 seconds.  

      Identity: host/ComputerName.CWF.ORG

      User: -

      Domain: -

      Reason: 327685

      Reason Text: An internal error occurred.

     

      Error Code: -2147023537

     

    I can't find anything on fixing the 'internal error'  I've seen a hotfix (957931) that once installed will let you change the lockout period through the registry.  That's a lot of hoops to jump through to deploy a hotfix to the entire domain, and then change the registry on all those machines, and it doesn't even address the initial error.  It only reduces the lockout!

    Any ideas on 'An internal error occured?'

    <!-- [if gte mso 10]> <mce:style>


     

     

     
  • Thursday, June 17, 2010 8:25 PM
     
     
    Sign In to Vote
    0
    250 views, and no one has any ideas?
     
  • Friday, July 02, 2010 3:51 PM
     
     Answered
    Sign In to Vote
    0

    I think we have two issues here.  The first issue is that the machine password has expired which results in the client being unable to connect.  This is discussed in:

    http://support.microsoft.com/?id=904943

    This also explains why leaving the client on the unsecured port we result in the cleint eventually fix itself.

    The second issue is actually a function of the switch and has probably been occurring all the time but you may not noticed it until the machines started getting blocked.  The switch is simply configured to do MAC authentication and is assuming that it needs to send these requests on behalf of the client.  It does not look like they are enforcing the authentication requirement.  The client does not send its mac address as the username.

    Clay Seymour - MSFT
    • Marked As Answer by jamesking5 Thursday, July 26, 2012 7:22 PM
    •  
     
  • Thursday, July 26, 2012 7:21 PM
     
     Answered
    Sign In to Vote
    0

    Wow, I should have closed this years ago. 

    The issue was related to machine accounts expiring, but there was more to the story.  Most of the failures occured first thing in the morning, and especially on Mondays.  It turns out that all of the machines that were failing were set to hibernate due to inactivity and the network connection would go dead.  In the hibernated state, the machine account password would expire and reset locally, but not update on the domain becaues the nic was asleep.

    The resolution was to configure the power settings (locally or through group policy) to either not hibernate ever, or to keep the nic alive even in a hibernated state.  In a couple cases we had to train users not to hibernate portables/laptops when the took them off the network.

    • Marked As Answer by jamesking5 Thursday, July 26, 2012 7:21 PM
    •  
     
  • Thursday, July 26, 2012 8:01 PM
     
     
    Sign In to Vote
    0

    Wow, talk about timing.  Thank you, this has really closed a gap for me as to why the passwords get out of sync in the first place.  I have been trying to sort that our for years.

    Clay Seymour - MSFT