07-17-2006 11:50 AM - edited 03-10-2019 02:39 PM
I'm investigating implementing 802.1X for authenication on our network. Our primary access switch for users is the 3550. It appears straight forward however I have a question. How do you deal with software pushes to devices on the network where the users are logged off and the port is in an un-authorized state? If you try to access a device on the network will it automatically authenticate?
07-18-2006 02:27 AM
Mike
This is a really good question, an un-authenticated supplicant should behave like an un-connected port. If 802.1x allowed traffic to flow I'd be worried.
Im not sure a switch can request an un-authenticated client to re-authenticate. Even if the protocol supported it, you'd probably be limited to machine auth rather than full user authen.
When ACS mainly did dial we had quite a few requests to build an external event notification mechanism in such that when a user was connected we pinged another external system and that did its thing. Maybe something like this is needed again to tell your servers to push out any pending updates?
Darran
07-18-2006 05:34 AM
Thank you Darren,
As I expected. What we are trying to do is to keep non company devices off the network. We have patch management & IDS implemented already. I'm thinking a full blown NAC solution is expensive and possibly over-kill. Also I don't want to do MAC port security because of administrative overhead.
What if we set up service account on the hosts that would log in and be used to keep the devices on the network. we could then re-authenticate every 7200 secs or whatever as a keepalive.
Thoughts?
07-18-2006 06:04 AM
Catalyst switches offer configurable behavior in this regard. By default, switches offer a bidrectional controlled port. This means nothing should come into or out of the network until authorized by 1X. But this would not inter-operate with the above use case, and it is written into the 1X spec as well as a guideline for how to deal with this. It is a unidirectional controlled port. This means traffic can exit the network (like to wake a machine up for patches, etc.) but traffic is still disallowed inbound until authorized by 1X. Thus, the expectation here is that any machine that uses this must authenticate itself for network access .. which typcially means machine-auth as pointed out above.
Hope this helps,
07-18-2006 08:24 AM
Thanks,
So what your saying is that although the device is not in an authenticated state it will still take software pushes or remote access. It just cant initiate the communication?
Regards,
Mike
07-18-2006 11:15 AM
Let me describe it with an example:
* 802.1X-authenticate my PC. The port is up and authenticated.
* Put my machine in hibernate mode when I leave for the evening (port goes down), and I am using a WoL utility to wake my machines up (I might have been using this before 1X anyway).
* With the described feature, this allows me to send my WoL traffic to my PC to wake it up, even though the port is UNAUTHORIZED.
* However, remember you're still running 802.1X, so my machine must 802.1X-authenticate itself when it wakes up to get proper network access.
Hope this helps,
07-18-2006 01:39 PM
YES .... I understand now.
07-19-2006 03:39 AM
You can use both actually.
We use Aegis with machine authentication (Active Directory SID) and user auth on top.
So when the PC is 'on' it is authenticated using it's SID entry in Active directory. When the user comes in and logs on, the authentication process starts again to authenticate the specific user...
07-19-2006 03:48 AM
There are two work arounds. Most 802.1X authentications use PEAP to authorize a computer rather than the user. Which means as long as the computer is on it should continue to answer EAP polls by the switch. The otherway is to use a guest VLAN. By creating a guest vlan with one server acting as SMS patch server and DHCP you could just let the computer fall of your legit network into an isolated network and remain patched.
07-19-2006 05:41 AM
Exellent Jason...Thanks
07-22-2006 06:57 PM
If you guys don't mind, I'd like to use the great talent pool on this post with a counter-question.
I'm deploying a wired 802.1 infrastructure and the simplest method seems to use MD5 on my Windows XP workstations.
1) Is this secure enough and is the most commonly deployed encryption protocol for wired 802.1x?
2) What are my other options without installing a certificate server?
Thank you
07-23-2006 09:40 PM
In most cases MD5 is not strong enough anymore.
From the choices TLS, TTLS, PEAP and FAST you could take a look at TTLS, PEAP and FAST. With these three you only need a server certificate to make it work. If you use Cisco's ACS it is easy, it has a build-in CA. Otherwise take a look at the Microsoft CA, freely available on server installations, and works fine.
I've used them al except for TLS, and they are pretty easy to implement. TTLS has a lot of flexibility for inner authentication protocols, PEAP is already supported by the build in XP client (with SP2 you case use SSO when authenticating to AD). Use FAST if you are going for NAC as well.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide