Wireless Access

Hello everyone, I'm pretty new to 802.1x authentication and Aruba. We've recently installed 40 new Aruba Instant Access Points 215..We have ClearPass 6.5 with RADIUS to our Microsoft Active Directory authentication. We have 2 VLANs and depending on the user account, the computers should be assigned to one of the two VLANs. 

 

Both user and machine authentication works as it should. ClearPass authenticates these correctly. On Mobile devices and other non-domain devices we have no problems. However, our Windows 7 laptops, which are part of the domain are behaving strangely. 

 

These Laptops don't seem to process the GPOs properly at login. We have the SSO Funktoionality for 802.1x Authentication conifgured and the devices also Authenticate themselves before starting the Windows Login process. However Users who login at a computer without a cached profile will not get their profile properly. The user will be logged in with a local profile and no folder redirections or network drive maps. 

 

After restarting and logging in again 2-4 times, the profile ist loaded and the folder redirections and maps are made. However if you log out and log in with another account or the same account again, the folder redirection and maps don't work. 

 

We've tried setting the GPO to wait for the network before logging in and we've tried a registry edit to make the computer wait for a network at login before processing the GPO. Both options didn't seem to make a difference as the login just waited for the timeout (60 seconds) and then proceded with the login anyway resulting in a broken profile. 

 

Have any of you encountered a similar scenario or do you have a similar installation that works from which I might learn how to configure things properly?

 

Please tell me if you more or other information.

Are you doing machine authentication ?

No, we've deactivated machine authentication at the time. 
We've tested it with machine authentication only and that works fine. However that doesn't give us the flexibilty we need as the machines can be used by different types of users that need different VLANs. 

And when we had the machines authenticate first (and put into the VLAN with lower privileges) we seemed to have the same problems when a user logged in that needed a different VLAN. 

Liam_R,

The reason why this fails for many people is that they try to out the user and the computer in different vlans. Also people think that users need to be in different vlans, bit they honestly only need an IP address, regardless of who they are. The Role on the IAP can restrict users that are in the same vlan to provide the separation that they need.

Long story short:

- do machine authentication on the client
- put users and computers in the same vlan
- return an Aruba Role for different users to segregate what they can and cannot access.

Colin Joseph,

 

Thanks for the reply. Sadly we have an existing infrastructure (with these two VLANs) that we can't change at the moment. We are planning on restructuring it in about half a year though. 

 

From your instructions I gather that I can assign IPs during machine authentication in a different net that exists only for wireless clients (with access to the two other LANs) and restrict the users during user authentication to give them access to only one or the other vlan. Is that about right?

 

I won't be able to do any tests on the installation until early next week. After that I will give feedback on the success of these. 

Liam_R,

 

Switching VLANs between user and computer authentication breaks GPO processing.  It also makes it so that users who do not have cached profiles on the laptop cannot login, or run login scripts as a result.  You need to have the computer and users on the same VLAN.  Choose a single VLAN and put all of your devices on it.  If you want, you can return a role that exists on the IAP that restricts traffic for different types of users.  Please be aware that the role needs to allow traffic to all domain resources for mappings, etc otherwise it will still break GPO processing.  Most people start with roles that allow everything so that they can validate functionality and take it from there.

 

Many people are of the opinion that they need to put different users into different VLANs as a security measure, but when users plugged in wired, they just get an ip address and go.  Sending back a role allows you to use any ip address space and then lock it down based on the user.

I was able to solve the problems by keeping the devices in a IAP DHCP Scope on a single Subnet governed by the access points. I then allowed access to one or the other vlan through the IAP NAT function according to the User Roles I assigned in Clearpass. Like this the devices were able to get an IP during machine authentication und then receive access to their respective VLANs during user authentication. 

Thanks for your help.

In order for this to work you need machine auth to work.

Instead of sending different VLANs send different role with different access but use the same VLAN

What may help in here, if you switch VLANs between machine and computer authentication, is the 'Enable Single sign on for this network' option in the Advanced Settings for your SSID (or wired network). That has some control about when the machine-user authentication switch takes place, and if you tick the box for VLAN switching, your client should trigger a DHCP on the authentication switch.

 

 

It has been some time ago that I used this option, but it may work in this case.

 

Please let us know if this fixed your problem...

 

Regards, Herman

Hi everyone,

 

Hope it is fine to bring up this topic again instead of creating a new one.

 

Part of a customer Clearpass pilot deployment, I am currently meeting very similar behavior as initial issue raised by Liam_R. However there are few differences with the environment :

 

- It is wired and not wireless 802.1x authentication.

- NADs are Procurve Switches working along with RADIUS server of ClearPass 6.6.0 communicating with AD. So it is 802.1x port-based access control where ACLs are pushed from Clearpass to switches per port.

- Rest is the same: User and Machine Auth are perform, 2 vLANS (1 restricted if Mach auth only succeeded, 1 allow if User and Mach auth both succeeded).

 

Just like Liam_R, GPOs aren't properly processed at login and particularly the ones involving network drive mapping.

 

Good part is that after Herman Robers suggestion regarding the SSO feature, it partially fixed the issue. GPOs were correctly processed and network drive correctly mapped. However this works only in a logoff/login scenario, in a restart/start scenario it doesn't (same initial result with no GPO processed).

 

Thinking that it could be because network didn't have time to properly start, I tried to enable the option "Always wait for the network at computer startup and logon" and increase the "Startup Policy Processing Wait Time" 60 seconds. Unfortunately nothing changed.

 

Based on previous posts, I understood that Machine and User should be in the same vLAN but in this case it is not an option for this customer deployment. Moreover the fact it is working in logoff/login scenario and not in start/reboot scenario makes me conclude that switching vLANs between user and computer do not always break the GPO processing, am I right ?

 

I'm quite new with Aruba and 802.1x auth and even more when it comes to Windows 7 client. Do some of you have maybe more experience with GPOs and have a small hint on what could be the reason of this behavior ?

 

Please let me know if you need additonal information.

 

Thank you for your consideration !

 

Simon