New Wireless - authentication methods?

[mdench]

So over easter we have installed a new Xirrus WiFi solution and I've been playing around making sure the APs work as basic but now I'm wondering hows best to set up our SSIDs etc.

 

On our old wireless we had several SSIDs setup in the following configuration:

 

Student (no wifi key) - Smoothwall SSL login page

Staff (Wifi Key) - setup in smoothwall to treat all traffic from that IP range as generic staff

Sixth Form (Wifi Key) - setup in smoothwall to treat all traffic from that IP range as generic student user

 

The last two were setup because Staff and the Sixth Form kept getting annoyed with the SSL login page timing out so wanted to be able to login in once and have internet. However this makes it difficult to track who is looking at what as it logs as IPs rather than usernames in Smoothwall.

 

Is there anyway I can up an authentication method so that the users logs into a device once and then the system remembers the devices and the credentials, which can then be used to log them into smoothwall?

 

Hope that makes sense

[tom_newton]

Yes: you want 802.1x - this uses a username and password from AD instead of a passphrase, and is a one-shot deal per device (or until pw change). This can be used to seamlessly log into Smoothwall - and you can then have one SSID for everyone.

[mdench]

Yes: you want 802.1x - this uses a username and password from AD instead of a passphrase, and is a one-shot deal per device (or until pw change). This can be used to seamlessly log into Smoothwall - and you can then have one SSID for everyone.

 

I have set this up with Smoothwall as the Radius Server. I have added the AP / client in to the settings on Smoothwall and it allowed me to log into the wireless using some AD credentials but now when I tried to browse the internet. I get a "Your Connection is not private warning" and at the bottom it says "NET::ERR_CERT_AUTHORITY_INVALID"

 

Is there a step that I have missed or am I doing something wrong?

[tom_newton]

Have you changed the authentication method on the smoothie to "core auth" (meaning "someone else will tell me") for the wireless IP range?

[mdench]

Have you changed the authentication method on the smoothie to "core auth" (meaning "someone else will tell me") for the wireless IP range?

 

You sir are a god!

[mdench]

So now that I have working authentication can I use this to assign users to vlans based upon their membership so ideally i would like Students on a vlan staff on another. Looking through the help on Smoothwall I found " Filter-ID — This is an optional attribute, used to supply the authentication group of the user. Typically, the group assignment is used by Advanced Firewall when there is no directory service configured to use for group mapping"

 

So on our xirrus kit I can specify a group policy and a destination VLAN what to do I have to filled our in the boxes for it to match up to a group?

[mdench]

[mjk]

So now that I have working authentication can I use this to assign users to vlans based upon their membership so ideally i would like Students on a vlan staff on another.

 

Yes this is how we do it - but we don't do vlan assignments through smoothwall.

What we do is have the wireless controller configured to authenticate to a radius server that is a windows NPS. The NPS decides which vlan the student/staff should be on based upon their Active Directory group membership, it sends this information back to the wireless controller that assigns the vlan.The NPS server also sends an accounting packet to the smoothwall, the smoothwall uses this information to identify the user.

Edited April 15, 2015 by mjk

[mdench]

Yes this is how we do it - but we don't do vlan assignments through smoothwall.

What we do is have the wireless controller configured to authenticate to a radius server that is a windows NPS. The NPS decides which vlan the student/staff should be on based upon their Active Directory group membership, it sends this information back to the wireless controller that assigns the vlan. After this is complete the wireless controller then sends an accounting packet to the smoothwall, the smoothwall uses this information to identify the user.

 

I tried to originally configure our wireless to auth against a windows NPS however it kept returning incorrect username and password after adding the client to the list

[mjk]

I tried to originally configure our wireless to auth against a windows NPS however it kept returning incorrect username and password after adding the client to the list

 

Yes you will need to fix this first.

Remember that the wireless controller is the client in this context - you can auth them together with a shared secret. There should also be an connection request policy to allow users to connect (all days/times) and authenticate. After this is done you can add your network policies.

[mdench]

