none
Restricting wireless access to domain devices

    Question

  • Students at a school disrtict are logging in to the wireless with their personal devices. The students use the wireless password, which is visible in Windows 7 Enterprise in the adapter setting in plain text. We have been unable to restrict their access to the adapter settings in the Server 2008 domain. Trying to create a NAP policy applying only to the Domain Computers OU does not work; we had to add Domain Users, otherwise the computers fail to connect with a "certificate server not available" message. A certificate has been installed and is viewable on the device, all encryption and authentication methods are correct. We are looking for the best way to secure the wireless from non-domain devices. We are using Rukus APs with a Cisco 4400 WLC.
    Tuesday, January 10, 2012 6:53 PM

All replies

  • Hi Sandi Snow,

     

    Thanks for your post.

     

    According to your description, I assume that you are trying to restrict the non-domain clients to access wireless network. If so, please note that we can use NPS network policy to secure your wireless network. On the condition field of network policy, we can only allow specific computers or users to access the wireless network. As you said, if we add Domain Users on the condition, it means NPS only allow the client get wireless when domain user logs on. This will prevent all non-domain devices get authenticate by NPS server, and they cannot access to the wireless network. We can change the condition settings to fit our requirements.

     

    In addition, it is recommended to use wizard to create NPS policies. At the Wizard Specify User Groups area, add specific groups, only members of these groups will apply this policy, follow the constraints to determine whether can get access or not.  

     

    Create NPS Policies for 802.1X Wireless Using a Wizard

    http://technet.microsoft.com/en-us/library/dd183706(WS.10).aspx

     

     

    Best Regards,

    Aiden

    Thursday, January 12, 2012 3:08 AM
    Moderator
  • Aiden,

     

    Sorry for the misconception. It is not non-domain users but non-domain devices. We have the wireless configured to give access to the Staff for iPads and Smartphones but want to restrict Students from doing the same. When we create a policy denying access to non-domain devices, it does not allow domain devices to connect unless we add the Student OU to the policy. Then the students can connect with any device, not just domain devices. I will go through your link and make sure we are following all steps. Thank you and I'll post the result.

    Thursday, January 12, 2012 3:59 PM
  • Hello, Sandi - we are trying to do the same sort of thing in our school district. We have a high school and a middle school close together in our 'campus' environment and two remote elementary schools. At present, in the campus schools (and the district office) we're using Cisco lightweight WAPs and two WLCs which reside on a WiSM module in a 6500 core switch. We also have a 4400 WLC which handles the guest wireless traffic. The RADIUS server is a Cisco ACS box. What we've been able to do here is to use the 'enable machine authentication' option in the ACS to restrict access for non-domain devices; but I've since learned that what this is actually doing is restricting access to non-domain devices based on the OS being used. My understanding is that machine authentication is a Windows-only proposition and I'll confess that I don't know how it does what it does. What I do know is that a Windows computer that's in the AD database will pass machine authentication and then the user will be prompted for user authentication. A Windows box that's not in AD will fail machine auth and be re-directed to the webauth portal. Non-windows machines will not even be able to respond to the machine auth request because they don't support this functionality and so they will also be re-directed to the webauth portal.

    So far this is working well for us - but the day will come when some of these non-Windows devices are going to become domain computers (that's actually already happened) and so we won't be able to use Windows machine authentication as a means of keeping the non-domain computers off the secure WLAN.

    As far as I know, the only sure way of doing this is by using an EAP method like EAP-TLS or EAP-TTLS, which will require a certificate from the supplicant as well as from the authenticator. We're trying to find a different method that will be less complex to implement, but have had no luck thus far.

    At one of our elementary schools, we recently installed Aerohive APs. Aerohive's suggestion for secure guest access is to use pre-shared keys. We're hoping to find a method that doesn't involve any user interaction beyond just logging in as usual, so not sure if this will be our solution.

    I'd be very interested in hearing what techniques you're trying and what the results are.

    Jon Koelker

    Oyster River School Dist.

    Durham, NH

    Friday, January 13, 2012 8:09 PM
  • Jon,

    I am grateful for your response, since we seem to be dead in the water! We have tried PEAP and EAP, or MS-CHAP in a NAP policy, but unless Domain Users were included, the domain computers would not attach, though the certificate was on the local machine. Since it is a small district, I looked at locking down DHCP by mac address but this would be a constant battle. I will look into setting up a RADIUS server that has the "enable machine authentication"; the WLC does not.  But you are right, we have districts putting in iPad labs and there are probably more to come!

     

    sandi

    Wednesday, January 18, 2012 8:16 PM
  • If I understand your issues correctly you need to use the Windows Group in your Network Policies rather than users.  Add two group with an OR statement.  "Trusted Users OR Truested Computers".  Then add another condition for the Machine Groups for "Trusted Computers".  Now the the PC can login without a user and only trusted users on a trusted PC can login.
    Wednesday, January 18, 2012 10:45 PM