Managing Wireless Clients.

In part 1 and part 2, I showed you how to set up your access point to authenticate to a Microsoft Radius server. Judging by the overwhelming positive response, I'm going to add a little more information on this setup, how to make it more secure and perhaps a little easier to manage. And for those waiting for the TLS tutorial, I'm afraid that's not in the cards at this time...

The first step is to ease the management of your wireless users. Setting properties individually in a number of users' profile is obviously not the way to go. The best way to manage this is by adding a (security) group called "Wireless Users" (or something similar of your choosing), and then use this group when determining who gets to log in via wireless or not. In part 1, I mentioned that the user needed to have the "Allow Access" set for "Remote Access Permission" in the Dial-in tab of the user properties. This is not necessary when using groups to define the access. Rather than setting it to "Allow Access", it should remain at the default "Control Access through Remote Access Policy".

Next step in setting up access by groups is to change the settings in the IAS policy that allows wireless connections. Under Policy conditions, simply click the Add button and pick the "Windows-Groups" and then simply select the group or groups that are allowed to connect using this policy. Another change from part 1 is that the settings have been changed from "Deny" to "Grant" in this window.

Now, by adding and removing users from the "Wireless Users" group, you can allow or deny access to the wireless network.

Another condition that is shown on this image is the "Client-IP-Address" condition. If you have only one wireless access point, you can enter it's IP address in here. This will prevent any rogue access points from being included in the policy. If you have more than one access point, you can group them together in the Radius client properties, which will give them all the same Friendly name. You can then use the Client-Friendly-Name condition to specify that only access points with a matching Friendly name can use this policy. You can also use pattern matching to specify the IP addresses of a group or range of access points.

With the access policy, you can also put more restrictions on wireless access, including the times when people may connect. In the picture on the right, I've checked of the "Allow access only on these days and at these times", and defined the time that is allowed to connect to the network. By clicking on the Edit button, you get the same old "day and time" selection that has been around since at least Windows NT 4, if not even earlier. It's a simple grid with days and hours, and you can make selections and change blocks and ranges to be either allow or deny. In the image, the selection is 8AM to 8PM for weekdays, so no access would be allowed on the wireless network outside of that range.

Also on the same tab, you can set idle-timeout. With the above settings, the client will be disconnected from the network after 15 minutes of idle-time. Personally, I don't see much point in setting this on a wireless network. One could argue that if someone where to leave their laptop for a few (10-15 minutes), that someone else could use this to gain unauthorized access to the network. Requiring a password to unlock a screensaver would solve that problem, and that is something that can be configured via group policies. Either way, forcing a disconnect after a given time period would not prevent anyone from using the laptop to connect to the network. As soon as the client start talking the network again, the client would automatically re-authenticate using the cached credentials. And according to this article: http://support.microsoft.com/default.aspx?scid=kb;en-us;823731, it is not possible to configure Windows to not cache these credentials. So, your best bet is to leave this unchecked, and rely on password protecting your screen savers. Thanks to Kendall at DeVry University for providing that link.

And, the "Allow access only through these media" setting at the bottom of that previous image is redundant. Since that is also specified in the "Policy Condition" up on top, it shouldn't be necessary here.

On the client side, there isn't many changes to make. One thing that I didn't do in part 2, was to set the server name of the Certificate Authority to check the certificate with. It's a simple fix, really. Just check the "Connect to these server:" box, and enter the fully qualified domain name of your CA server.