Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  


AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml

AspAutocadCDot netExcelFox proHtmlJava
LinuxMathcadPhotoshopPhpSqlVisual studioWindowsXml

WPS technology for an HSP with IP filters

windows

+ Font mai mare | - Font mai mic



WPS technology for an HSP with IP filters

If your organization is an HSP, you can deploy WPS technology by using IP filters for client computer isolation. In this circumstance, client computers are provided access to HSP and WISP network resources, such as provisioning servers and IAS servers, and IP filters block access to the Internet until the customer establishes a paid account. After the account is established, the IP filters are lifted, and traffic is allowed between the client computer and the Internet.




In the sections that follow, the components of an HSP network using IP filters are described, and how the components work together during new customer sign-up are detailed.

Components of WPS technology for an HSP network using IP filters

A Hotspot Service Provider (HSP) can deploy WPS technology with IP filters for client computer isolation during the account sign-up process.

The following illustration depicts the components of an HSP network using IP filters for client computer isolation.

Components of an HSP network using IP filters

This configuration consists of the following components.

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 wireless client connects to the HSP network, which is in a public location and is accessible to customers with portable computers and wireless network adapters.

Wireless access point (RADIUS client)

The wireless access point is configured as a RADIUS client to the IAS proxy server deployed on the HSP LAN. The wireless access points used by an HSP for WPS technology must meet the following requirements:

Support for the IEEE standard 802.1X authentication.

Support for Wi-Fi Protected Access (WPA) is preferred

The ability to implement client isolation by applying IP filters to the connection with the client.

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.

IP filters

IP filters that isolate client computers connecting as guest are configured in the remote access policy on the HSP IAS proxy server, and are applied to the client connection by the wireless access point. The IP filters must grant the client computer access to the provisioning server at the HSP and the WISP, and must block access to all other locations.



Router

The router must provide multiple ports for connection to access points, the HSP LAN, and the Internet or a WISP, depending on your configuration.

HSP LAN

The HSP local area network (LAN) consists of the following components.

Provisioning server

The HSP 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 HTTPS.

HSP XML master files

HSP XML master files are stored on the HSP provisioning server. Because an HSP can provide customers with a choice of Internet access plans with a variety of WISPs, one XML master file is configured at the HSP and stored on the HSP provisioning server for each WISP available to HSP customers. Each HSP XML master file contains a master XML schema that describes a list of URLs to other XML documents, which are XML subfiles stored on WISP provisioning servers. The XML master schema also describes properties of the WISP for which the XML master file was created and the Time-To-Live (TTL) for the XML master file before it is updated by the HSP provisioning server from the WISP provisioning server. The XML master file schema is:

The domain name of the WISP. For example, if Microsoft Corporation is the WISP, the domain name is “microsoft.com.”

The friendly name of the WISP. For example, Microsoft Corporation.

The TTL for the XML master file. When client computers connect to the HSP provisioning server and download the master file, the TTL value tells Wireless Provisioning Services on the client computer when to request an update of the master file from the HSP provisioning server.

The list of URLs that point to XML subfiles. The XML subfiles are located on the WISP provisioning server for which the XML master file was created. Only HTTPS URLs are supported for use within the XML schema, and by WISP provisioning servers. The name of the XML schema described in the subfile is included, as is the version number for the subfile. Possible subfile names include: Signup, SSID, EAP, Location, and Help. For more information, see “XML Schemas” in this paper.

Server certificate

For server authentication to client computers, the 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 connecting to the HSP wireless LAN. 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.

IAS proxy server

The HSP IAS proxy server is configured with the following components.

Internet Authentication Service (IAS)

The IAS proxy server must be a computer running Windows Server 2003, Standard Edition with Service Pack 1 (SP1); Windows Server 2003, Enterprise Edition with SP1; or Windows Server 2003, Datacenter Edition with SP1; and Internet Authentication Service (IAS). IAS is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) proxy and server.

The IAS proxy functions both as an IAS proxy and as an IAS server. The IAS proxy server is configured to locally process connection requests for users that authenticate as guest, and to forward non-guest authentication and accounting requests to the IAS servers located at individual WISPS based on the realm name configuration specified in Connection Request Policies in the IAS console.

On the IAS proxy, the IAS servers at each WISP are added to a remote RADIUS server group, with a minimum of one remote RADIUS server group created for each WISP. Because Windows Server 2003, Standard Edition, permits the creation of only two remote RADIUS server groups, an HSP offering Internet connectivity to more than two WISPs must deploy IAS proxies and servers running Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition.

Server certificate

For server authentication to client computers, the 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 connecting to the HSP wireless LAN. 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.



DHCP server

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

WISP 1 LAN

The WISP 1 LAN is configured with the following components.

Provisioning server

The WISP provisioning server is configured with the following components.

HTTPS Web server

Like the HSP Web server, the WISP Web server must use HTTPS. The WISP provisioning server stores XML subfiles that are downloaded over HTTPS by client computers running Windows XP with SP2.

Web application

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

The account processing Web application on the provisioning server must be capable of accepting and processing the XML documents containing the user data. For example, the account processing Web application must dynamically create an account in the Active Directory user accounts database, and must 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 subfiles

The WISP provisioning server maintains the XML 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 XML subfiles, see “XML schemas” in this paper.

Server certificate

For server authentication to client computers, the 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 connecting to the HSP wireless LAN. 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.

Domain controller and IAS server

The WISP domain controller and IAS server is configured with the following components.

Active Directory

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.

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

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 IP filters to RADIUS clients (access points) that apply the filters to client connections during guest authentication. IAS also provides unrestricted access to users with valid accounts.

Server certificate

For server authentication to client computers, the 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 connecting to the HSP wireless LAN. 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.

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 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 the client 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.

WISP 2 LAN

The WISP 2 LAN is identical to the WISP 1 LAN described above, and is depicted in  “Components of an HSP network using IP filters” to illustrate that an HSP can provide service offers to customers from multiple WISPs.






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 676
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2021 . All rights reserved

Distribuie URL

Adauga cod HTML in site