Forum

Hello all,

I've been searching online for different gateway solutions. I'm trying to find a solution that will keep unregistered user on a private / quarantine role / ip address until the user authenticates. After authenticating, the user can get a public ip address. I was wondering if anyone has ideas or can share your solutions. I'm currently reviewing the 802.1x solution. Since our network is a BOYD (campus/resnet) network, the 802.1x might not be the best solution.

My main goal is to separate our unregistered users from our registered users and keep the unregistered devices off the production network until authenticated.

Any help or thoughts on this topic is greatly appreciated.

Thanks,

Simpson,

As most will probably agree with we no longer have the "security by obscurity" mechanism in places with 802.1x for devices being that it is so well documented. We have started down the path (with me kicking and screaming) of bring your own exploit (I meant bring your own device) and what it really gets back to is having some sort of "NAC" (sorry I had to say it) solution in place. 802.1x will confirm the identity but it doesn't differentiate corporate versus private owned. You need a NAC solution to address that. One thing that I have started to do to keep them (WLAN's) separate to make the "guest network" more attractive to users. I made it the guest network easier to connect to and we opened up connectivity to some core services for the users. Most users who put personal devices on the internal network are only looking connectivity to certain applications, email, IM and most of those services are now available externally. I don't know all of the options out there but Cisco has ISE, Juniper has their layer 3 solution, Aruba has it built into the controller and I'm sure other vendors have some options to address this issue as well. At the end of the day, cost is going to drive your solution because users don't care about security.

That's true. Unfortunately, I work in Higher Ed and have a wired and wireless network deployed for on campus students. As it stands now, we have to use public ip addresses for user accountability. We use to use NAT but no longer use it. At this moment, any device that connects to the network will obtain an IP. I'm trying to prevent these devices from being on the same network as the devices that are authenticated. Just trying to keep the unauthenticated from the authenticated. This will save our IP addresses and reduce unwanted broadcast traffic. A lot of student will leave there devices on and walk away. Once the session times out, the device returns to a unauthenticated role but still keeps the IP address. Basically, I have a gateway with a login page that will allow internet access.

Thanks,

Have you seperating the students from authenticated users, by using a sepearate vlan/ssid/dhcp scope?

When a device connects to the network, it will get an IP address. When a student tries to access the internet, they are redirected to a log in page. Once logged in, they have access to the internet. So, to answer the question, all the users are on the same vlan.

So in other words, you dont authenticate to the network, you just authenticate to access the internet.

I vlan users based on their login credentials. I use Windows Server 2008 (running NPS) as my authenticating server (RADIUS). The connection policy places users in the vlan that corresponds to the "group" to which they "belong" within Active Directory. If they are not listed in any group, they cannot join the particular SSID. This should separate unauthenticated users (not devices) from authenticated. I suppose a default policy could be added "last in line" for those that "do not qualify". (not sure about that) These folks could be sent to a different vlan. This may not help you at all, and I apologize ahead of time. I am probably not qualified to do anything more than "lurk" for my own solutions, but wanted to at least try to help.

Sincerely

Thanks RC, I've been thinking of a similiar idea. I've been pondering the idea of using 802.1x and using web Auth as the supplicant. This way any devices that doesn't support 802.1x can authenticate. This will allow a private ip address prior to authenticating. This will keep the devices that are turn on (but not being used) from obtaining and wasting a public ip address.

Also, I've never set up 802.1x before. Please correct me if I'm wrong. Of the little bit of reading I've done so far, 802.1x can change a switch port to different vlans (as long as their defined) depending of the users cerdentials. I'm asking this because I need to do the same on a wireless and the wired.

Thanks

You might want to investigate [url=http://www.arubanetworks.com/products/management-security-software-2/amigopod-visitor-management-2/]Amigopod[/url] by Aruba.

It's a visitor and BYOD solution that allows you to control roles and access based on registrations and authentication type. Might be a good fit for you. Might not. Who knows?

Ok. I will check it out. Thanks for the reply!!

You are welcome. With regard to the wireless side. The switch port that the ap is connected to is set up to allow multiple vlans to pass through.(different from the default vlan of the port) Once a wireless user attempts to "join" this ap, those credentials are checked against multiple groups in Active Directory. Keep in mind that Network Policy Server is where the "policy" lives. The role of Active Directory in this case is more or less a "database" of names or groups. When it "finds" the group it belongs to, the policy for that group simply "tells" it from where to obtain DHCP. Once the wireless client obtains the correct ip address, it belongs to a specific vlan and can pass through if the port. I have never set up a switch to do this. I suppose in this case the switch, not the access point, would be the Radius client. The switch would have to be configured to "look" for the authenticating server. The devices connected to the ports (wired) would then be similar to the wireless clients looking to join an SSID. I have done a good bit of switch configuration via cli and such, but have not even "scratched the surface" for what I need to know. (this posting is plenty of evidence)

Sincerely