Now that we have secured the wireless part of the network, lets work to secure switchports. Like wireless networks, switchports support 802.1x. However, it's a little different from the wireless configuration in that we only have a single switchport, so we won't be able to apply the SSID-to-VLAN style. What we'll do here is to enable authorization from the RADIUS server to actually help us push clients into the correct VLANs they belong to.
On a switchport with 802.1x enabled, the data received will be split into two separate channels. One channel will be specifically dedicated to AAA and will be the only channel available until authenticated. Once the client authenticates (or fails to authenticate, resulting in him being kicked into other VLANs, but we're getting ahead of ourselves here), the data channel will be open.
In switches, there are two kinds of VLANs that clients can go into. A client who doesn't authenticate (authentication timeout) will be put into a GUEST-VLAN. A client who authenticates but fails will be put into the AUTHFAIL-VLAN. We will show you the implementation in this article.
First off, lets recap what we have. The VLAN 10 (MANAGEMENT) of the switch has an IP Address of 10.10.10.2, while a RADIUS server resides at 10.10.10.4. Now we would set up basic AAA for the switch:
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius-server host 10.10.10.4 key 0 cisco
Now that we have the authentication and authorization lists defined, we can begin setting up dot1x. First of all, we must enable the dot1x mechanism through:
dot1x system-auth-control
Next we'll enable dot1x for the first 9 interfaces. To do this, we'll use:
dot1x port-control auto
By default, port-control is set to force-authorized, which means that clients need not authenticate. Setting it to "Auto" would cause clients to receive EAPOL packets from the switch.
Here, we'll also set the GUEST and AUTH-FAIL VLANs:
dot1x auth-fail vlan 30
dot1x guest-vlan 30
At this time the switch should be able to perform full AAA services. However, that's assuming that you have the RADIUS server set up for authentication.
If you haven't set up PEAP before, here's a simple walkthrough. Your server needs to be either a Domain Controller or part of a Domain, and it must be a Certificate Authority must have Network Policy Server installed. You should have these roles now:
Next, you'll need to add the appropriate policies for NPS. In this case, we'll use the default NPS policy that caters for all other authentication types. The first thing we need to do is to change the policy to Grant Access as shown:
Next, we'll need to add PEAP into the authentication method:
Finally, we'll set up the authorization options as shown:
Now the entire mechanism should work as follows:
Client successfully authenticates - Pushed into VLAN 20
Client fails to authenticate - Pushed into VLAN 30
Client doesn't authenticate - Pushed into VLAN 30
Now comes the client side. This is the simpler part of the article. We first have to make sure that Wired Autoconfig is turned on. To do this, enter services.msc from Run and look make sure it looks like this:
Now you would have access to the Authentication tab:
Make sure that you do not validate the server certificate or else it will not work. Your settings should look like this:
No comments :
Post a Comment