WPS Technology for a WISP with VLANs

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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.

Components of WPS technology with VLANs

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

Wi-Fi hotspot components

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.

WISP LAN components

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.

How a WISP works with VLANs

The Internet connection process using WPS technology with a VLAN-aware gateway device differs depending on whether the customer attempting to connect is a new customer or an existing customer. The following example describes the process for a new customer using a promotion code at a Wi-Fi hotspot location. In addition, the manner in which IAS handles an expired account is explained.

New customer connection example

When a new customer connects to a WISP and establishes an account, the following stages occur:

1. The customer discovers the WISP network at a Wi-Fi hotspot

2. The customer authenticates as guest

3. The client is provisioned and the customer establishes an account

4. The customer is authenticated with the new account credentials

5. The user is switched to a VLAN that provides Internet access

In the next section we will look at these stages in more detail.

1.  The customer discovers the WISP network at a Wi-Fi hotspot

When a customer arrives at the WISP Wi-Fi hotspot with a portable computer running Windows XP Home Edition with SP2, Windows XP Tablet PC Edition with SP2, or Windows XP Professional with SP2, the computer comes within range of the WISP access point beacon.

Wireless auto configuration on the client computer detects the beacon information from the access point, which is configured to broadcast the Service Set Identifier (SSID) of the WISP's network. The SSID is equivalent to the network name.

The customer is informed by Windows XP that a wireless network is available. In this example, the customer possesses a promotion code to use for account establishment, and proceeds by clicking Connect.

2.  The customer authenticates as guest

Wireless auto configuration uses 802.1X and PEAP guest authentication to connect to the WISP network through the access point, automatically passing a null user name and a blank password to the WISP IAS server. The access point is connected to a VLAN-aware gateway device that allows traffic from the client to pass through the Network Resource VLAN, but blocks the client from access to the Internet VLAN.

The IAS server is the PEAP authenticator and TLS endpoint for customers who connect as guest. The TLS tunnel is created between the wireless client and the IAS server. All subsequent messages between wireless client and IAS server pass through this tunnel, which traverses the access point and the gateway device.

Server authentication is performed when the IAS server verifies its identity to the client computer using a certificate that contains the Server Authentication purpose in Enhanced Key Usage (EKU) extensions. This certificate is issued by a public CA that the client computer trusts.

The IAS server authenticates and authorizes the customer as guest. In the Access-Challenge message that the IAS server sends to the client is a URL PEAP-TLV attribute. The URL PEAP-TLV message contains the URL of the provisioning server. This URL provides the client with the location of the XML master file.

The wireless client computer receives an IP address lease from the DHCP server. The address is from an IP address range configured in a scope on the DHCP server. In addition to the IP address, the client receives DHCP options, such as a default gateway and a DNS server IP address.

3.  The client is provisioned and the customer creates an account

The XML master file on the provisioning server contains pointers to the XML subfiles. The wireless client creates an HTTPS connection with the provisioning server and downloads the XML master file and subfiles. When the XML sign-up file is downloaded, the sign-up wizard is started on the wireless client to allow the customer to create and pay for an account with the WISP.

Using the sign-up wizard on the wireless client computer, the customer steps through the process of signing up for an account. The customer enters the promotion code as well as personal data such as name, address, and credit card number. The data entered by the customer is converted into an XML document.

The XML document containing the customer’s sign-up data is sent to the Web application on the WISP provisioning server.

The Web application checks the promotion code entered by the user against the promotion code database on the SQL server. If the promotion code is valid, the Web application continues processing the customer’s data.

The Web application processes the customer payment information. After payment is verified and sign-up information is completed successfully, the Web application reads the domain and security group information from the promotion code database on the SQL server and creates a user account in Active Directory and adds the account to the security group. The Web application also enters the new user name in the promotion code database.

An XML document containing the new account credentials is sent from the WISP provisioning server to the client computer. The client computer uses the credentials to configure wireless auto configuration and 802.1X under the name of the WISP.

4.  The customer is authenticated with the new account credentials

Wireless auto configuration restarts the association to the SSID for the WISP.

Wireless auto configuration finds the correct 802.11 profile, which was downloaded with the other WISP information. Wireless auto configuration re-associates with the access point using the correct profile.

802.1X restarts the authentication process using PEAP-MS-CHAP v2 and the new account credentials.

As the client starts the authentication process with PEAP-MS-CHAP v2 authentication, a TLS channel is created between the customer’s client computer and the WISP IAS server.

In the second stage of PEAP-MS-CHAP v2 authentication, the WISP IAS server authenticates and authorizes the connection request against the new account in the Active Directory user accounts database. The IAS server sends an Access-Accept message to the access point. Included in the Access-Accept message are attributes that specify which VLAN the customer can access.

5.  The customer is switched to a VLAN that provides Internet access

The access point instructs the gateway device to assign the client to the Internet VLAN rather than the Network Resource VLAN. In addition, 802.1X on the access point opens the virtual port to provide Internet access to the client.

