I'm trying to determine the security implications of utilizing 802.1x authentication/authorization with the "Domain Computers" option selected within ACS. The problem I am having with this scenerio is this:
1) Client machines are authenticated to the LAN or WLAN based on AD machine account name/password if "Domain Computers" is selected.
2) Windows XP machines will authenticate 802.1x using the machine account name/password by default upon initial boot and upon log-off.
3) Once a machine boots up or someone logs off, the 802.1x port status is placed into "Authorized" using machine account name/password credentials.
4) If you log onto a machine after the port goes "Authorized" (from #3) with a local user or local administrator account you gain "free access" to the network for < 60 seconds (I've done this many times now and you do infact gain "free access.")
So then the following scenerio comes into play, what if:
1) Someone steals a laptop.
2) Compromises a local user or local administrator account on said laptop.
3) Places the laptop onto either the wired or wireless network.
4) Reboots the box.
5) Logs in with local user or local administrator and launches a script (they will have free-access for < 60 seconds before a re-authentication is forced).
Anyone famliar with this, or any white papers/KB's is/are greatly appreciated!
When the user enters their username/password the supplicant switches to user authentication mode and should send an EAPoL start forcing an immediate re-authentication on the port, what supplicant are you using (if windows what service pack are you running on XP)? There may be some settings you need to tweak and if the machine is slow to boot it may take some time for the supplicant to be ready. If the user compromises the machine you have bigger issues though, with access to the machine the user can disable user login and force machine authentication only even in the user space. You may want to considder going the EAP-TLS route that way if a user laptop is stollen the certificate can be revoked preventing the machine from gaining access to the network. I guess this could also be accomplished by deleting the account from the domain.
Something else to considder would be to have a limited Machine Authentication VLAN and assign the user VLAN with the user authentication, this has implications on GPOs though as you are interrupting network access at the user login so you may need to delay those.
First, you should disable the machine account in the RADIUS server and AD when a PC is stolen or replaced.
if you allow a person with a stolen laptop connect the stolen laptop in your office by ethernet, I think that you should address the security loophole by physical security. Why do you allow such person in your office?
The PC will try machine authentication once it boots up. Once
is entered, the PC initiate 802.1x authentication by sending EAPOL start. The AP or switch should change the state of the PC from authenticated to authenticating. Thus, the PC should not get network connectivity unless it passes user authentication again. If you use a local account to logon to the PC, the PC should not pass 802.1x authentication. At least, that's how Cisco equipment works.
A small clarification here about your statement:
"The PC will try machine authentication once it boots up. Once
is entered, the PC initiate 802.1x authentication by sending EAPOL start. The AP or switch should change the state of the PC from authenticated to authenticating. Thus, the PC should not get network connectivity unless it passes user authentication again. If you use a local account to logon to the PC, the PC should not pass 802.1xauthentication. At least, that's how Cisco equipment works."
This is not up to Cisco equipment, the AP has no idea the PC is switching between machine and user mode unless the supplicant on the PC restarts the authentication (via EAPOL-Start as you stated), this is wholey up to the supplicant installed on the PC. So with this < 60 second window that is being seen here it is most likely due to slow load of the user space/desktop.
An option to prevent this would be to use a supplicant that can start before login (such as the Cisco Secure Services Client) that way the user is authenticated before they have access to the desktop.