|
|
Configuration Example - AIR-AP1220B
[Last Updated: Monday, 20-Oct-2008 22:24:50 EDT]
The goal of your wireless setup should, obviously, be to primarily provide
good connectivity with consistent acceptable signal strength in all the areas you
need to use it. However, There are alot of bad people, nosy people, and "freeloaders"
out there who'd like to use your connectivity for free to do things you might not
approve of or want happening on your network. So, in order to protect access to and
the use of your network, you need a sufficiently strong method(s) of authentication
and sufficiently strong encryption to protect your personal data and information. You
have to also balance this with ease of use and client configuration. If it is
difficult for legitimate clients
to connect using standard wireless clients and drivers, then you need to rethink your
approach. Unfortunately, there are a myriad of protocols and methods for achieving
these requirements which is thoroughly confusing to the average user. Some are highly
compatible and easy to configure and others are less compatible and harder to setup.
Hopefully I can clear up a little of the confusion around these configurations so you
can provide acceptable protection levels along with a straightforward and more
compatible client configuration.
Most access points on the market today provide at a minimum WEP, WEP
128, WPA, and possibly WPA2 support. WEP or Wired Equivalent Privacy was one of
the first authentication and encryption schemes for WiFi networks. Being that it was the
first, it was naturally full of protocol weaknesses and algorithm vulnerabilities. Do
not use WEP or WEP 128 if possible. It is fairly trivial for anyone with half a clue
to crack it and gain access.
WPA or WiFi Protected Access was created in response to the weaknesses
found in WEP. In its original form it is a fairly secure protocol and provides
support for pre-shared key solutions (PSK) as well as more advanced 802.1x
authentication methods such as EAP, EAP-TLS, and PEAP and uses the TKIP encryption
algorithm. Pretty much all access points on the market since 2003 support this
option. WPA2 is the second iteration and a more complete protocol implementation. It also
provides for the use of the Advanced Encryption Standard (AES) CCMP algorithm which is
considered to be the most advanced encryption protocol publicly available. This option is
mostly only available on access points and network cards sold from 2006 to present.
All current products on the market that are marked with by the WiFi
Alliance are required to provide support for WPA2.
Personally, I have configured 3 different VLANs with 3 different SSIDs
for wireless access on my home network. The primary SSID requires WPA2 with AES and
uses PEAP with EAP-TLS for 802.1x user authentication via a local Radius server on my
network. I also created a wireless Voice segment which uses WPA2 with AES and
pre-shared key (PSK). Finally, I have a guest VLAN which uses WPA2 with AES and a
pre-shared key for access and also provides fallback to WPA with TKIP envryption.
Warning: Aironet Extensions
One comment of note is that the Cisco Aironet access points have a
default wireless interface configuration that enables the proprietary Aironet
extensions. If you have client devices or drivers that do not support these extensions
or have strict implementations, they will not work with this setup. You must
explicitly disable these extensions for those clients to be able to properly
authenticate and gain access. Issue the command 'no dot11 extension aironet'
globally on the main Radio interface to do this.
Enabling Beacon SSID Broadcast
Additionally, many devices that have Wifi capability included expect
the SSID information to be broadcast as part of the normal Beacon. Without an SSID
name in the Beacon, many devices just ignore it. You may be required to explicitly
configure the SSID name onto the device to use the network. This will usually take
longer for the device to associate to the network and gain access. Some devices also
lose this information when they are powered off and rebooted. That can be an extreme
pain in the butt for client configuration. As the SSID name can be easily discerned,
anyway, from active user traffic, there is really no real reason to not advertise the
SSID name with the beacon, unless you just don't want the particular name to just show
up on nearby client machines available wireless networks list. Hence, the suggestion
is to use a sufficiently vague SSID name that does not clearly identify to whom the
network belongs or is associated. Cisco IOS, by default, does not advertise the SSID
name in the beacon messages. In order to broadcast the SSID name, the command
'guest-mode' must be configured explicitly under the relevant SSID configuration.
Radio Configuration
One of the tricker things to setup is which radio frequency to use, which speeds to enable,
and what power settings. Each of these can affect performance and device compatibility. There
is a ton of math and science involved in this topic. I will not go into that detail here. My
goal is to make this easy to read and use for anyone.
Frequency
For frequency configuration, Cisco provides a beautiful shortcut trick. If you
login to the command line and go to the dot11radio interface mode, you issue the command
'channel least-congested'. This automatically scans all the available frequency channels 1
through 11 (US) and finds a channel that has the fewest access points assigned and the
least amount of signal interference.
Speed
The speed configuration has a myriad of possibilities. If you are only
supporting 802.11b, this limits the options. However, if you intend to support both
802.11b and 802.11g or 802.11a, the configuration can be a little trickier. The options are
endless. What speeds do you really need to offer at a minimum to be flexible and support the
largest variety of client devices without going overboard and configuring everything?
Personally I have both the b and g radios installed in my access point. However, if you
support both b and g clients simultaneously, the drawback is that actual data throughput
will tend to drop off to 11Mbps. So in order to ensure maximum throughput up to 54Mbps, it is
best to configure using the Orthogonal Frequency Division Multiplexing (OFDM) rates which will
enforce that only 802.11g clients can associate. 'speed basic-6.0 basic-9.0 basic-12.0
basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0'
Power
Setting your radio to maximum power will certainly work but it will also advertise your
network at greater distances and provide the ability for others outside your home or office
to have the ability to associate to your network from greater distances. The trick here is to
reduce the power settings and then to walk around your home or office and test with a laptop
and a software client like Network Stumbler. You will be able to determine the optimal power
setting so that you can successfully connect where you need to but also limit the distance
that you broadcast your signal.
Configuration Overview
The following is a configuration example taken from my own personal Cisco Aironet AP1220B
Wireless Access Point that I use at home. When I get a chance I will add a list of
detailed comments on the relevant portions. I ran into a lot of headaches trying to
properly configure the 802.1x method along with the various encryption options and client
settings as well as the use of local RADIUS authentication.
The information supplied in this configuration is in no
way guaranteed to work in every situation nor supported by the author.
This document is meant to provide an example of general Wireless
configuration practices. The ! signifies a commented line in Cisco's
notation. Non-commented lines are the actual configuration syntax as it
would be entered on the Cisco Access Point.
Using an integrated Intel 2200BG wireless card with the
Intel PROSet/Wireless client application, I was able to login to my access
point on VLAN3 with the following parameters:
- Network Authentication: Open
- Data Encryption: AES
- Mandatory WPA2 with a sufficiently long pre-shared key
I want to use Cisco PEAP or EAP-TLS for 802.1x
authentication. However, these features are only supported on full blown
RADIUS server implementation. Using the local RADIUS authentication
within the AP limits the available EAP options supported. It seems that
you can only run EAP, LEAP, and EAP-FAST with the local RADIUS
implementatation. Out of the 3, EAP-FAST would be the best recommendation.
The other 2 options are not considered to be equivalently strong implementations.
I finally installed FreeRadius on my Linux server and was able
to get PEAP/EAP-TLS working properly using CACERT signed SSL certificates. Below I
have included a good step-by-step tutorial of this
configuration. Also, here are some offsite links to other good articles covering this
implementation:
Go To Configuration
DISCLAIMER
No Warranty of any kind is expressed or implied with respect to the information contained in this document!
The information found here is compiled for the convenience of anyone looking for general guidelines and best practices for configuration based on my own professional experience, as well as industry standards.
Use this information at your own risk!
Scott S. 2007
Example Configuration for the Cisco AP1220B Access Point
version 12.3
service nagle
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone year
service password-encryption
service sequence-numbers
!
hostname w5418-ap1
!
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxx
!
clock timezone EST -5
clock summer-time EDT recurring
clock save interval 24
ip subnet-zero
no ip source-route
ip domain name thewaystation.com
ip name-server 192.168.x.x
ip name-server 4.2.2.1
!
!
ip ssh time-out 30
aaa new-model
!
!
aaa group server radius rad_eap
server 192.168.x.x auth-port 1812 acct-port 1813
!
aaa authentication login default local
aaa authentication login eap_methods group rad_eap
aaa authentication login mac_methods local
aaa authorization exec default local
aaa accounting network acct_methods start-stop group rad_acct
aaa session-id common
dot11 activity-timeout client default 3600
!
dot11 ssid external
vlan 3
max-associations 10
authentication open
authentication key-management wpa
guest-mode
wpa-psk ascii 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
!
dot11 ssid internal
vlan 1
max-associations 2
authentication open eap eap_methods
authentication network-eap eap_methods
authentication key-management wpa
!
dot11 ssid voip
vlan 2
max-associations 2
authentication open eap eap_methods
authentication network-eap eap_methods
authentication key-management wpa
!
dot11 phone
!
!
username user privilege 15 password 7 xxxxxxxxxxxxxxxxxxxxxxx
!
bridge irb
!
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm tkip
!
encryption vlan 1 mode ciphers aes-ccm tkip
!
encryption vlan 3 mode ciphers aes-ccm tkip
!
encryption vlan 2 mode ciphers aes-ccm tkip
!
broadcast-key vlan 1 change 3600
!
broadcast-key vlan 3 change 3600
!
broadcast-key vlan 2 change 3600
!
ssid external
!
ssid internal
!
ssid voip
!
speed basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0
no power client local
station-role root
rts threshold 2312
payload-encapsulation dot1h
no dot11 extension aironet
no cdp enable
dot1x reauth-period 1800
!
interface Dot11Radio0.1
encapsulation dot1Q 1 native
no ip route-cache
no cdp enable
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface Dot11Radio0.2
encapsulation dot1Q 2
no ip route-cache
no cdp enable
bridge-group 2
bridge-group 2 subscriber-loop-control
bridge-group 2 block-unknown-source
no bridge-group 2 source-learning
no bridge-group 2 unicast-flooding
bridge-group 2 spanning-disabled
!
interface Dot11Radio0.3
encapsulation dot1Q 3
no ip route-cache
no cdp enable
bridge-group 3
bridge-group 3 subscriber-loop-control
bridge-group 3 block-unknown-source
no bridge-group 3 source-learning
no bridge-group 3 unicast-flooding
bridge-group 3 spanning-disabled
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
hold-queue 160 in
!
interface FastEthernet0.1
description Wireless Internal Secure Trunk
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
!
interface FastEthernet0.2
description Wireless VoIP Trunk
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
no bridge-group 2 source-learning
bridge-group 2 spanning-disabled
!
interface FastEthernet0.3
description Wireless External Trunk
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
no bridge-group 3 source-learning
bridge-group 3 spanning-disabled
!
interface BVI1
ip address 192.168.x.x 255.255.255.0
no ip route-cache
!
ip default-gateway 192.168.x.x
ip http server
ip http authentication local
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
ip radius source-interface BVI1
!
logging trap notifications
logging origin-id hostname
logging 192.168.x.x
snmp-server community xxxxxx RO
snmp-server enable traps tty
!
radius-server attribute 32 include-in-access-req format %h
radius-server host 192.168.x.x auth-port 1812 acct-port 1813 key 7 xxxxxxxxxxxxxxxxxxxxxxx
radius-server vsa send accounting
!
control-plane
!
bridge 1 route ip
!
!
banner login ^C
Unauthorized Use Is Prohibited
Access to this device or attached networks is expressly
prohibited without express written permission.
Violators will be prosecuted to the fullest extent
of both civil and criminal law.
^C
banner motd ^C
Welcome to w5418-ap1.thewaystation.com!
All activity is logged and audited.
^C
!
line con 0
exec-timeout 0 0
timeout login response 120
password 7 xxxxxxxxxxxxxxxxxx
logging synchronous
terminal-type ansi
length 40
transport preferred none
line vty 0 4
exec-timeout 15 0
timeout login response 120
password 7 xxxxxxxxxxxxxxxxxx
logging synchronous
terminal-type ansi
length 40
transport input telnet ssh
line vty 5 15
!
sntp server 192.168.x.x
end
DISCLAIMER
No Warranty of any kind is expressed or implied with respect to the information contained in this document!
The information found here is compiled for the convenience of anyone looking for general guidelines and best practices for configuration based on my own professional experience, as well as industry standards.
Use this information at your own risk!
Scott S. 2007
Courtesy of jbibe on
DSLReports:
FreeRADIUS/WinXP Authentication Setup
This post describes how to build a FreeRADIUS server for TLS and PEAP authentication, and how to configure the Windows XP clients (supplicants). The server is configured for a home (or test) network.
Three papers have been written about TLS authentication with a FreeRADIUS server:
1) www.missl.cs.umd.edu/wireless/eaptls 2) www.freeradius.org/doc/EAPTLS.pdf 3) www.denobula.com
These papers provide an excellent background, but are somewhat out of date. Where appropriate, I will simply refer to these documents rather than repeating the information. I recommend that you follow the steps I give below rather than the steps in these documents.
In the steps below, I give examples from the FreeRADIUS server that I installed yesterday in my Red Hat 9 computer. If you follow this example, please make the needed changes to the names of the files. I installed the FreeRADIUS and OpenSSL files in special local directories. This ensures that there is no interaction between the base Linux files and the new files. It also allows you to easily remove all of the newly installed files.
One word of caution: Be prepared for some frustration. The FreeRADIUS and OpenSSL snapshots used in constructing the server are beta software. Don't be surprised if you encounter some problems.
1. Download and Install OpenSSL and FreeRADIUS
The first step is to download and install the latest snapshot versions of OpenSSL and FreeRADIUS.
a. OpenSSL -- Download the latest OpenSSL-0.9.7-stable snapshot. I downloaded the OpenSSL snapshot to my home directory. The snapshots are located at:
»ftp://ftp.openssl.org/snapshot/
Then I used the following nine steps:
mkdir -p /usr/src/802/openssl cd /usr/src/802/openssl cp /home/jbibe/openssl-0.9.7-stable-SNAP-20040202.tar.gz \ openssl-0.9.7-stable-SNAP-20040202.tar.gz
gunzip openssl-0.9.7-stable-SNAP-20040202.tar.gz tar xvf openssl-0.9.7-stable-SNAP-20040202.tar cd openssl-0.9.7-stable-SNAP-20040202
./config shared --prefix=/usr/local/openssl make make install
That completes the work with OpenSSL, except for building the required certificates.
When you perform the config, make, and make-install here and in the FreeRADIUS install described below, I recommend that you log the information. For example, instead of using the simple "make" command, use:
make > mymake.log 2>&1
If you encounter problems, you can review mymake.log (or myconfig.log, or myinstall.log) for errors.
b. FreeRadius -- Download the latest FreeRADIUS snapshot. Again, I downloaded the file to my home directory. The snapshot is located at:
»ftp://ftp.freeradius.org/pub/radius/CVS-snapshots/
Then I used the following nine steps:
mkdir -p /usr/src/802/radius cd /usr/src/802/radius cp /home/jbibe/freeradius-snapshot-20040203.tar.gz \ freeradius-snapshot-20040203.tar.gz
gunzip freeradius-snapshot-20040203.tar.gz tar xvf freeradius-snapshot-20040203.tar cd freeradius-snapshot-20040203
./configure --with-openssl-includes=/usr/local/openssl/include \ --with-openssl-libraries=/usr/local/openssl/lib \ --prefix=/usr/local/radius make make install
That completes the work with FreeRADIUS, except for building certificates, making the changes to the FreeRADIUS configuration files, moving the server certificates to their final location, and building a wrapper for radiusd.
2. Produce Certificates
Server and client certificates are needed for TLS and PEAP. To produce the required certificates, I recommend that you use CA.all that is included with FreeRADIUS. CA.all uses the configuration information in openssl.cnf.
a. openssl.cnf -- Update openssl.cnf for your configuration. The configuration file is located at:
/usr/local/openssl/ssl
A portion of the information from my openssl.cnf is given below. (The company information is does not describe an actual company located in Brentwood, TN.) Note that the configuration information includes the password "whatever". It is the certificate password.
When CA.all executes, it uses this information three times. The first pass through this information produces the root certificates. If you set up your configuration as shown below, you will be able to accept all of the settings in the first pass. The second pass through this information produces the client certificates. You only need to change the commonName to the client name. In my case, I changed the commonName to jbibe. The third pass through this information produces the server certificates. You only need to change the commonName to the server name. In my case, I changed the commonName to micron.
----- Example -------------------------------------------
... # req_extensions = v3_req
# The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code) countryName_default = US countryName_min = 2 countryName_max = 2
stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Tennessee
localityName = Locality Name (eg, city) localityName_default = Brentwood
0.organizationName = Organization Name (eg, company) 0.organizationName_default = Helava
organizationalUnitName = Organizational Unit Name organizationalUnitName_default = Engineering
commonName = Common Name (eg, YOUR name) commonName_max = 64 commonName_default = HAI
emailAddress = Email Address emailAddress_max = 40 emailAddress_default = ohb@cmcast.net
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 challengePassword_default = whatever
unstructuredName = An optional company name
---------------------------------------------------------
b. CA.all -- Update the CA.all script for your requirements. The file is located at:
/usr/src/802/radius/freeradius-snapshot-20040203/scripts
If you use the default password "whatever", you only need to verify that the path in the script points to the installed openssl information. No changes should be necessary, but there is one gotcha. At about line 30, the path will probably be in error. Look for the following line and update the path as needed.
echo "newreq.pem" | /usr/local/openssl/ssl/misc/CA.pl -newca
When CA.all executes, it produces nine certificates:
root.pem, root.p12, root.der cert-clt.pem, cert-clt.p12, cert-clt.der cert-srv.pem, cert-srv.p12, cert-srv.der
For TLS and PEAP, the server needs root.pem and cert-srv.pem. For TLS, the Windows XP client needs root.der and cert-clt.p12. For PEAP, the Windows XP client needs root.der.
In the event that you want to use TLS authentication with multiple clients, Document 3 provides the needed script. Look for the CA.clt script in Section 6.
3. Configure Server for TLS
There are only a few changes and additions needed for TLS authentication. The clients.conf, users, and radiusd.conf are located at:
/usr/local/radius/etc/raddb
a. clients.conf -- This file contains the basic configuration for the Access Point. Look for the following line then uncomment and modify as appropriate:
#client 192.168.0.0/24 {
client 192.168.1.0/24 { secret = AP_Shared_Secret shortname = WLAN }
b. users -- This file contains the basic user information. Look for the following line and then add the user name:
#"John Doe" Auth-Type := Local, User-Password == "hello" #
jbibe
Note that for TLS, you should not include an Auth-Type or a password. The server is able to determine the correct Auth-Type, and a password is not needed because the client uses a client certificate for authentication.
c. radiusd.conf -- This file contains the server configuration information. Look for the following lines and then change the default_eap_type from md5 to tls:
eap { default_eap_type = md5
Change md5 to tls.
Move down to the following line, and then uncomment and modify the information, as shown below. Note that I placed the server certificates, dh file and random file in a new directory 1x on my system. Modify the path as needed for your server:
#tls {
tls { private_key_password = whatever private_key_file = /usr/local/radius/etc/1x/cert-srv.pem certificate_file = /usr/local/radius/etc/1x/cert-srv.pem CA_file = /usr/local/radius/etc/1x/root.pem dh_file = /usr/local/radius/etc/1x/dh random_file = /usr/local/radius/etc/1x/random fragment_size = 1024 include_length = yes }
No other changes are needed in radiusd.conf for TLS.
d. Server Certificates, DH File, and Random File -- I added a new directory 1x in the radius etc directory, and then copied the server certificates (root.pem and cert-srv.pem) into the directory. Finally, I used the following trick to produce dh and random:
openssl gendh >> dh dd if=/dev/urandom of=random count=2
e. Run-Radius -- The only server addition remaining is wrapper for radiusd. I added a new file run-radius in the /usr/local/radius/sbin directory. The script is from Document 3:
----- Wrapper Script ------------------------------------ #!/bin/sh -x
LD_LIBRARY_PATH=/usr/local/openssl/lib LD_PRELOAD=/usr/local/openssl/lib/libcrypto.so
export LD_LIBRARY_PATH LD_PRELOAD
/usr/local/radius/sbin/radiusd $@ ---------------------------------------------------------
After entering and saving the script, make run-radius executable:
chmod u=rwx run-radius
The server is complete.
4. Install Windows XP Certificates and Setup Client for TLS
The Windows XP certificates need to be installed, and client needs to be configured. I recommend that you follow Raymond McKay's example in Document 3, Section 10, XP Client (Supplicant) Setup. When this step is complete, the client is ready.
5. AP Setup
The AP configuration needs to be modified. This is the setup I used with my ZyXEL B-1000v2. (I assume that the B-1000 has been configured previously to use WEP keys and MAC addresses.)
At the wireless 802.1x tab:
Wireless Port Control = Authentication Required ReAuthentication Timer = 1800 seconds Idle Timeout = 3600 seconds Authentication Database = RADIUS only Dynamic WEP Key Exchange = 128-bit WEP
At the RADIUS tab for authentication:
Active = Yes Server IP = 192.168.1.10 Port Number = 1812 Shared Secret = AP_Shared_Secret
6. Test TLS
The final step is to test the server. With Windows XP computer off, start the server in the debug mode by entering:
/usr/local/radius/sbin/run-radius -X -A
The server should start, displaying various debug information before it displays:
----- Example --------------------------------------------
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp. Ready to process requests
----------------------------------------------------------
If you don't see the message, look through the debug information for errors and missing information. If you see this message, start the Windows XP computer.
When the Windows XP starts, you will see various messages and certificates exchanged between the client and the server. If all is well, you should see the client authenticated and the user logged on. The following partial example is from Document 3. It shows the last few lines of a successful authentication:
----- Example --------------------------------------------- ... MS-MPPE-Recv-Key = 0xe032765ca06c052e5fe7c2a7534a4252daec44a08505bdb459d4 fa81e70390f2221d2b06071eb0625e0ba67452a890909662 MS-MPPE-Send-Key = 0xe03131ce085bc266127528e749bd4753d3e1702df2d4d8c080351 380f52eae2c24a9fa78015c24e0d140bcd01b23d6c0cacc EAP-Message = "\003_\000\004" Message-Authenticator = 0x00000000000000000000000000000000 Finished request 5 Going to the next request -----------------------------------------------------------
If you see MS-MPPE-Recv-Key and MS-MPPE-Send-Key, the server authenticated the client. You should be able to surf.
7. Change Server Configuration for PEAP
To change the server for PEAP authentication, only a few changes need to be made.
a. users -- Return to the users file and add the user password:
jbibe User-Password == "My-XP-Password"
b. Radiusd.conf -- Return to the radiusd.conf file and make the following changes:
Change the default_eap_type from tls to peap:
eap { default_eap_type = peap
Move to the PEAP section below the TLS section and uncomment the following lines:
peap { default_eap_type = mschapv2 }
The server is now ready for PEAP authentication.
8. Change Windows XP for PEAP
On the Wireless Network tab, select the network and click Configure to open the network properties. Then
Select the Authentication tab Select Protected EAP on the drop-down list Click Properties Enable "Validate server certificate" In Trusted Root Certification Authorities list, enable the root.der certificate. In Select Authentication Method, select "Secured password (EAP-MSCHAPv2)" Click Configure If desired, enable "Automatically use my Windows logon name and password".
I did not enable "Automatically use my Windows ..." In my HP laptop, the software adds HP\\ before the user name; e.g., HP\\jbibe. If you don't enable this option, windows will ask for your user name and password the first time the laptop tries to connect to the network. The computer will then use the user name and password exactly as entered.
On the original Authentication screen, I disabled the "Authenticate as computer when computer information is available"
Windows XP is now ready for testing.
9. Test PEAP
The final step is to test the server. With Windows XP computer off, start the server in the debug mode by entering:
/usr/local/radius/sbin/run-radius -X -A
The server should start, displaying various debug information. If it displays "Ready to process requests", the server is running. This message is identical to the TLS start message. If you review the debug information, you will see additional messages as peap and mschapv2 start.
If you see the Ready message, start the Windows XP computer. As the client and server communicate, you will see various messages exchanged. If all is well, you should see the client authenticated and the user logged on. Again you will see the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key.
If you review the debug messages, you will see the TLS tunnel being built. Once it is built, you will see verification that messages are passing through the tunnel. Finally, you will see the user authenticated.
|
More details coming...
Last Revised: Monday, 20-Oct-2008 22:24:50 EDT
|