The wireless client computer receives an IP address lease from the DHCP server. The address is from an IP address range configured in a scope on the DHCP server. In addition to the IP address, the client receives DHCP options, such as a default gateway and a DNS server IP address.

The wireless client computer can now access the Internet.

How IAS handles an expired account

You can determine the types of account plans that you want to offer your customers. These plans can range from fees based on hourly use to accounts with life spans as long as a day, a month, or longer.

It is important for IAS to determine whether a connecting or connected client computer has a valid account, and to take the appropriate action if the customer’s account is expired. The following example illustrates how IAS determines that a 24-hour account is current and how WPS technology behaves when the account expires.

Twenty-four hour connect option example

When the customer arrives at the WISP, the customer chooses an access account that has a one-day (24-hour) lifespan. The customer and client computer proceed through the account creation process described above, and then connect to the Internet. The following process occurs:

1. In the Access-Accept message sent by the IAS server, the IAS server sets a session timeout of 60 minutes for the client computer connection to the access point.

2. After 60 minutes, the access point requests that the client reauthenticate. The client reauthenticates successfully and the customer’s session is not interrupted.

3. Each 60 minutes thereafter, the access point requests that the client reauthenticate. During each authentication the IAS server checks the current time against the expiry time for the user account to discover whether the customer is authorized to access the network.

4. On the last re-authentication, at hour 23 in the account lifespan and before 24 hours have passed, the IAS authorization check fails and the IAS server sends a URL PEAP-TLV message to the client that contains the account renewal action parameter and an HTTPS URL for an XML master file. The URL PEAP-TLV supplies the customer with the location of the provisioning server where the customer can renew the account.

5. Upon receiving the URL in the URL PEAP-TLV message, 802.1X requests that Windows XP display the account renewal application to the customer.

6. The customer renews the account and 802.1X initiates authentication using the new account credentials.

7. During authentication with the IAS server, the IAS server authenticates and authorizes the customer against the user accounts database, and sends an Access-Accept message containing a session timeout of 60 minutes to the access point.

8. During this process, because the account has not expired, the customer maintains connection to the Internet.

If the customer does not complete the renewal process before the 24-hour account lifespan is reached, authentication fails and customer access to the Internet is terminated. When authentication fails, Windows XP attempts authentication as guest. The VLAN-aware gateway device is configured to allow the connection to the Network Resource VLAN, and the customer is provided with the option of renewing the account for continued access.

How to deploy WPS technology with VLANs

In the set of instructions that follow, these assumptions are made:

1. The computer functioning as your IAS/RADIUS server has Windows Server 2003 with SP1 installed, and the EnableWPSCompatibility registry key is enabled according to the instructions in “Configuring IAS for WPS technology” in this paper.

2. Client computers are running Windows XP Home Edition with SP2; Windows XP Professional with SP2; or Windows XP Tablet PC Edition with SP2.

3. All of your hardware, including the VLAN-aware gateway device and VLAN-aware wireless access points, meet all of the technical requirements stated in “Components of WPS technology with VLANs” in this paper.

4. You have already deployed a computer running SQL Server 2000 or a third-party database program on your network. For information about SQL Server 2000, see SQL Server at https://go.microsoft.com/fwlink/?LinkId=20014.

5. You have SQL Server 2000 or third-party relational database development experience and you understand how to use SQL Server 2000 or a third-party database program to create, modify, administer, and manage your databases.

6. You have experience deploying an Internet Information Services (IIS) or third-party Web server with HTTPS. If you are deploying IIS, you understand how to use Active Server Pages (ASP), and you can develop applications using Microsoft .NET Framework 1.1.

7. You have software development experience that allows you to create your custom Web application that will be installed and run on the provisioning server.

8. You have software development experience that allows you to create an IAS extension DLL.

To deploy WPS technology with VLANs, the basic steps are as follows:

1. Configure the domain controller and IAS server

2. Configure the DHCP server

3. Install and configure your VLAN-aware gateway device

4. Install and configure your wireless access points

5. Configure RADIUS clients in IAS

6. Create your Web application

7. Configure the provisioning server

8. Configure XML master and subfiles

9. Configure the database on the SQL server

10. Configure the Windows XP–based client computer

11. Configure certificates in a test lab environment (optional)

Configure the domain controller and IAS server

Install Windows Server 2003, Standard Edition with SP1; Windows Server 2003, Enterprise Edition with SP1; or Windows Server 2003, Datacenter Edition with SP1 on a computer that meets or exceeds the minimum hardware requirements for the respective operating system. After the operating system is installed, you can perform General configuration, Active Directory configuration, IAS configuration, and IAS extension DLL & URL PEAP-TLV configuration.

General configuration

