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?
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?
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.
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,
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?
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,
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...
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.
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?
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.