Microsoft IAS, Apple Airport, Mac OS X and Vista

The lack of documentation on this particular combination was discouraging, but the need was pressing so we set about trying to use Microsoft IAS (Internet Authentication Server) to provide the RADIUS infrastructure for our growing collection of Apple Airport base stations.

The players

ITAdmin, the NICAI IT team

Rogue-d, a general purpose Windows 2003 server. Hosts the IAS service.

dns-server, the primary domain controller for CREATIVE and host for the enterprise CA.

nicai-84d1e, an early 2009 model Airport Extreme base station.

ITAdmin's MacBook, an early 2009 model MacBook running Mac OS X

ITADMINSMACBOOK, an early 2009 model MacBook running Vista Enterprise Edition (win32).

The dream

We wanted easy to rollout and manage, secure wireless network access with high speed connectivity and the ability to reach resources on the inside of the campus firewall.

Essentially, an arrangement connecting our local directory to any number of Apple airports to deliver wireless access for a heterogenous mix of wireless clients.

Building it, the idealised step by step...

Configuring the enterprise

An enterprise CA (certification authority)

To support PEAP or EAP-TLS variants of authentication for securing communications between wireless clients, the wireless access points, the RADIUS server and the hosting directory, you need to supply a certificate for the IAS server. The local implementation involved setting a policy in the active directory to allow automatic certificate allocation for computers in the domain.

Configuring policy on dns-server:

See http://technet.microsoft.com/en-us/library/cc781869.aspx

This wiki assumes you already have an enterprise CA (as we did). If you need to set one up, see

http://technet.microsoft.com/en-us/library/cc776709.aspx

The process is fairly straightforward and involces installing the certifcate services on a domain member and handing this server the enterprise CA role -something that should not be done too lightly.

Once the automatic allocation policy is in place, you should see certificates being issued to member computers of the domain.

This approach has many advantages, the main one being that computer identification via RADIUS between hosts in the domain can be automated -ie. no technical fiddling required. This means that computers that are members of a domain can join wireless networks without the configuration steps required for other computers (see below).

This automation is also subject to management through central policy. This allows a lot of flexibility for access and authorisation permutations.

It is possible to use other certificates issued by external authorities, this discussion is beyond the scope of this wiki entry. The Microsoft articles on deploying IAS server go into this in some depth.

Updating dns-server for Vista/Server 2008 clients

Some wireless clients, non Windows systems and Windows systems that are not members of the domain hosting the IAS and enterprise CA, require manual installation of the public part of the root certificate for the enterprise to avoid certificate issues when connecting to a base station managed through the IAS service being deployed here.
The easiest way to do this is through a web interface provided by the CA itself.

The enterprise CA for the CREATIVE domain is hosted in a Windows 2003 server. For Vista and Server 2008 clients to acquire certificates via Internet Explorer or some other web client the web pages hosting the certificate service on dns-server, needed to be updated.

http://support.microsoft.com/kb/922706/

Configuring IAS

IAS is one of the many network services available in Windows Server. If it is not already configured, you can add it through the Windows Components wizard accessed via the Add or Remove Programs control panel.

(Note. You do not need DHCP which is included in the services provided by rogue-d)

We ended up with IAS and another service management tool called Routing and Remote Access. The latter seems to be superfluous for this exercise.

Rogue-d installed and ran this service without needing to restart.

Adding a RADIUS client

Out of the box, Windows 2003 server supports hosting up to 50 RADIUS clients. For the local implementation this means we can mange 50 wireless access points off each server! Adding these involves two steps. Create am entry for each access point in the RADIUS clients area of the IAS tool, then configure the RADIUS client with the same settings.

Creating or adding a RADIUS client involves right clicking on the RADIUS Clients folder and selecting New RADIUS Client... Enter a common name and an IP address, specify a Client type and then add a shared secret. We used the name of the Airport as the common name (makes it easier to find these things later), entered the IP address of the device, selected RADIUS standard from the various device types available and typed in a long and reasonably complex password.

Adding a Remote Access policy

Remote Access policies can be used to gate access. We added a simple one associating a group in the local active directory with wireless access and granting the combination permission to access the network.

The process is documented by Microsoft on the technical articles pages indicated above. Our remote access policy grants remote access when the following conditions are both met

AND

This policy as inserted before the default policies Microsoft delivers with IAS -these basically block access. When a client connects, the request is evaluated down the list of policies until access is granted or denied. The default policies catch anything other policies might not deal with.

Policies could be written for individual access points or users if such a requirement existed.

Some fiddliness is involved in configuring the Profile associated with this policy. The following general settings worked for us.

Authentication set to MS-CHAP v2, and the EAP method set to Protected EAP (PEAP). The MD5-Challenge shown below is a left over of previous experimentation:

Encryption turned up full!:

IP assignment handled by someone else:

and this left as it was found:

Configuring the base station

The Airport Extreme base station was configured with an IP address and set to function as a NAT router for clients through it. This particular model can deliver 802.11b/g and 802.11a connectivity simultaneously and can also support 802.11n clients (over either the 2.x or 5.x GHz bands).

Setting Radio Mode to 802.11a/n - 802.11b/g allowed the WPA/WPA2 Enterprise wireless security options. Selecting this security option activated the Configure RADIUS button, which when pressed revealed the following panel.

The details in this panel should match the ones configured on the IAS server. After entering these and pressing the Update button, the base station restarts and the wireless access point should now be communicating with the IAS server.

At this stage it should be possible to join wireless clients to the network advertised by the access point using the authentication method and authorisation specified in the IAS Remote Access Policy.

Watching the system log on the IAS server can be useful for debugging connectivity issues. When we initially set the IAS server up, we were seeing weird bounces that lead us to investigate issues with our enterprise CA -it transpired that the root certificate had expired. Regenerating a new root certificate magically fixed everything else. As a note, the default lifetime of a root certificate generated for itself by the enterprise CA  is 5 years.

Configuring clients

The process can be a little tricky on some systems, but there were no insurmountable technical issues with the wireless clients we tried. The key steps involved:

Sort out certificates

Because the certificates used to secure wireless access are generated and signed by a local authority, most computer systems will not trust the certificate to validate identity without some action by the user. The wireless client needs to trust the certificates being used for the services to work properly.

There are two approaches available:

OR

The latter option is more future proof (for at least 5 years ;-), but the first option provides a quick and dirty alternative. From the short experimentation we have done, Vista requires the second option, Mac OS X allows either approach.

Some walkthroughs of the process of installing the root certificate are documented in separate wiki areas:

These should be considered step 1 for any client connection process. ie. something to be done before connecting to the wireless network.

WPA2 Enterprise

Authenticate using domain credentials