1. Assign the server a static IP address. Determine the IP address range for the WISP LAN, and determine how many devices need static IP addresses from that range. For example, the domain controller and IAS server must have a static IP address, and it is generally a good idea to provide static IP addresses to other key servers, such as the DHCP server and WISP provisioning server. IP addresses that are statically assigned are excluded from distribution by a DHCP server through definition of an exclusion range on the DHCP server. The exclusion range falls at the beginning of the IP address range, so choose one of the addresses from the beginning of the range that you plan on excluding when you configure DHCP, and assign it to the domain controller by using Network Connections. For more information, see “To configure TCP/IP for static addressing.” At https://go.microsoft.com/fwlink/?LinkId=20015.

2. Install a server certificate obtained from a public trusted root certification authority, such as a certificate from Verisign.

   For more information, see “Obtaining and Installing a VeriSign WLAN Server Certificate for PEAP-MS-CHAP v2 Wireless Authentication” at https://go.microsoft.com/fwlink/?LinkId=33675.

   When you obtain the certificate, it must conform to the minimum server certificate requirements described earlier in this paper.

   For more information, see “Network access authentication and certificates” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20016.

Active Directory configuration

1. Install Active Directory and DNS. To install Active Directory, open Command Prompt, type dcpromo, and then follow the instructions provided in the wizard, entering your network configuration information in the wizard as you progress.

2. Design and create your security groups. When users sign up and create an account, your Web application adds the new user account as the member of a security group that you create in this step. The Web application chooses group membership based on the value of the security group field in the promotion code database on your SQL Server, so you need to match the security group you create to the security group field in the SQL server database. If you have the need for multiple security groups, you can assign permissions to each group individually. For more information, see “To create a new group” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20018 and “Assign user rights to a group in Active Directory” at https://go.microsoft.com/fwlink/?LinkId=20019.

   Important

   The security groups you create in Active Directory are named and used in the SQL Server database and in IAS remote access policy.

3. Enable the Guest account in Active Directory. If guest access is not enabled in Active Directory, new customers cannot access your provisioning server by authenticating as guest. To enable the Guest account, open the Active Directory Users and Computers snap-in, and then double-click Users. Right-click the account named Guest, and then click Enable Account.

To perform the next procedure, you must be a member of either the Domain Admins group in the domain for which you want to raise functionality or the Enterprise Admins group in Active Directory; or you must have been delegated the appropriate authority.

Raise the domain functional level to either Windows 2000 native or Windows Server 2003 by doing the following:

1. Open the Active Directory Domains and Trusts snap-in. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Domains and Trusts.

2. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level.

3. In Select an available domain functional level, do one of the following:

   1. To raise the domain functional level to Windows 2000 native, click Windows 2000 native, and then click Raise.

   2. To raise domain functional level to Windows Server 2003, click Windows Server 2003, and then click Raise.

The current domain functional level is displayed under Current domain functional level in the Raise Domain Functional Level dialog box.

For more information, see “Domain and forest functionality” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?linkid=30600.

For information about configuring Active Directory replication, see “Active Directory Replication” in this paper.

IAS configuration

For IAS, the three configuration stages are General configuration, Remote access policy configuration, and Connection request policy configuration. (RADIUS client configuration occurs later in the overall WISP deployment process.)

General configuration

1. Install Internet Authentication Service.

   For more information, see “To install IAS” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20028.

2. Register IAS in Active Directory. In order for IAS to have permission to read user accounts in Active Directory, IAS must be registered in Active Directory.

   For more information, see “To enable the IAS server to read user accounts in Active Directory” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20030.

3. Delete the default remote access policies. To delete the policies, open the IAS console, and then click Remote Access Policies. Select each existing policy, right-click the policy, and then click Delete.

4. Create your IAS extension DLL. For more information, see “How to Create an IAS Extension DLL and a URL PEAP-TLV” in this paper.

5. Install the DLL on your IAS server and configure DLL registry keys according to your needs.

   To install your DLL, do the following:

   • Open Command Prompt and change directories to the folder that contains your DLL.

   • Type the following: regsvr32DLL_name.dll, where DLL_name.dll is the name of your DLL file.

Remote access policy configuration

There are two remote access policies configured for WPS technology. The Guest access policy provides network parameters and rules for users connecting as guest. The Valid Users access policy provides network parameters and rules for users who have valid WISP accounts.

To configure the Guest access policy

1. Open the Internet Authentication Service console and, if necessary, double-click Internet Authentication Service.

2. In the console tree, right-click Remote Access Policies, and then click New Remote Access Policy.

3. Use the New Remote Access Policy Wizard to create a policy. For the WISP guest access policy, you can choose the following:

   1. For How do you want to set up this policy? select Use the wizard to set up a typical policy for a common scenario.

   2. For Policy name, type Guest access (or type another name for your policy that you prefer).

   3. For Select the method of access for which you want to create a policy, click Wireless.

   4. For Grant access based on the following, click User.

   5. In Select the EAP type for this policy, select Protected EAP (PEAP), and then click Configure.

   6. In Certificate issued, select the certificate that you want the IAS server to use to verify its identity to client computers. Also select the Enable Fast Reconnect check box.