I have added the access point as a client into NPS (our wifi is cloud based so no controller)

 

I've created a connection request policy to allow then to connect all days / times

 

is there anything else I need to do?

[mjk]

So I don't have the PEAP in the "connection request" section; That bit is blank and goes in the network policy. In the connection request I have put "forward accounting requests to a remote RADIUS group instead (the smoothwall server). Earlier I mistakenly said that the wireless controller does this, now I see that it is indeed the NPS.

 

In the "Network Policies" section I then made a policy for EACH wireless network/vlan. for example:

 

Student-1 has:

 

conditions: called station ID (the SSID in this case)

Auth: PEAP/EAP

NAS port type: wireless 802.1x

windows group - DOMIAN\GROUPNAME ( ie match year 8 and go in yr8 VLAN)

NAS IPv4 address: Address of the wireless controller x.x.x.x.

 

 

Constraints I have: PEAP

 

then settings I put:

 

802.1x Tunnel-medium type = 802 (includes all 802 media plus ethernet)

802.1x Tunnel-private-group = the VLAN ID

802.1x tunnel-type= Virtual VLANS

 

 

clearly your wireless controller needs to be aware of what to do with these VLAN's

 

So the way it works is the NPS allows connections, sees something coming from the wireless controller, forwards the info to smoothwall, authenticates the user and matches them against an AD group then sends back the VLAN info to the controller which puts the user into the correct vlan.

Edited April 15, 2015 by mjk

[mdench]

Is there a log anywhere for the connection requests? I've setup the client, Connection Request and Setup a Network Policy just in case to test. But I keep getting back incorrect username or password when I try to log in. I have tried multiple user creds all the same

[mjk]

It's in "accounting" in NPS, you need to turn on logging first:

https://technet.microsoft.com/en-us/library/ee663944%28v=ws.10%29.aspx

 

Also find that Wireshark is good for this sort of thing.

[mdench]

So I have this working now for the most part! I can connect apple devices (iPhone, iPad, Mac) and android devices no issues but I can't connect any windows laptops... I can see the WiFi network and it prompts me to enter a username and password and then says unable to connect. Having checked the NPS logs I see a reason code = 265 which seems to link to

"The certificate that the user or client computer provided to NPS as proof of identity chains to an enterprise root certification authority that is not trusted by the NPS server"

 

A quick google got me a meraki site -> https://documentation.meraki.com/MR/Encryption_and_Authentication/Common_Wireless_RADIUS_Configuration_Issues

 

Root Certificate is not added to the client Device

On Windows end-user devices you have the option to validate the server certificate presented by the server when using WPA-2 Enterprise. If this option is selected, the Certificate Authority must be added to the client's list of Trusted Root Certification Authorities. If the Certificate Authority is added to the Windows Client you may see Event 6273 Reason Code 265 in the Network Policy and Access Services logs, see figure 10.

Options to resolve this include Pushing a root CA chain via GPO to client devices or Disabling Server Validation on your Windows Client.

 

A lot of our devices are going to be BYOD so I can't push a CA via GPO or be expected to disable an option on each Window machine. Any one got any ideas?

[mdench]

[psydii]

Publish your root cert public key on your website and get the students to download it from there? Some vendors have bespoke solutions to this problem.

[mdench]

Publish your root cert public key on your website and get the students to download it from there? Some vendors have bespoke solutions to this problem.

 

Could do but they would need the cert to be able to join the WiFi to be able to get our website and get the cert?

 

But why only Windows Machines? Everything else jsut connects the iPads and iPhones ask you to accept a certificate as part of the logon process.

[psydii]

Something to do with the way windows wireless connection service works I would guess.

[KEVIA]

Hi Mdench,

 

You "can't connect any Windows laptops" is you can't connect any Windows 7 laptops. Try a Windows 8 laptop and you'll find the problem doesn't exist. With windows 7 it seems you have to pre-add the wireless connection for that SSID. Make sure you set the correct wireless properties for the connection. I can try to provide a lil more help if needed.