• 1.  802.1x and Single Sign-on

    Posted 02-07-2014 20:12
    We have a number of laptops that are mobile labs (Tanks) and in the library for students to check out.
    We push the 802.1x settings via AD and it works very well. The problem we have run into is that when we have login set to 'user or computer' and check single sign-on it comes up and logs into the network using the computer name just fine. But then when the user logs in it immediately authenticates 802.1x as the user and then proceeds to churn until ultimately failing with "No logon servers found".
    The strangest thing about this is that packet captures reveal that while the machine is churning it is sending out ARPs for its gateway. The gateway replies but the client ignores it. It does this 30-40 times before giving up.
    If the user has logged onto the machine before they will get on with cached credentials and they will be fine, other than being grumpy over how long it takes to get on. If they have never logged on before they will get the dreaded "No logon servers found"
    Doing a 'ARP -a' at the command line reveals the gateway address is listed and the machine is able to browse just fine.
    I don't think this is a wireless\policy issue as I set up the client to get our IT_Admins profile no matter what and also after the client finally stops asking for the gateway's mac address everything is fine.
    Our work around is to just set it to Computer authentication only. This is a bummer because we lose visibility as well as the ability to apply user based profiles.

  • 2.  RE: 802.1x and Single Sign-on

    Posted 02-10-2014 16:45
    In the deployments I've done with user or computer authentication, I haven't selected the single sign on option and it works great. Have you tried removing that checkbox and see if it helps?

  • 3.  RE: 802.1x and Single Sign-on

    Posted 02-11-2014 19:02
    Yes I have tried that. Still have the same issue. I have found that if I have logged into the machine before I can get to the desktop. Once on the desktop I fire up Wireshark and I can see the arp request leaving but no return. Extreme taught me how to grab a remote packet capture from the AP (very cool BTW) and the arp reply is making it to the radio anyway.

    If I disconnect and reconnect to my VNS I am fine so I think there is some issue with the encryption key changing when the user changes from computer to user but either the client or the AP is not updating. So when the encrypted data hits the Wireless NIC it just gets dropped. Then when I disconnect and reconnect the keys get lined up again and all is well.

    Just a theory.

    Also, when the machine first comes up and is logged onto the network as a machine I can ping it all day long. As soon as I login I can no longer ping the device. I have it rigged so that an IT Admin policy gets assigned for both computer and any user so throughout the process the policy never changes and it is a policy that is wide open.

  • 4.  RE: 802.1x and Single Sign-on

    Posted 02-11-2014 19:05
    What version of Windows are you using and how old are you network card drivers?

  • 5.  RE: 802.1x and Single Sign-on

    Posted 02-25-2014 18:14
    Hello, I hope you are well.
    I know you have been working with GTAC on this concern through an actual case. As the NAC engineer has not discovered the answer, a wired engineer has reached out to you to gather some additional files for a better understanding of the problem.
    Once the solution is available, we will post it for all to see.

    Brian Townsend

  • 6.  RE: 802.1x and Single Sign-on

    Posted 03-25-2014 21:05
    Hello John,
    The issue you have mentioned it is a Microsoft behavior and not NAC or policy behavior.

    • you have a internal CA setup
    • you have a NAP server setup.
    The solution is to have the workstation NIC settings setup as the following
    In NIC property.
    1. enable the IEEE 802.1x authentication
    under the "Microsoft: protected EAP (PEAP)"settings
    • Select the "validate server certificate"
    • connect to these servers >> your internal RADIUS server as FQDN (eg.
    Hope it helps

  • 7.  RE: 802.1x and Single Sign-on

    Posted 03-26-2014 13:16
    I am not using certs to authenticate. I am just using username and passwords. As for the server yes I am requiring that it validates itself. I am using an externally signed cert and have the trusted roots checked in the supplicate. I do not have a NAP server setup. What would I do with that?


  • 8.  RE: 802.1x and Single Sign-on

    Posted 03-26-2014 15:02
    PEAP authentication by default requires you to utilize certificate authority (CA). The error message you are getting is that EAP packet return is asking "where is the (certificate) server?"
    If CA is utilized, the conversation gets a bit complicated either it is a "internal" or a "external" CA you are using; thus, you will have some decision to make to setup CA infrastructure (internal certs infrastructure--99% of time). When utilizing the PEAP authentication for wire or wireless connections, certificate is required.

    However, if you are not using certificate, there are two ways to deal with the situation.
    1) using PEAP setting but uncheck for "certificate server validation" checkbox. (you might be able to fool Microsoft OS that way).

    2) or using EAP-MD5 CHAP authentication. This method, requires no certs for deployment. but the downside is that whenever user login, they will have to deal with windows balloon pop-up twice and login (lower right corner NIC icon enablement.) -- not sure if it will work for win7, we tested back in the day for XP.

    Using MS-NAP server is up to you. we utilized MS-NAP for NAC redundancy in case of complete failure of NAC infrastructure. (This is for another story).

    Using of externally signed certificate might be a good bet, personally we have not going down that route, Having a internal CA or not, there are argument for both cost vs management vs organizational approach. There are pros and cons for both scenarios.

    Hope it helps.

  • 9.  RE: 802.1x and Single Sign-on

    Posted 03-26-2014 15:38
    We are forcing the server to Validate and the server has to have a externally signed cert because we have computers on our network that are not part of the domain and we do not want to deal with getting our root's cert on non-institution computers. So yes we are using the cert for the server (NAC) to validate itself. I thought you meant using client based certificates to authenticate. We are not doing that.

    I figured the cert from the server was just used as a validation mechanism so we can trust the server before we give up our credentials. I can uncheck that in the MS supplicant and everything works fine so I'm not seeing that a certificate is required. Are you saying the cert is required in order for encryption to work?



  • 10.  RE: 802.1x and Single Sign-on

    Posted 04-11-2014 00:33

    Sorry for the much delayed reply.

    To clarify, what I meant by using internal CA is to deal with internal users only. in order for the PEAP to work; a server-side public key cert is need to create an encrypted TLS. That is it.

    If you are using Microsoft OS as the major portion of your servers and clients, Microsoft implements PEAP-EAP-TLS is utilized which it requires client-side certs.

    As you have mentioned in the original post, the behavior of "spinning" is because user certs is not there. if you have a Windows PC, there are two kind of certificate being issued-there are computer certs and user certs. If CA exist on a MS domain, computer certs is automatically issued. The user certs will be issued if modify the MS group policy. If the CA does not exist, then Windows OS will generate a self certs whenever it needs one. for example, a stand alone PC will have a self certs generated by OS when EFS is enabled.

    Since you said some of your user traffic are based on non-institutional devices. in this case, in wired environment, I will only implement a MAC PAP based NAC rule to parse the non-institutional devices with a restrictive policy role-- skip the hassle to issue some kind of certs to make PEAP occur --because PEAP encrypts the authentication tunnel only..