After you have completed creating the policy and have closed the wizard by clicking Finish, you need to perform additional policy configuration.

1. In the IAS console, click Remote Access Policies, and then double-click the policy you just created. Make the following configuration changes to the policy:

2. In the policy Properties dialog box, for Policy conditions, click Add.

3. In Attribute Types, click Day-And-Time-Restrictions, and then click Add. In Time of day restraints, select Permitted, configure the days and times that access is permitted, and then click OK.

4. In the policy Properties dialog box, click Grant remote access permission.

5. Click Edit Profile. On the Authentication tab, in Unauthenticated access, click Allow clients to connect without negotiating an authentication method.

To configure the Valid Users access policy

1. Open the Internet Authentication Service snap-in and, if necessary, double-click Internet Authentication Service.

2. In the console tree, right-click Remote Access Policies, and then click New Remote Access Policy.

3. Use the New Remote Access Policy Wizard to create a policy. For the WISP Valid users access policy, you can choose the following:

   1. For How do you want to set up this policy? verify that Use the wizard to set up a typical policy for a common scenario is selected.

   2. For Policy name, type Valid Users (or type another name for your policy that you prefer).

   3. For Select the method of access for which you want to create a policy, click Wireless.

   4. For Grant access based on the following, click Group, and then click Add. In Enter the object name to select, type the name of a security group that you defined when configuring Active Directory. For example, if you created a group named Valid Users, type Valid Users, and then click OK.

      Important

      The following three items must match: the name of the security group in Active Directory, the value of the security group field in the SQL Server database, and the name of the security group configured in the Valid Users access policy in IAS. The Web application uses the value of the SQL Server database security group field to determine group membership for new accounts.

   5. In Select the EAP type for this policy, select Protected EAP (PEAP), and then click Configure.

   6. In Certificate issued, select the certificate that you want the IAS server to use to verify its identity to client computers. Also check the Enable Fast Reconnect check box.

After you have completed creating the policy and have closed the wizard by clicking Finish, you need to perform additional policy configuration.

1. In the IAS console, click Remote Access Policies, and then double-click the policy you just created. Make the following configuration changes to the policy:

2. In the policy Properties dialog box, for Policy conditions, click Add.

3. In Attribute Types, click Day-And-Time-Restrictions, and then click Add. In Time of day restraints, select Permitted, configure the days and times that access is permitted, and then click OK.

4. In the policy Properties dialog box, click Grant remote access permission.

5. Click Edit Profile, and then click the Advanced tab. By default, the Service-Type attribute appears in Attributes with a value of Framed. To specify additional connection attributes required for WPS technology with VLANs, click Add, and then add the following attributes:

   • Framed-Protocol. Value: PPP

   • Tunnel-Medium-Type. Value: 802 (Includes all 802 media plus Ethernet canonical format)

   • Tunnel-Pvt-Group-ID. Value: Enter the integer that represents the VLAN number for the Internet VLAN. For example, if your access controller’s Internet VLAN is VLAN 4, type 4.

   • Tunnel-Type. Value: Virtual LANs (VLAN)

   • Tunnel-Tag. Value: Obtain this value from your hardware documentation

Connection request policy configuration

By default, there is one connection request policy predefined in the IAS console, called Use Windows authentication for all users. This policy can be used for WPS technology.

1. In the IAS console, double-click Connection Request Processing, click Connection Request Policies, and then double-click the policy Use Windows authentication for all users.

2. Click Edit Profile. The Edit Profile dialog box opens.

3. On the Authentication tab, click Authenticate requests on this server, and then check the Protected EAPcheck box.

4. Click Configure Certificate. Select the certificate you want IAS to use to authenticate to clients, and then click OK three times to close all dialog boxes and return to the IAS console.

Configure the DHCP server

On a computer running Windows Server 2003:

1. Install DHCP.

   For more information, see “To install a DHCP server” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20034.

2. In the DHCP console, run New Scope Wizard twice. Create two VLAN scopes from which IP addresses will be leased to wireless clients connected to the VLANs. Each scope must define a different IP address range using either a private address range or a public IP address range. If you are using network address translation (NAT), you can use a private IP address range; otherwise, the IP addresses leased to wireless clients must be from a public IP address range.

   For more information, see “To create a new scope” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20123.

3. While running New Scope Wizard, create an exclusion range for the IP addresses you will be assigning statically. For example, if you need to statically assign 10 IP addresses from the address range 10.1.1.1 through 10.1.1.254, your exclusion range is defined as 10.1.1.1 through 10.1.1.10.

4. While running New Scope Wizard, assign scope options. On the Configure DHCP Options page, select Yes, I want to configure these options now. Scope options are applied only to leases of addresses from within the IP address range that the scope defines, which provides flexibility as your network grows. Define the DNS server and Domain name options, as well as any other options that are appropriate for your network configuration.

5. While running New Scope Wizard, activate the scope. The option to activate the scope while running the wizard is available only if you have chosen to configure DHCP scope options in the previous steps.

   For more information, see “To activate a scope” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20124.

