help with 802.1x?

[Aaron_M]

Let me preface and say that I am probably going to ask some fundamentally basic questions, and probably misunderstand some things about either how 802.1x works in general, or how Extreme's implementation of 802.1x works, as I did see a post that made mention that Extreme does auth a little differently, as far as port vs MAC auth. So I apologize in advance.

I was wondering if anyone can point me in the right direction as far as possible template configurations, or specific sections of the concepts guide? I looked through the concepts guide, and tried some of it out, and still had issues.

We are a university, and ideally, I'd like to be able to have a port:

• unauthenticated - guest/student vlan
• authenticated as a student - guest/student vlan
• authenticated as staff - staff vlan
• phone authenticates with MAC (which I still need to figure out how to do) - voip vlan

First off, is the above possible?

I found somethings about using VSAs, but then they reference placing users in groups in AD, and then, if those users authenticate, send back a specific VLAN name, which confuses me a little, probably because we're doing it wrong.

In our environment, each building has its own VLAN, let's say building A is VLAN 1000. In the switch, that VLAN name is "buildingA" (we also have VoIP VLANs as "voice_buildingA"). Likewise, building B is VLAN 1010, building C is VLAN 1030, etc. The first thing I'm wondering is, what happens if the VLAN name the VSA is sending on auth, doesn't exist on that switch? For example. Staff member is part of the 802.1x auth group in AD. They're in buildingA, and RADIUS sends the "buildingA" VLAN name. Cool. What happens if they go to building B? RADIUS would send "buildingA", which doesn't exist on that switch stack. "buildingB" does, but not "buildingA."

Is the VSA portion necessary, or is it an overcomplication, and can everything just be done with NPS?

Sorry if this is confusing. It's just new territory, and I want to try and implement something during the summer so we can smooth it out before students return en masse. As it is right now, students can just come up to administrative buildings or classrooms, and plug right in and get full network access. Sure they need administrative credentials to access resources, but ideally they shouldn't be able to get to a lot of that in the first place.

Thanks in advance (and please be gentle).

[Chad_Smith1]

Aaron,

You don't use U or T with 209. You can use U and T with a VLAN ID if you are using Attribute 211. A description of the VSAs can be found on page 872 of the 21.1 User Guide

[Aaron_M]

Chad, thanks for your detailed response. I'll have to review our policies as I've seen some set up with NAS IPv4 and some with Client IPv4, so that you for that clarification.

With regards to what you've said about U and T for VLAN Names, and with what I've read here: http://www.extremenetworks.guru/exos-802-1x/, does the U and T still apply if using Attribute 209 or 211 with VLAN ID instead of VLAN Name? (ex: U1000 instead of UBuildingA, or T2000 instead of TVoice_BuildingA ?)

I'll probably do some testing over the next couple days and will report back how it goes.

Thanks again.

[Chad_Smith1]

Aaron,

Replies to each of your 5 bullet points

• Yes. You may also need/want a group for phones and students.
• The actual terminology in NPS for a RADIUS client IP is "Client IPv4 Address". You can also use a wildcard. So you could create a condition for all BuildingA RADIUS clients by specifying 10.10.10.* (or whatever the network address is). This is probably not a good practice though considering there will be actual users in this same subnet. You should specify each individual RADIUS client.
• Yes
• The value is actually X where X is either U for untagged and T for tagged traffic. In this situation I believe you would always need untagged. So it would look something like "UBuildingA".
• Yes, at least three policies per building.

There are a couple of options to solve the guest/student problem that I can think of.

IF you were ONLY using 802.1X netlogin on the ports then you could use the guest VLAN feature of netlogin. This effectively places all devices that do not participate in 802.1X authentication into the specified guest VLAN

• configure netlogin dot1x guest-vlan vlan_name {ports port_list}
• enable netlogin dot1x guest-vlan ports [all | ports]

Since it seems you may need to use both 802.1X and MAC auth on the ports (for phones) then you could also try using the authentication failure VLAN as the guest VLAN. Any device that is not authenticated either via 802.1X or MAC would be placed into this VLAN

• configure netlogin authentication failure vlan VLAN_NAME

Also, you could create another "accept all" policy in NPS that authenticates all other devices and places them in a guest VLAN via VSA. This may be the best option. Simplified policy logic:

• Staff user Auth with 802.1X go to staff VLAN
• Student auth with 802.1X go to Student VLAN
• Phone user authenticated via MAC list and placed in VOIP VLAN
• All other authentications received from RADIUS Client (switch) go to guest VLAN

[Aaron_M]

Chad, thanks for the quick response.

So we have a simple star topology with, for the most part, Core to Access. We don't really have Distribution switches, except in a few cases...sort of.

Generally each building typically just has one VLAN for staff, and then one VLAN for VoIP. There are a few locations where a switch will have more than one VLAN for staff because the switch in that situation serves end users, as well as acts kind of like a distribution switch for another building.

For example, for most locations, we have Core > BuildingA, so in that situation, building A's switch stack will just have two VLANs - staff and VoIP. A handful of other locations have Core > BuildingB > BuildingC. So in that respect, building B will have both buildingB and buildingC staff and VoIP VLANs (with buildingC VLANs only tagged on the uplink to core and buildingC).

Each switch stack's Client IP will be the .2 (upwards of .4) of each building's respective staff VLAN. So, Core has a router interface for VLAN 1000 (buildingA) of 10.10.10.1. BuildingA switch stack will be 10.10.10.2, and again, that's the staff VLAN.

As far as VSA goes, I'm looking at NPS right now, and given what you've said (as well as what this article says, it seems like the following needs to happen when setting up the Network Policies:

• We're going to need to put all dot1x staff in a group, and add that group as a condition
• The switch stack's IP will need to be added as another condition as Client IP (or NAS IPv4?)
• Authentication Methods in Constraints as shown in that article
• Vendor Specific Attributes in Settings, that's where we'll set up the different VSAs, each with Vendor Code 1916, and Attribute Number 211, Attribute format string, and then Value as the VLAN *NAME* on the switch?
• And we'll also need probably 3 policies (eventually) per switch stack (since the Client IP and User Group are defined in each policy's Conditions tab: so a policy for staff in builiding A, a policy for students in building A, and (eventually) a policy for phones in building A?

Another thing I thought of, can authentication failures also be set to keep people on the guest/student VLAN?

[Chad_Smith1]

Aaron,

I believe the functionality you need should be possible.

A few questions:

Do you have only one VLAN per building or is there a student, staff, and VOIP VLAN per building?
What IP address would the switch be sending the RADIUS request from?

One way to solve your location based problem would be to send different VLANs in the VSA based on the RADIUS client (the switch) that is sending the request. So if a switch in BuildingA sends the request then the VSA sent is for VLAN BuildingA. If a switch in BuildingB sends the request then BuildingB VSA is sent.

The VSA portion is necessary in order to place users in different VLANs based on their user credentials.