802.1x Issues between B5 and NAC

  • 0
  • 2
  • Problem
  • Updated 4 years ago
  • In Progress
First of all is anyone using wired 802.1x Authentication successfully with NAC?  My goal is to have 802.1x be my first auth choice and Mac auth second and then use AD to push 802.1x settings to machines that are members of the domain.  All other machines would likely authenticate via Mac auth.  I have it set for user or computer authentication in the supplicant so when the computer first connects it authenticates as a computer and then flips to user auth when the user logs in.  Then I can assign policy based on who the user is rather than based on the computer with Mac auth.

I have this all working......sort of.  The problem I have is that periodically the computer flips into Mac auth after the user is logged in and has their profile.  This is seemingly random.  So the user is going along with their special profile and suddenly they get "Computer", which is what they get with Mac auth, and then they cannot get to whatever they need and they call me.

When I take a packet capture and trigger a reauth from NAC I see that the switch and NAC are exchanging up to 11 Access-Requests\Challenges pair  per client before NAC finally issues an Accept with the filterID.  So far I only have one capture during the moment when a client flips from 802.1x auth to Mac auth.  I see no associated RADIUS packet between NAC and the switch when that happens.  So I cannot see how this is happening unless the switch is just changing that without talking to NAC.  That should never happen.

At this point I'm pretty discouraged with 802.1x.  I am thinking I am adding too much complexity to the process of a basic connection.  If I roll this out over the whole campus there is any number of things that can bite me, the supplicant, the switch, NAC any time I upgrade anything I will be super nervous.

So is anybody else using 802.1x on wired as the primary way your users connect and if so are you able to get it stable?  Also does anyone have any idea what is going on with my network?

John
Photo of John Kaftan

John Kaftan

  • 810 Points 500 badge 2x thumb

Posted 5 years ago

  • 0
  • 2
Photo of Jason Parker

Jason Parker, Employee

  • 3,038 Points 3k badge 2x thumb
John
I am sorry I missed your question on the Hub and will answer what I believe is the issue and place the same feedback on the the HUB
I believe that you should change to multiauth precedence
Dot1x Mac pea
That way any PC registered will be MacAuth
"Show multiauth session or show macauthenticaton session
Then when the clients does dot1x
It will show up in the show multiauth session and will not be displayed in the show macauthenticaton session

Jason Parker
Photo of Charles Yang

Charles Yang

  • 130 Points 100 badge 2x thumb

John,

The following might help you to be on the right path. We have being using 802.1x PEAP authentication past 10 years. It is solid and stable. I do see the behavior which you are describing when the backend AD and local workstation is not setup correctly. Most of time it will be the NIC card authentication settings which enabled by for service on “wired auto configuration”.

First, I don’t have the full knowledge of your environment, therefore, the following solution might not be right for you.

When you said “the computer flips into Mac auth after the user is logged in and has their profile”, one troubleshooting step comes to mind. The following are the windows7 NIC to resolve the issue

1.       On the NIC property, authentication tab, Click on Additional settings

Under the 802.1x settings, click on “specify authentication mode” and select “user authentication” instead.

 

When you said” are exchanging up to 11 Access-Requests\Challenges pair  per client before...”

·         Yeah, we saw it too. It is windows 7’s default behavior. I cannot really sure why Microsoft OS is doing that. Apparently, it is using different PEAP settings on mschapv2 thingy... not really sure..

Hope the information above helps

Regards,  

 

Charles Yang

Photo of John Kaftan

John Kaftan

  • 810 Points 500 badge 2x thumb
Ok I believe it has stablized.  I did set it to User Authentication and it seems to be working.  I had it set to computer or user and that worked fine while establishing the initial connection.  First the computer connected as host/comptuername via 802.1x and once the user logged in it flipped to user Auth.  Then when the user would log off it would flip back to 802.1x as the host.  I liked that.  However, it was not stable.  After some period of time, could be 10 min, or 10 hours the end system would lose its 802.1x sesison and revert to Mac Auth.  The policy I have for MacAuth is very restrictive so the users would get jacked up and call me.

I was never able to prove what was going on because I could never get all my ducks in a row to grab the packet capture at the precise moment it was happening.  The one time I saw it happening while I had a capture in place I saw no RADIUS pacts exchange between the switch and NAC at the moment the end system went to MacAuth.  I don't get that because how would NAC know the computer was at MacAuth unless it was the one who authenticated it.  How could it do that without a RADIUS packet?  I don't see how a computer can move from 802.1x to MacAuth without NAC being involved.  It was only one capture so maybe I did not have it right.

It is a tough issue because it is hard to recreate.  Anyway a couple of people told me they use User Auth without issue so I went that route and it seems to work. 

Thanks

John


Photo of Charles Yang

Charles Yang

  • 130 Points 100 badge 2x thumb
John,
Thank you for the update. I was very interested to see the outcome. in the level of troubleshooting, I usually take NAC out of equation by have the switch directly send to a MS NAP server and have a logviewer to check what kind of RADIUS packet coming in. not sure if you can do that or not?