6. Authorize the DHCP server in Active Directory.

   For more information, see “To authorize a DHCP server in Active Directory” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20125.

The DHCP server is now online and able to provide IP address leases to client computers. In some cases you might want to examine the types and durations of accounts you offer your customers and adjust the DHCP lease duration accordingly. In most cases when deploying WPS technology, the default lease duration of eight days is too long and should be shortened considerably.

DHCP example

In this example, you are creating two VLANs and two scopes, one scope for each VLAN.

VLAN 2

VLAN 2 is the Network Resource VLAN that provides access to network resources (such as the IAS server and DHCP server) for wireless computers connecting as guest. VLAN 2 blocks access to the Internet, however. The DHCP scope for VLAN 2 is defined with the following example parameters:

• Address range: 192.168.1.1 through 192.168.1.254. This is a private IP address range. If you are using NAT, you can use this range on your network. If you are not using NAT, use a public IP address range. In addition, if your wireless deployment is large, select an IP address range that provides more IP addresses for lease to clients.

• Exclusion range: 192.168.1.1 through 192.168.1.10. By using this exclusion range, the available address pool for clients is 192.168.1.11 through 192.168.1.254. Ten IP addresses are excluded so that you can statically assign these addresses to computers and devices on your network. For example, the router IP address must be statically assigned on the router.

• DHCP scope option 003, Router: 192.168.1.1. The router IP address must be an address that falls within the exclusion range so that the DHCP server does not lease the router IP address to a wireless client computer, thereby creating an address conflict.

• DHCP scope option 006, DNS server: the IP address of the Active Directory and DNS server on the WISP LAN.

Note that DHCP scope option 003, Router, provides client computers with the IP address of their default gateway IP address. In this case, the default gateway for wireless clients is the VLAN-aware gateway device, whether it is an access controller, a VLAN-aware router, a VLAN-aware switch, or another compatible device. When you configure your VLAN-aware gateway device, you can specify the IP address that the device uses for each VLAN.

In this example, you must configure the VLAN-aware gateway device so that it uses the IP address 192.168.1.1 on VLAN 2.

For your WPS deployment you can configure additional DHCP options as needed. For example, if you are using a WINS server, you can configure your VLAN scopes with DHCP option 044, WINS/NBNS Servers.

VLAN 4

VLAN 4 is the Internet VLAN that provides access to the Internet. Users who have successfully created an account are switched to this VLAN after completing the provisioning and sign-up process. The DHCP scope for VLAN 4 is defined with the following example parameters:

• Address range: 192.168.2.1 through 192.168.2.254

• Exclusion range: 192.168.2.1 through 192.168.2.10

• DHCP scope option 003, Router: 192.168.2.1. The router IP address must be an address that falls within the exclusion range so that the DHCP server does not lease the router IP address to a wireless client computer, thereby creating an address conflict.

• DHCP scope option 006, DNS server: the IP address of the Active Directory and DNS server on the WISP LAN.

For VLAN 4 in this example, you must configure the VLAN-aware gateway device so that it uses the IP address 192.168.2.1 on VLAN 4.

Install and configure your VLAN-aware gateway device

Configure two VLANs on the gateway device: a Network Resource VLAN that provides access to the WISP LAN, and an Internet VLAN that provides access to the Internet.

The remote access policies you create in IAS determine which VLAN your customers can access:

• The Guest access policy places users on the Network Resource VLAN so that they can create and pay for a valid user account.

• The Valid Users access policy in IAS places customers on the Internet VLAN.

Each VLAN has a different IP address range. When configuring your DHCP server, you created a scope for each VLAN, and you defined DHCP scope option 003, Router. This is the IP address commonly referred to as the “default gateway.”

You must configure the VLAN-aware gateway device as the default gateway for each VLAN, using an IP address from the IP address range that you defined on your DHCP server.

Choosing the IP address for the default gateway for each VLAN

Your VLAN-aware gateway device is the default gateway for both VLANs and is configured with a different IP address for each VLAN.

After you define an IP address range for a VLAN on your DHCP server, you can use any IP address from that range as the IP address for the default gateway. To prevent an IP address conflict, however, exclude some IP addresses from the range for use by devices that you want to configure with a static IP address. When you create an exclusion range for an IP address range, the DHCP server does not lease IP addresses from the exclusion range to DHCP clients.

Thus ensure that you assign an IP address from the exclusion range as the IP address for the default gateway. The address you use does not need to be the first address in the exclusion range, but it must be an address contained within the exclusion range.

In accordance with the example provided in the DHCP configuration section of this paper, configure the VLAN-aware gateway device so that it uses an IP address from the exclusion range 192.168.1.1 through 192.168.1.10 for VLAN 2. For example, you can configure the VLAN-aware gateway device so that it uses the IP address 192.168.1.1 on VLAN 2.

