For all scenarios in this paper, whether you are deploying IAS as a RADIUS proxy or IAS as a RADIUS server, you must configure IAS to be compatible with WPS technology by creating the EnableWPSCompatibility registry entry. When you configure and enable this registry entry, and then open a connection request policy profile in the IAS console, connection request policy user interface elements that allow you to configure Protected Extensible Authentication Protocol (PEAP) become visible.

To configure EnableWPSCompatibility

Open Registry Editor.

Browse to the following registry path:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesRemoteAccessPolicy

Right-click the Policy key, click New, and then click DWORD value.

A new value is added to the details pane, with the default name of the value highlighted for editing. Replace the default name by typing EnableWPSCompatibility, then press Enter.

Right-click on EnableWPSCompatibility, and then click Modify.

In Edit DWORD value, in Value data, change the integer to 1. The default value is 0 (disabled). All values other than 1 (enabled) are treated as 0 (disabled).

To verify that EnableWPSCompatibility is enabled

Open the IAS console.

Double-click on Connection Request Processing, and then click Connection Request Policies.

In the right pane, double-click the default connection request policy, named Use Windows authentication for all users, and then click Edit Profile. The Edit Profile dialog box opens.

On the Authentication tab, below Authenticate requests on this server, you can see the Protected EAP check box.

To verify that EnableWPSCompatibility is disabled

Open the IAS console.

Double-click on Connection Request Processing, and then click Connection Request Policies.

In the right pane, double-click the default connection request policy, named Use Windows authentication for all users, and then click Edit Profile. The Edit Profile dialog box opens.

On the Authentication tab, below Authenticate requests on this server, you cannot see the Protected EAP check box.

For additional IAS configuration steps, see the deployment scenarios in this paper.

If your organization is a WISP, you can deploy WPS technology using a VLAN-aware gateway device, such as an access controller, a VLAN-aware router, or a VLAN-aware switch. In this circumstance, network resources such as the provisioning server and the IAS server reside on a Network Resource VLAN, while access to the Internet is provided to customers who have established an account by switching them to an Internet VLAN.

In the sections that follow, the components of a WISP network using a VLAN-aware gateway device are described, how the components work together during a new customer sign-on are detailed, and how to deploy a WISP network with VLANs is explained.

This deployment scenario, designed for an ISP that deploys Wi-Fi hotspots as a WISP, has the following features:

A VLAN-aware gateway device is used for client computer isolation during the account sign-up process.

Customers sign up using a promotion code. Many organizations introduce new services through the use of promotional campaigns in which customers are provided with a special or discounted offer when they sign up for an account using a promotion or pre-paid code. This implementation of WPS technology depicts a WISP that uses promotion or pre-paid codes for a spontaneous customer sign-up at a Wi-Fi hotspot. The codes are stored in a database on a server running SQL Server 2000 or a third-party database application.

The following illustration depicts the components of a WISP network using a VLAN-aware gateway device for client computer isolation.

Components of a WISP network using VLANs

Following are the components that comprise the wireless local area network (WLAN):

Wireless client

A computer running Windows XP Home Edition with SP2, Windows XP Professional with SP2, or Windows XP Tablet PC Edition with SP2. The computer must be equipped with a wireless network adapter that provides support for IEEE standard 802.11, IEEE standard 802.1X authentication, and Wired Equivalent Privacy (WEP). Support for Wi-Fi Protected Access (WPA) is preferred, but not required.

Wireless access point (RADIUS client)

One or more wireless access points deployed on the WISP LAN with a wired connection to the access controller, VLAN-aware switch or router, or other gateway device.

The wireless access point is configured as a RADIUS client to the Internet Authentication Service (IAS) server deployed on the WISP LAN. The wireless access points used for WPS technology must meet the following requirements:

Support for the use of VLANs.

Support for the IEEE standard 802.1X authentication.

Support for Wi-Fi Protected Access (WPA) is preferred. WPA is supported by Windows XP with SP2. To deploy WPA, use wireless network adapters and wireless access points that also support WPA.