the reason the set the NIC  on "user auth" is because there are two mode how microsoft authentication when PEAP is enabled--user or computer. User mode obviously only using the user name to authenticate, but when "computer" is selected, the OS is using the <doamin/hostname> which reflects computer resource name in the AD domain to authenticate. also, it checks certs. and that will be a computer name based PEAP authentication. Some people uses that, but for us, it is not secure due to the fact to authenticate just by computer hostname is contradiction toward to security.

For the session time out issue, you might want to enable automatic re-authentication if not already. I set for reauth as every 6 hours-- it really depend on your security policy and framework.
Photo of John Kaftan

John Kaftan

  • 810 Points 500 badge 2x thumb
Yeah I could have the switch talk directly to MS NAP server but only in test.  The debug is pretty good on NAC though and I can always look at packets via port mirroring and wireshark so I am not sure what that will buy me but I will give it some thought.  The problem is time to set it up and get it working in NAC and on another device.  My logic for rules has gotten pretty complex.

MS has a 3rd option for auth which is 'user or computer'.  That is what I was using.  I had gotten away from user auth from my experience with wireless.  With user auth and wireless I would frequently get issues because the user was not on the network at the point where they were logging in.  They would have to first log onto wireless and establish an IP and everything and then log into the domain.  I kept getting "No Logon Server Found" from windows.  Not always but enough to make it a problem.  I went with computer auth because the machine would boot up and already be on the network when the user was logging onto it and they would get on fine.  Possibly there is a timer in there somewhere that I could have tweaked.  

I did experiment with this by naming a non-domain computer the same as a computer in AD.  The computer that was not in the domain was refused a connection so I figured I was fine.  I am still doing this with Laptop Labs (Tanks) because it is the only thing that is stable for me.

For users that are primary on the computer I can use user auth because if the network isn't there for them they get on with cached credentials.  

As for re-auth I just add a zero to the default of 3600.  So I do re-auth every 10 hours.  I like that because then if I see something in NAC whose 'Last Seen' is 2-3 days ago I know it is real and not just that the ES hasn't had a reason to authenticate.  






Photo of John Kaftan

John Kaftan

  • 810 Points 500 badge 2x thumb
Jason that is the order of precedence that I have now.  I am confused by "That way any PC registered will be MacAuth".  My PCs come up as 802.1x auth as host/pc name until my users log in.  Are you saying I should change my auth type in my supplicant form computer or user to just user?  

Thanks for the reply.

Photo of John Kaftan

John Kaftan

  • 810 Points 500 badge 2x thumb
Ok I see what you are saying.  I set the computer to do User Authentication + Single Sign on.  When the computer comes up it is MacAuth but it is on the network enough to talk to AD so when the user walks up to it and logs in it can authenticate.  With SSO enabled Auth flips to 802.1x using the user's credentials and they can get the profile we assign them.  

So with your method I am switching from MacAuth to 802.1x when people log in and log out.  What I was doing was switching from computer 802.1x auth to User 802.1x auth.  I still think what I was doing was fine and once the user was authenticated with 802.1x they should have stayed authenticated.  I am ok with it either way.  Can you think of a reason why there would be a difference between our two methods?  I have set a machine up this way and will leave it logged in to see if it stays logged in as the user.

Thanks for the reply Jason.

John
Photo of Yacobucci, Ryan

Yacobucci, Ryan, Multi-Tier Technical Support Engineer

  • 5,354 Points 5k badge 2x thumb
Hello John,

Typically we see environments that are doing .1x for both host and user authentication. When the user logs out, the PC switches to .1x host authentication, and when he logs in we see a user authentication with the username of whomever signed in. 

The main issue that I think is happening is a user .1x authenticated session is being dropped and MAC authentication is then the only option and takes over.

This can be proved by doing a "show multiauth session port x.x.x" when you see the .1x session drop in NAC and the MAC authentication takes over. If both sessions still exist then per precedence the port should show the .1x session still intact. If the output of the command shows the MAC authenticated session and not the .1x then the .1x user authenticated session has been disconnected. 

If this is the case then we need to determine why the session has been disconnected. Is there any re-authentication timer on the switch that would disconnect the session?

Also, can you verify that RADIUS accounting is enabled on the switch and is pointing to NAC? There might be valuable information in the accounting packets to determine why the session is being dropped.

I have seen issues in the past with .1x user authenticated sessions being disconnected due to enabling eapol on uplink ports. I did not see in instance of this in the traces provided, but it's still a good idea to check as the main issue is that something is causing the existing .1x session to become disconnected.

Thanks
-Ryan
Photo of John Kaftan

John Kaftan

  • 810 Points 500 badge 2x thumb
Thanks Ryan:

I will try your multiauth command.  I double checked and in Policy manager authentication is not enabled on the uplink port.  It is set to Inactive\Default Mode under the Port Mode tab.  Is there anywhere else I can check to make sure eap is not enabled on the uplink port?

I do not have RADIUS accounting enabled for this switch.  I will enable that.  I do have it set for 802.1x for computer auth and then 802.1x for user auth.  It works perfectly until the 802.1x session drops.

I do have a Reauth timer set for 36000 secs or 10 hours.  I have tried disabling that but it has not helped.