Similarly, as described in “Configure the DHCP server” in this paper, configure the VLAN-aware gateway device so that it uses an IP address from the exclusion range 192.168.2.1 through 192.168.2.10 for VLAN 4. For example, you can configure the VLAN-aware gateway device so that it uses the IP address 192.168.2.1 on VLAN 4.

In some circumstances you might prefer to use your VLAN-aware gateway device as the DHCP server for each VLAN. If this is the case, you must define IP address ranges and exclusion ranges on the VLAN-aware gateway device rather than on a DHCP server.

See the product documentation for your VLAN-aware gateway device for information about configuring your hardware.

Install and configure your wireless access points

Following is an example of how to configure your wireless access points for use with WPS technology. This example depicts configuration of a Cisco 802.1X–compatible access point. If you use a different 802.1X–compatible access point, follow the directions in your product documentation and in “Using other access points” in this paper.

The Cisco access point used in this example provides a Web-based interface for access point configuration. To use this interface for access point configuration, you must physically connect the access point to the network, log on to a computer that has network connectivity to the access point, and then open a Web browser, such as Microsoft® Internet Explorer.

Type the IP address for your 802.1X–compatible access point in the Web browser address bar, and then press ENTER. The access point configuration page appears in the Web browser.

To configure your wireless access point

1. On the configuration page, click the Setup tab, and then click Express Setup.

2. In the Radio Service Set ID (SSID) field, type an SSID for the access point, and then click OK.

3. Under Services, click Security, and then click Radio Data Encryption (WEP).

4. On the AP Radio Data Encryption page, select the Open check boxes for the Accept Authentication Type and the Require EAP options, and then clear all other check boxes.

5. In the Encryption Key box, type a 32-digit WEP key. In the Key Size list, select 128 bit, and then, to update the page, click Apply.

6. In the Use of Data Encryption by Station is list, select Full Encryption, and then click OK.

7. On the Security Setup page, click Authentication Server. The following table shows the values to set on the Authenticator Configuration page.

   Item	Value
   802.1X Protocol Version (for EAP Authentication)	Draft 10
   Server Name/IP	IAS server IP address
   Server Type	RADIUS
   Port	1812
   Shared Secret	Type the shared secret you want to use for RADIUS clients
   Timeout (in seconds)	20
   User server for	EAP Authentication

8. When you have completed the configuration of the authentication server, click OK.

Using other access points

If you are using an access point (AP) other than Cisco, follow the directions in your access point documentation using the following guidelines:

• Authentication or RADIUS server: Specify your IAS server by IP address or FQDN, depending on the requirements of the AP.

• SSID: Specify a Secure Set Identifier (SSID), which is an alphanumeric string that serves as the network name. This name is broadcast by APs to wireless clients and is visible to users at your Wi-Fi hotspots.

• RADIUS settings: Use RADIUS authentication on User Datagram Protocol (UDP) port 1812 and use RADIUS accounting on UDP port 1813.

• Secret or shared secret: Use a strong shared secret and configure the IAS server with the same shared secret.

• EAP: Configure the AP to require EAP from wireless clients.

• 802.1X and WEP: Enable IEEE 802.1X authentication and WEP.

Configure RADIUS clients in IAS

In the IAS console, add each access point on your network as a RADIUS client. In addition, configure the shared secret used between the access points and the IAS server. For more information, see “To add RADIUS clients” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20031 and “To configure the Message Authenticator attribute and shared secret” at https://go.microsoft.com/fwlink/?LinkId=20032.

Configuring RADIUS clients by IP address range

If your IAS server is running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, you can configure RADIUS clients by IP address range. This is a useful feature when you have a large number of access points to deploy; if you deploy your access points on the same subnet or VLAN within the same IP address range, configuration of RADIUS clients in IAS is simplified. Instead of individually configuring each access point as a RADIUS client in IAS, you can configure all access points at once using the IP address range of the subnet or VLAN upon which the APs reside. In this circumstance, use the same shared secret for all access points, and make sure that the shared secret is strong.

By contrast, you can configure IAS in Windows Server 2003, Standard Edition, with a maximum of 50 RADIUS clients. You can define a RADIUS client using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. With Windows Server 2003, Standard Edition, if the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the IAS server uses the first IP address returned in the DNS query. With IAS in Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, you can configure an unlimited number of RADIUS clients.

Create your Web application

Your Web application must be capable of performing the following functions:

• Communicating with Wireless Provisioning Services using HTTPS.

• Uploading XML master file and subfiles that are stored on the provisioning server to client computers that request the files.

• Accepting and processing XML documents from client computers that contain customer data, such as promotion code, customer name, customer address, and other information.

• Accepting and processing XML documents from client computers that contain credit card information. This includes verifying the credit card and charging the customer account.

• Reading the promotion code database records to validate promotion codes.

• Reading the promotion code database records to determine the domain in which to create a new user account.

• Reading the promotion code database records to determine the security group membership for a new user account.

• Writing a user name to the user name field in the promotion code database.