Support for RADIUS authentication and RADIUS accounting, including:

Support for the Class attribute as defined in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," to allow session correlation for RADIUS authentication and accounting records. For session correlation, when you configure RADIUS accounting at your IAS server or proxy, you must log all accounting data that allow applications (such as billing applications) to query the database, correlate related fields, and return a cohesive view of each session in the query results. At a minimum, to provide session correlation, you must log the following IAS accounting data: NAS-IP-Address; NAS-Identifier (you need both NAS-IP-Address and NAS-Identifier because the access server can send either attribute); Class; Acct-Session-Id; Acct-Multi-Session-Id; Packet-Type; Acct-Status-Type; Acct-Interim-Interval; NAS-Port; and Event-Timestamp.

Support for accounting interim requests, which are sent periodically by some access servers during a user session, that can be logged. This type of request can be used when the Acct-Interim-Interval RADIUS attribute is configured to support periodic requests in the remote access profile on the IAS server. The access server, in this case a wireless access point, must support the use of accounting interim requests if you want the interim requests to be logged on the IAS server.

Support for IP address range filtering.

Support for dynamic retransmit timeout (RTO) estimation or exponential backoff to handle congestion and delays in a wide area network (WAN) environment.

In addition, there are some filtering features that the access points must support to provide enhanced security for the network. These filtering options include:

DHCP filtering. The access point must filter on IP ports to prevent the transmission of DHCP broadcast messages in the instance that the client is a DHCP server. The access point must block the client from sending IP packets from port 68 to the network.

DNS filtering. The access point must filter on IP ports to prevent a client from performing as a DNS server. The access point must block the client from sending IP packets from port 53 to the network.

Following are the components that comprise the WISP LAN.

VLAN-aware gateway device

The VLAN-aware gateway device can be an access controller, a VLAN-aware router, a VLAN-aware switch, or any other device that can be configured to apply IAS-provided parameters to client connections. The VLAN-aware gateway device is configured with two VLANs: a Network Resource VLAN and an Internet VLAN.

The Network Resource VLAN allows all users access to the provisioning server and DHCP server. This VLAN grants access to network resources that allow customers to connect to your network as guest, create an account, receive provisioning information from the provisioning server, and pay for the account.

The Internet VLAN provides access to the Internet. Only customers who have created and paid for accounts are switched to this VLAN and granted Internet access. This process occurs when Windows XP reauthenticates the user with the newly created account information. When the user is authenticated and authorized by your IAS server, the IAS server returns attributes to the VLAN-aware wireless access point; the access point instructs the VLAN-aware gateway device to route client traffic to the Internet VLAN.

Provisioning server

The WISP provisioning server is configured with the following components.

HTTPS Web server

The Internet Information Services (IIS) or third-party Web server must be deployed with Secure Hypertext Transfer Protocol (HTTPS).

Web application

The WISP Web server is configured with an account processing Web application that processes data provided during customer sign-up or account renewal. When a customer uses the sign-up wizard on a client computer to create and pay for a WISP account, the customer enters data, such as name, address, and credit card information that is converted to an XML document on the client. Windows XP sends this XML document to the WISP provisioning server.

The account processing application on the provisioning server must be capable of accepting and processing the XML documents containing the user data. For example, the account processing application must compare the promotion code entered by the user to a promotion code in the SQL Server database, and then dynamically create an account in the Active Directory user accounts database with the properties (domain and security group membership) described in the database. The account processing application must also contain a credit card verification component to process customers' payment information. The account processing Web application must permit new customers to sign up and to permit existing customers to renew their subscriptions for service.

XML master file and subfiles

The WISP provisioning server stores the XML master file and subfiles that provide the client with all configuration information needed to access the network, create an account, pay for the account, and ultimately access the Internet. For more information about the XML master file and subfiles, see "XML schemas" in this paper.

Server certificate

