2007 Apr 30 - Mon
Implementing a Wired 802.1X Network With Cisco and Microsoft
Some companies will set up guest networks utilizing a parallel network configuration: separate switches or hubs, along
with separate DSL/router internet connections. They will then designate certain ports in a conference room to be 'corporate
connections' and certain ports to be 'guest network'. They then leave it up to the user to 'pick a port'.
This mechanism does indeed provide a separate path to the internet, but obviously, the weakness is an inability to
prevent people from using inappropriate ports.
A better from of enforcement is provided through the implementation of an authentication/authorization protocol called
802.1X. This protocol works with wired as well as wireless networks. Various methods of operation are available. The
simplest to to either enable or disable a switch port based upon receipt of appropriate credentials from the supplicant,
which is the computer/user being connected to the network.
A more sophisticated form of operation is to assign a vlan (and associated IP address) based upon computer and/or user
credentials. If a connecting device does not have supplicant ability, a default 'guest' vlan can be assigned.
According to Cisco's and Microsoft's literature, the best authentication mechanism for 802.1X is through EAP-TLS, a
PKI/certificate mechanism.
This document describes an implementation based upon Microsoft's Certifcate Authority (CA), Microsoft's Internet
Authentication Server (IAS), and Cisco Switches.
The implementation uses a Windows Server 2003, Enterprise Edition, for the Certificate Authority. The Enterprise
Edition has a
few more CA templates (such as Wireless certificate templates) than does the Standard Edition product. One recommendation is
to run the CA on a VMWare server. This
provides the ability for simple backups and to move the CA from place to place. For very risk averse environments,
placing the CA on a dedicated server in a secure room would be a better choice. The primary consideration in this is that
the CA is a single point of failure and requires a simple, convenient, fast mechanism to bring it back to life during some
sort of failure condition.
With the CA in place, machine and user certificates can be automatically issued through a Group Policy configuration.
Users and machines should be assigned to various Active Directory groups. For machines, possible groupings would be
servers, workstations, and laptops. Since Laptops are typically more prone to carrying malicious nasties, assigning them
to protected segments is beneficial.
As some HP printers are 802.1X ready, they can also be issued certificates.
Users can also be issued certificates. Preliminary testing indicates that Group Policy doesn't push out the certificates.
Users need to download them manually by connecting to the CA server webpage at http://ca/certsrv to obtain their
certificates.
Windows XP workstations have the 802.1X supplicant built in. The settings for the supplicant are in the authentication
tab under properties for the network card. On some machines, you may need to start the Wireless Zero Configuration
(WZC) service in order to see the tab. For our implementation, the defaults are fine.
However, there are two registry keys we play with to change the characteristics somewhat. They are described in a
document called 802.11 Wireless Tools and Settings. Even though the document is about 802.11 Wireless, the settings still
apply to wired connections. After changing the registry keys, the machine will need to be rebooted, or simpler, restart the
WZC service.
- AuthMode: HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global\AuthMode
- SupplicantMode: HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global\SupplicantMode
With AuthMode of 1 and SupplicantMode of 3, you can get different VLAN's depending upon whether or not a user is logged
in. If a user is not logged in, and a machine is plugged in, the machine certificate defines the VLAN. If a user
subsequently logs in, the VLAN assignment changes to that associated with the user. If the user logs out, the VLAN reverts
back to the VLAN associated with the machine certificate.
For another site where the administrator wants to ensure that users login to the network in order to ensure login
scripts run (scripts that check that virus clients are up to date and such), a SupplicantMode of 2 and an AuthMode of 1 would
be used. Supplicant mode of 2 will not force a renegotiation when a user logs in. In this scenario, one of two VLAN
assignments happen:
- If a user is logged in and the machine is connected to the network, the VLAN assignment is based upon the logged in
user's certificate. As this doesn't force a domain login, no login scripts are run. Therefore, a blocked VLAN would be
assigned to this relationship. This will force a user to logout, disconnect and reconnect in order to get the machine based
VLAN instead.
- If a user is not logged in and the machine is connected to the network, the VLAN assigned is the one associated with
the machine certificate. Even when the user subsequently logs in, the VLAN assignment does not change. This mechansim
forces the user's domain log in and the operation of log in scripts. (See further in this document on how this relates to
the 'reauthenticate' command in the switch).
A company called Blue Socket may have some add-on tools that force
Domain Login.
On the Cisco side of things, there are a number of configuration items. For a 3750 switch, Here is an example
configuration document: Configuring 802.1x Port-Based Authentication.
The switch needs to know of one or, preferably more, RADIUS servers:
radius-server host 10.10.10.10 auth-port 1645 acct-port 1646 key thisisakey
radius-server source-ports 1645-1646
Make sure you have a username line and enable secret in the configuration:
username switchadmin password switchadminpass
enable secret enablesecret
Then let the switch know to where authentication requests need to be sent:
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
aaa accounting system default start-stop group radius
A switch global command is required:
dot1x system-auth-control
Each interface needs some additional commands:
interface GigabitEthernet0/1
switchport access vlan 3
switchport mode access
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 3
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
dot1x timeout supp-timeout 5
! dot1x reauthentication
dot1x auth-fail vlan 105
spanning-tree portfast
spanning-tree bpduguard enable
The 'dot1x reauthentication' may or may not be applicable. A scenario in which it should not be used is the following. I
mentioned a scenario where you want a machine to be connected to the network before a user logs in. When the user does
finally login, you don't want the vlan to change. Hence, SupplicantMode should be 2, and there should be no 'dot1x
reauthentication' command. If the command were in place, the reauthentication would see the user certificate and change the
vlan to suit. Which wouldn't be the desired affect.
For further reading and reference, here are some additional links:
|