• Dynamically creating new accounts in Active Directory (or a third-party LDAP-compliant database) using data provided by customers as well as parameters from the promotion code database.

It is recommended that the design of your Web application provides customers with knowledge of their user name and password. Customers can either be allowed to designate their own user name and password or this information can be provided to them upon completion of the sign-up wizard. Following are some circumstances where customers need to know their password-based credentials:

• For a variety of reasons, user authentication might fail. For example, cached credentials might get corrupted or network connectivity issues might prevent wireless client computers from successfully authenticating.

• The user account expires and the customer wants to renew their account. In this circumstance, IAS sends a URL PEAP-TLV to the wireless client that contains the renewal action parameter and the URL of the provisioning server. After the wireless client is directed to your account renewal application, the customer must have their password-based credentials to renew their account.

If your customers know their user name and password, they can attempt to connect to your network until they are successful. If they do not have this information, they cannot fix the problem without calling your help desk.

You can create your Web application with the Microsoft .NET Framework 1.1 or with other application development software. If you want to create your Web application with the .NET Framework 1.1, you need the Microsoft .NET Framework 1.1 Software Development Kit.

Microsoft .NET Framework 1.1 Software Development Kit

Microsoft .NET Framework 1.1 Software Development Kit (SDK) includes .NET Framework 1.1, as well as everything you need to write, build, test, and deploy applications using .NET Framework 1.1. This includes documentation, samples, command-line tools, and compilers.

If you have already installed Microsoft® Visual Studio® .NET, you do not need to install .NET Framework 1.1 SDK separately; Visual Studio .NET includes the SDK. If you want to distribute .NET Framework 1.1 with your application, download .NET Framework 1.1 Redistributable in addition to the SDK.

You can get .NET Framework 1.1 SDK from the Download Center at https://go.microsoft.com/fwlink/?LinkId=17161. You can run .NET Framework 1.1 SDK on the following platforms:

• Windows Server 2003

• Microsoft Windows 2000 (Service Pack 2 is recommended)

• Windows XP Professional or Windows XP Home Edition (Windows XP Professional is required to run ASP.NET)

Configure the provisioning server

For the provisioning server, if you are using Internet Information Services (IIS), do the following:

1. Install Internet Information Services and ASP.NET.

   For more information, see “To install Internet Information Services (IIS) 6.0” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20033.

2. Verify that you have .NET Framework 1.1 installed by clicking Start on your Windows desktop, selecting Control Panel, and then double-clicking the Add or Remove Programs icon. When that window appears, scroll through the list of applications. If you see Microsoft .NET Framework 1.1 listed, the latest version is already installed and you do not need to install it again.

   1. If Microsoft .NET Framework 1.1 is already installed: register ASP.NET with Microsoft .NET Framework 1.1 by running the following command at Command Prompt:

      %WINDIR%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe –I

   2. If Microsoft .NET Framework 1.1 is not installed: Install .NET Framework 1.1. You can install .NET Framework 1.1 through Microsoft Windows Update at https://go.microsoft.com/fwlink/?LinkId=284 or you can see the MSDN topic “How to Get the .NET Framework 1.1” at https://go.microsoft.com/fwlink/?LinkId=116211.

3. Create two folders in the Web server root location %systemroot%\Inetpub\wwwroot. You can use one folder to hold your custom Web application and one folder to hold the XML master and subfiles that you will be creating in later steps. For example, you can create a folder named wpsdeploy (%systemroot%\Inetpub\wwwroot\wpsdeploy) to contain your Web application, and you can create a folder named wpsfiles (%systemroot%\Inetpub\wwwroot\wpsfiles) to contain your XML files.

4. Install your Web application into the folder you created for the Web application files.

5. Set user permissions for the Web application. Open Windows Explorer and browse to the location where you installed your Web application. For example, if you named your folder wpsdeploy, browse to %systemroot%\Inetpub\wwwroot\wpsdeploy. Right-click the wpsdeploy folder, and then click Sharing and Security. On the Security tab, click Add. In Enter the object names to select, type Everyone, and then click OK. In Permissions for Everyone, enable Write permissions by checking the Allow check box.

6. Enable HTTPS. You must configure IIS to use a certificate for secure Web communications between the provisioning server and clients. To enable HTTPS you must install a server certificate obtained from a public trusted root certification authority, such as a certificate from Verisign or Thawte. When you obtain the certificate, it must conform to the minimum server certificate requirements described in this paper.

   For more information, see “Network access authentication and certificates” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20016.

   To enable Secure Sockets Layer (SSL) and HTTPS, complete the following procedures.

To obtain a new server certificate using Web Server Certificate Wizard

1. In IIS Manager, expand the local computer, and then expand the Web Sites folder.

2. Right-click the Web site or file that you want, and then click Properties.

3. On the Directory Security or File Security tab, under Secure communications, click Server Certificate.

4. In Web Server Certificate Wizard, click Create a new certificate.

5. Complete Web Server Certificate Wizard, which will guide you through the process of requesting a new server certificate.