For server authentication to client computers, the WISP provisioning server must maintain a valid certificate in its certificate store. The certificate must contain the Server Authentication purpose in Enhanced Key Usage (EKU) extensions and be issued by a public certification authority (CA), such as Verisign or Thawte, that is trusted by client computers. The Trusted Root Certification Authorities certificate store on computers running Windows XP is installed by default with a multitude of certificates issued by public CAs. You must obtain your server certificate from one of the public CAs for which clients already have trust. For more information, see "Server Certificate Requirements" in this paper.

In test lab deployments of WPS technology, you can deploy your own certification authority in lieu of using a public trusted root CA. In this circumstance you must install the private trusted root CA certificate on all clients used for testing so that the clients will trust the CA and so that your servers, such as your provisioning server and your IAS server, can be successfully authenticated by the clients.

Domain controller and IAS server

The WISP domain controller and IAS server is running Windows Server 2003, Standard Edition with SP1; Windows Server 2003, Enterprise Edition with SP1; or Windows Server 2003, Datacenter Edition with SP1, and is configured with the following components.

Active Directory

In this scenario, Active Directory is deployed. The user accounts database on the domain controller must be an Active Directory user accounts database or a database that uses Lightweight Directory Access Protocol (LDAP) and supports dynamic creation of user accounts.

When a customer signs up for an account, the account processing Web application on the provisioning server creates a new account in the user accounts database, and adds the user to a group that has clearly defined access privileges that match the type of account the customer purchased when signing up.

If you use an accounts database other than Active Directory, IAS authentication and authorization extensions must be written and installed for this process to function correctly.

Internet Authentication Service (IAS)

IAS is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy, and is used to authenticate and authorize users connecting to your network. IAS is configured with remote access policies that allow guest authentication for non-domain member computers and users. It is also configured to provide attributes to RADIUS clients (access points) that instruct the gateway device to apply the attributes to client connections. Protected Extensible Authentication Protocol (PEAP) with MS-CHAP v2 is configured on remote access policies as the authentication method used by wireless clients.

Extension DLL and URL PEAP-TLV

An IAS extension DLL defining a URL PEAP-TLV provides IAS with the ability to send the location of the provisioning server to client computers.

PEAP-Type-Length-Value (PEAP-TLV) is an Extensible Authentication Protocol (EAP) authentication type that allows the IAS server to pass information to client computers attempting to connect to your network.

In this circumstance, the value contained in the PEAP-TLV is an HTTPS Uniform Resource Locator (URL) that provides client computers running Windows XP with SP2 with the location of the WISP provisioning server. With this URL, Windows XP can download the WISP XML files to the client computer.

In addition to the URL of the provisioning server, the URL PEAP-TLV includes an action parameter. The action parameter directs Windows XP to perform a specific task.  The action parameter included in the URL PEAP-TLV defines tasks such as new customer sign-up, existing account renewal, and password change.

For more information, see "How to create an IAS extension DLL and a URL PEAP-TLV" in this paper.

Server certificate

To authenticate the IAS server to the wireless client computers using PEAP, the WISP IAS server must maintain a valid certificate in its certificate store. The certificate must contain the Server Authentication purpose in Enhanced Key Usage (EKU) extensions and be issued by a public CA, such as Verisign or Thawte, that is trusted by client computers. The Trusted Root Certification Authorities certificate store on computers running Windows XP is installed by default with a multitude of certificates issued by public CAs. You must obtain your server certificate from one of the public CAs for which clients already have trust. If you install IAS and Active Directory on the same computer, the computer must have a certificate. If you install IAS and Active Directory on different computers, only the IAS server needs a certificate.

SQL server

A computer running SQL Server 2000 or another SQL-compatible relational database application.

The promotion code database running on the SQL server is configured with the following fields: promotion code, user name, domain name, security group, and expiration date. With the exception of the user name field, each field for each record is preconfigured with a value. The value for the user name field is assigned by the Web application when a customer creates a user account with a promotion code that matches a value in the promotion code field in the database. By predefining the domain in which the user account is created by the Web application and the Active Directory security group to which the user account is joined as a member, you can assign network access and other permissions for your customers.

DHCP server

The DHCP server must be able to assign valid public IP addresses to computers accessing the network through the wireless access points.