To install a server certificate using Web Server Certificate Wizard

1. In IIS Manager, expand the local computer, and then expand the Web Sites folder.

2. Right-click the Web site or file that you want, and then click Properties.

3. On the Directory Security or File Security tab, under Secure communications, click Server Certificate.

4. In Web Server Certificate Wizard, click Assign an existing certificate.

5. Complete Web Server Certificate Wizard, which will guide you through the process of installing a server certificate.

Configure XML master and subfiles

There are two methods you can use to create and configure your XML master and subfiles:

• Use the WPS Authoring Tool to create a WPS project and publish your XML files. The WPS Authoring Tool has a graphical user interface and is designed to assist you in accurately producing and managing a collection of XML files for your WPS solution. For more information, see “Using the WPS Authoring Tool” at https://go.microsoft.com/fwlink/?LinkId=41067. Using the WPS Authoring Tool to create your XML data files is recommended. You can download the WPS Authoring Tool at https://go.microsoft.com/fwlink/?LinkId=40535.

• Use the XML schemas provided in this paper to create your files. After you have created these files, you can enter information specific to your network and deployment parameters. For example, where the location of the provisioning server is required, you can provide an HTTPS URL. In another example, you may need to enter your domain name in several places; you can examine the schemas and example files and determine where to insert your domain name.

When your XML files are configured with the information for your organization, you can store them on your provisioning server and configure your Web application so that it can find the files when necessary. If you are using Internet Information Services as your Web server, you can install the files at the location %systemroot%\inetpub\wwwroot.

Configure the database on the SQL server

On the computer running SQL Server 2000 or a third-party product with similar functionality, create a promotion code database with the following fields, using the appropriate data type for each field:

• Promotion code. This field contains promotion codes that you distribute publicly to potential customers. When customers sign up for an account, they provide the promotion code that is matched by the Web application to a value in this field in the database.

• User name. This field has no value assigned until a customer creates an account. At this time, the Web application assigns a value to this field.

• Domain name. This field contains the domain name where you want the Web application to create the user account when a customer signs up using the promotion code.

• Security group. The Web application joins the new user account to the security group defined in this field.

• Expiration date. If your promotion lasts for a specific period of time, you can enter the expiration date related to the promotion code in this field. If a user with a promotion code attempts to create an account after the expiration date for the promotion, they cannot do so.

Populate the database with records, providing values for all fields except user name, and enable the data link between your Web application and the SQL server. Also configure security and authentication on the SQL server so that your Web application has permission to access and write to the database. For more information, see SQL Server at https://go.microsoft.com/fwlink/?LinkId=20014.

Configure the Windows XP-based client computer

On the computer running Windows XP Professional, Windows XP Tablet PC Edition, or Windows XP Home Edition, install SP2. The computer must have a wireless network adapter compatible with IEEE 802.11 and 802.1X.

Configure certificates in a test lab environment (optional)

If you are deploying WPS technology in a test lab, you can obtain server certificates from a public trusted root CA or you can deploy Certificate Services for Windows Server 2003 on your test network. To deploy Certificate Services and enroll certificates to domain member computers (such as the servers on your networks), do the following:

1. On a computer running Windows Server 2003, install Certificate Services.

   For more information, see “To install an enterprise root certification authority” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20035.

2. Add a server certificate template to the certification authority and configure the certification authority to allow computers to request a certificate that is based on the template you create.

   For WPS technology in a test lab environment, you must create a server certificate that will be trusted by client computers. The server certificate must meet the requirements stated in “Server Certificate Requirements” in this paper.

   In addition, you must base your certificate on the correct certificate template for the operating system you are running. If you are running an enterprise certification authority (CA) on a computer running Windows Server 2003, Standard Edition, and your IAS server is a domain member, base your certificate on the Computer certificate template. If you are running an enterprise certification authority (CA) on a computer running Windows Server 2003, Enterprise Edition, and your IAS server is a domain member, base your certificate on the RAS and IAS Server certificate template.

   For more information, see “To create a certificate template” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20036.

3. Autoenroll certificates to domain member computers. Autoenrollment allows domain member computers to automatically obtain, or enroll, certificates. For WPS technology, autoenroll certificates to servers using the certificate template you created in the previous step.

   For more information, see “Planning for autoenrollment deployment” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20037 and “Checklist: Configuring certificate autoenrollment” at https://go.microsoft.com/fwlink/?LinkId=20038.

4. Install the enterprise CA certificate in the Trusted Root Certification Authority certificate store on client computers being used for testing purposes. You can request the enterprise root CA certificate by using Web enrollment services, which is installed with Certificate Services, or you can export the server certificate to a floppy disk, and then import the certificate into the Trusted Root Certification Authority certificate store on the client.

   For more information, see “To export a certificate” in Help and Support Center for Windows Server 2003 or on the Web at https://go.microsoft.com/fwlink/?LinkId=20039 and “To import a certificate” at https://go.microsoft.com/fwlink/?LinkId=20040.