Tutorial: Cisco Routers Add Web Security with Cisco ScanSafe

Cisco launched this feature to the market last month at Interop. In a nutshell, it provides IOS routers with intelligent, identity aware, traffic redirection to the Cisco ScanSafe web security cloud offering. ScanSafe provides the following web security features as a cloud service:

• URL Filtering
• Scanlets analyze all elements of a web request including HTML, JavaScript, Flash and even obfuscated active scripts
• Zero-day malware prevention
• Protection against Phishing attacks
• Granular Reporting with a multi-tenant design
• 100% uptime over the last 8+ years
• Heuristic Malware identification

Here is a graphical look at how each web request is processed in the cloud:

This means that http and https traffic will be redirected from the router to the ScanSafe cloud where it will be filtered according to your policy settings. In addition to the redirection of traffic, the ISR G2 will also provide identity (group and user based) to ScanSafe for granular policy selection. Identity can be obtained using multiple methods (AD, web auth, etc) but Active Directory will probably be the most popular. The router encrypts all identity info before it is sent to the cloud.

This type of feature will allow companies to securely stop back-hauling web traffic from remote site VPNs to the central site and back out again. It also allows for a common web security policy across remote sites, central sites, and even remote hosts with the AnyConnect ScanSafe integration. Sending web traffic directly to the Internet results in performance and user satisfaction improvements and decreased bandwidth requirements for HQ. Here is a simple graphic to illustrate this intelligent redirection of web traffic.

Now on to how you configure this on the router.
First configure Identity on the router. This example will focus on active directory

LDAP integration.
Ldap server ad-server
ipv4 10.0.1.250
transport port 3268
bind authenticate root-dn cn=scansafe,cn=users,dc=test,dc=localdomain password 7 4424A34232
base‐dn dc=test,dc=localdomain

search‐filter user‐object‐type top
authentication bind‐first

Next, create an ldap group

Aaa group server ldap ad-servers
Server ad-server

Now Define ip admission control:

Aaa authentication login cs-aaa group ad-servers
Aaa authorization network cs-aaa group ad-servers
Aaa accounting network cs-aaa none

Ip admission virtual-ip 1.1.1.1
Ip admission name csauth ntlm
Ip admission name csauth order ntlm
Ip admission name csauth method-list authentication cs-aaa authorization cs-aaa accounting cs-aaa
Ip http server

Interface Gig0/1
!Internal interface
Ip admission csauth

Now that we have identity configured we move on to configuring the scansafe redirection commands:

parameter-map type content-scan global
server scansafe primary ipv4 72.37.244.147 port http 8080 https 8080
server scansafe secondary ipv4 80.254.145.147 port http 8080 https 8080
license 0 source interface GigabitEthernet0/0
timeout server 30 user-group ciscogroup username ciscouser
logging server scansafe on-failure block-all

Turn on content scanning on the external interface:

interface GigabitEthernet0/0
!external interface
ip address 128.107.150.75 255.255.255.0
ip nat outside
ip virtual-reassembly in
ip virtual-reassembly out
content-scan out

To whitelist sites you create a parameter map like the following example:

parameter-map type regex site_param
pattern google
pattern cisco
parameter-map type regex browser_param
pattern Chrome
content-scan whitelisting
whitelist header user-agent regex browser_param
whitelist header host regex site_param

Supported Cisco ISR G2 Platforms and requirements include
-881,891
-19xx, 29xx, 39xx
-Security feature license or higher is required
-Valid Cisco ScanSafe license

Cisco will release the IOS code end of this month. It will be 15.2(1)T. You can find more information at these links.

www.cisco.com/go/scansafe
www.cisco.com/go/isrg2

Cisco ASA Upgrade Adds Identity Firewalling

Identity aware firewalling seems to be all the rage right now. Having the ability to make firewall policy decisions based on user and group information from Active Directory can have enormous benefits if used properly. The Cisco ASA recently acquired the identity aware firewalling ability with the release of 8.4.2 code. It works with Microsoft Active Directory, cut-through proxy and VPN authentications today for user/group to flow matching. This new feature allows you to write access control policies that take a source username or group membership as match criteria. The ASA applies the security policies based on an association of IP addresses to Windows Active Directory, VPN or cut-through proxy login information and reports events based on the mapped user names instead of network IP addresses. This feature also allows you to use identity policies in service polices for things like IPS inspection, deep packet inspection, inspection engines, etc.

Here is an example of a user based access control rule:

The Cisco AD agent communicates with your ASA's to make this happen. You can have multiple ASA's talk to a single agent or vice-versa. This allows you to scale identity across domains, forests, and firewalls.

The other nice feature that released in 8.4.2 is the ability to use domain names instead of IP addresses. This means you can write a ACE that says source: http://www.cisco.com/ destination:http://www.amazon.com/ .
This feature helps simplify the readability of your ACL's and works great for domains that have multiple IP addresses associated with them. You cannot however enter a full URI like www.cisco.com/go/asa,so this feature will not take the place of a web filter.

You can upgrade to the latest code here www.cisco.com/go/asa
You'll also find the latest release notes herehttp://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html

If you have any questions on these features just post them.

ASAs, Multiple ISPs, and VPNs

Sometimes a customer situation finds aligns with perfect symmetry with my studies.

A customer of mine is using one ISP, which happens to be a T1 connection.  Really cool if you live in Lickbucket, AK or insist that 1998 was the coolest year ever.  Fortunately for me and my sanity, my customer does not fit into either category.  The T1 connection is used for both Internet access and site-to-site VPN connections to a number of satellite offices.  The VPNs are utilized for direct dialing between IP phones.  Not only is this solution undersized for their needs, but recently the T1 connection failed, causing the whole main office to go down.

Right now, the  customer is using a pair of ASAs at the main site.  While the ASA doesn’t offer a BGP solution like Juniper (grrr…), the ASA does offer redundant links out to the Internet.  However, unlike BGP, the IP address schemes for each ISP will be disparate.  This is no big deal if you have only outbound connections, but what about VPNs?  If we go with an additional ISP, we then need to split the traffic so we can utilize both links, but we still need a failover solution in case either link dies.

One feature of the ASA is the ability to put multiple peers on the firewall.  With this option, the VPN connections at each of the satellite offices can point to both external IP addresses for the redundant ISP links, providing for failover for the VPN as well.

In order to test out the theories, I setup the following lab:

With this lab, a local ASA simulates two ISP connections to R2 and R3.  R4 is the ISP connection to the remote location, and the remote ASA connects to R4.  R1 and R5 loopbacks are going to simulate end hosts.  R4 has three loopbacks that is going to simulate Internet connections.  R2, R3, and R4 are running EIGRP, and R3 is using an offset list to prevent asymmetric routing.  BGP could have been used to create a more “realistic” Internet connection, but…well, screw that.  EIGRP is easy, and the routing protocol isn’t the point of the lab.

After setting up EIGRP, getting the routes setup correctly, and opening up the firewalls to allow ICMP through, the meat of the lab is now at hand.  The failover between ISPs is done by SLA monitoring.  The SLA monitor sends a ping to a downstream router of choice, and if the router is responding, then the routes associated with the SLA monitor stay in place.  However, if the downstream router does not ping, then a second static route that is given a high metric (in this example, 250), takes over in the routing table.  Here is what the configuration in the lab would look like for the default static routes:

route outside 0.0.0.0 0.0.0.0 192.168.1.2 1 track 1
route backup 0.0.0.0 0.0.0.0 192.168.2.2 254
!
sla monitor 123
 type echo protocol ipIcmpEcho 192.168.1.2 interface outside
 num-packets 3
 frequency 10
sla monitor schedule 123 life forever start-time now
!
track 1 rtr 123 reachability

Two default routes exist.  The first default route points to the first “ISP” and has a metric of 1, and there is a track of 1 placed after it.  The track 1 matches the Response Time Reporter (rtr) that is the last statement of the SLA monitoring configuration.  The second default route points to the second “ISP” and has a metric of 254.

SLA monitor is configured with the interface and the downstream router (or host) that will receive the ping.  In this example, we are pinging R2 from the outside interface on the ASA to verify connectivity.  In the real world, this is going to be one of the better options, as many ISPs don’t really like having intermediate routers or hosts pinged through their systems.  The SLA monitor schedule line starts the monitoring process.  The final line is the Response Time Reporter associated with tracking the ping and linking the ping to the primary route using the track command.

After configuration, the routing table looks like the following:

ASA# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

S    1.1.1.1 255.255.255.255 [1/0] via 10.10.10.2, inside
C    10.10.10.0 255.255.255.0 is directly connected, inside
C    192.168.1.0 255.255.255.0 is directly connected, outside
C    192.168.2.0 255.255.255.0 is directly connected, backup
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.1.2, outside

The default route is currently going through the outside interface.  However, if the link to 192.168.1.2 is severed by doing a no shut on the fa0/0 interface on R2, the following result is:

ASA# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route

Gateway of last resort is 192.168.2.2 to network 0.0.0.0

S    1.1.1.1 255.255.255.255 [1/0] via 10.10.10.2, inside
C    10.10.10.0 255.255.255.0 is directly connected, inside
C    192.168.1.0 255.255.255.0 is directly connected, outside
C    192.168.2.0 255.255.255.0 is directly connected, backup
S*   0.0.0.0 0.0.0.0 [254/0] via 192.168.2.2, backup

The default route has now changed to the backup interface, and the next hop is going to ISP2.  Notice the metric: it is now at 254 rather than 1, as it is using the floating static route that was created.  After doing a no shut on fa0/0 on R2, the routes go back to normal.

One down, one to go…

The failover on the ASA is working, but what about the VPNs? There are now two different ISPs providing two different IP addresses on the outside. So the ASA at the remote site needs to connect to the backup interface on the local ASA for the primary VPN, but when the primary connection fails, it will need to connect to the outside interface of the local ASA. One way to accomplish this is to create two peers on the ASA on a single crypto map. However, not only do two peers need to be added, but two different tunnel groups (tunnel groups require the IP address of the endpoint for the name on S2S VPN connections).

The local ASA looks like the following:

access-list VPN extended permit ip host 1.1.1.1 host 6.6.6.6
!
crypto ipsec transform-set STRONG esp-3des esp-sha-hmac
crypto map VPN 10 match address VPN
crypto map VPN 10 set peer 10.10.40.2
crypto map VPN 10 set transform-set STRONG
crypto map VPN interface outside
crypto map VPN interface backup
crypto isakmp enable outside
crypto isakmp enable backup
crypto isakmp policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
tunnel-group 10.10.40.2 type ipsec-l2l
tunnel-group 10.10.40.2 ipsec-attributes
 pre-shared-key cisco

This is a pretty standard crypto map solution.  The access list at the top is creating a tunnel from l0 on R1 to l0 on R6.  Everything else will go out the “Internet”.  The next hurdle is the routing.  Redundancy would require that if ISP2 went down, then the VPN would go through ISP1. We can accomplish that by doing the same thing that we did for the outside link, only we create another SLA monitor for the backup link and track that connection:

route backup 1.1.1.1 255.255.255.255 192.168.2.2 1 track 2
route backup 10.10.40.2 255.255.255.255 192.168.2.2 1 track 2
route outside 1.1.1.1 255.255.255.255 192.168.1.2 254
route outside 10.10.40.2 255.255.255.255 192.168.1.2 254
!
sla monitor 456
 type echo protocol ipIcmpEcho 192.168.2.2 interface backup
 num-packets 3
 frequency 10
sla monitor schedule 456 life forever start-time now
!
track 2 rtr 456 reachability

Two routes have been added that will go to the backup interface for the VPN.  The first route is the endpoint that will go through the VPN tunnel.  The second IP is the actual VPN termination point on the firewall.  By creating the routes in this manner, the VPN will be forced through the backup ISP unless it goes down.  If the backup ISP goes down, the VPN will go through the outside ISP until it comes back up.  This allows both connections to still be used rather than having one connection sitting idle yet costing the company money.

Routing is complete, so now the remote ASA needs to be configured to use the backup ISP as the primary and the outside ISP as the secondary for the VPN.

access-list VPN extended permit ip host 6.6.6.6 host 1.1.1.1
!
crypto ipsec transform-set STRONG esp-3des esp-sha-hmac
crypto map VPN 10 match address VPN
crypto map VPN 10 set peer 192.168.2.1 192.168.1.1
crypto map VPN 10 set transform-set STRONG
crypto map VPN interface outside
crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
tunnel-group 192.168.2.1 type ipsec-l2l
tunnel-group 192.168.2.1 ipsec-attributes
 pre-shared-key cisco
tunnel-group 192.168.1.1 type ipsec=l2l
tunnel-group 192.168.1.1 ipsec-attributes
 pre-shared-key cisco

The configuration is pretty much the same, but there are some distinct differences.  First, the access-list for the VPN is reversed to match the outgoing traffic as with any VPN connection between two IPSec devices.  Second, the set peer statement has two IP addresses: The primary address followed by the backup address is the primary is unreachable.  Finally, there are two tunnel groups created.  This needs to be done because the tunnel group must match the IP address.  Because we have two potential tunnels, we need two tunnel groups.

So with everything in place, testing can now begin.  The following scenarios should be tested:

1. Current state: When we ping 6.6.6.6 from 1.1.1.1 on R1, the ping should be successful, and phase one should complete between 192.168.2.1 and 10.10.40.2.  This can be confirmed with a sh crypto isakmp on both ASAs.  A ping to 2.2.2.2, 3.3.3.3, or 4.4.4.4 on R4 from R1 (either 1.1.1.1 or 10.10.10.2) should also complete.  A traceroute to those IP address should show the route going through R2.
2. R2 goes down: Ping from 1.1.1.1 to 6.6.6.6 is successful.  Ping to R4 on any interface is successful, but the traceroute should show that the path now goes through R3. The crypto maps on both ASAs remain the same as in scenario 1.
3. R3 goes down: Ping from 1.1.1.1 to 6.6.6.6 is successful. P Ping to R4 on ay interface is successful, and the traceroute should go through R2 as in scenario 1.  However, the crypto maps on the ASAs should now show a connection between 10.10.40.2 and 192.168.1.1.  This can be confirmed with a sh crypto isakmp on both ASAs.

If these scenarios are successful, then the lab setup is confirmed.  First, scenario 1.  The routing table on the ASA:

ASA# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

S    1.1.1.1 255.255.255.255 [1/0] via 10.10.10.2, inside
S    6.6.6.6 255.255.255.255 [1/0] via 192.168.2.2, backup
C    10.10.10.0 255.255.255.0 is directly connected, inside
S    10.10.40.2 255.255.255.255 [1/0] via 192.168.2.2, backup
C    192.168.1.0 255.255.255.0 is directly connected, outside
C    192.168.2.0 255.255.255.0 is directly connected, backup
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.1.2, outside

So far, so good.  A traceroute to an “Internet” address (one of the loopbacks):

R1#traceroute 5.5.5.5

Type escape sequence to abort.
Tracing the route to 5.5.5.5

 1 192.168.1.2 28 msec 44 msec 16 msec
 2 10.10.20.1 8 msec *  28 msec

Good!  The traceroute is going through R2.  Is the VPN going through R3?  It should be terminating on the 192.168.2.1 address:

ASA2# sh crypto isakmp sa

 Active SA: 1
 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 192.168.2.1
 Type    : L2L             Role    : responder
 Rekey   : no              State   : MM_ACTIVE

After pinging 6.6.6.6 from R1 with a 1.1.1.1 source, we see on ASA2 that the active peer is 192.168.2.1, so we are going through R3 and terminating on the backup interface of ASA1.  So for scenario 2, we shut the fa0/0 interface on R2 to verify that all traffic will go through R3.  After shutting the interface down, we look at the routing table on ASA1:

ASA# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route

Gateway of last resort is 192.168.2.2 to network 0.0.0.0

S    1.1.1.1 255.255.255.255 [1/0] via 10.10.10.2, inside
S    6.6.6.6 255.255.255.255 [1/0] via 192.168.2.2, backup
C    10.10.10.0 255.255.255.0 is directly connected, inside
S    10.10.40.2 255.255.255.255 [1/0] via 192.168.2.2, backup
C    192.168.1.0 255.255.255.0 is directly connected, outside
C    192.168.2.0 255.255.255.0 is directly connected, backup
S*   0.0.0.0 0.0.0.0 [254/0] via 192.168.2.2, backup

The default gateway has now changed to the backup interface, and the backup interface is being used for the VPN.  A traceroute to the “Internet”:

R1#traceroute 5.5.5.5

Type escape sequence to abort.
Tracing the route to 5.5.5.5

 1 192.168.2.2 20 msec 44 msec 8 msec
 2 10.10.30.1 8 msec *  28 msec

The traceroute is now going through R3 instead of R2.  The VPN:

ASA2# sh crypto isakmp sa

 Active SA: 1
 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 192.168.2.1
 Type    : L2L             Role    : responder
 Rekey   : no              State   : MM_ACTIVE

The backup interface on the ASA is still terminating the VPN.  Scenario 3 is up next:

ASA# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

S    1.1.1.1 255.255.255.255 [1/0] via 10.10.10.2, inside
S    6.6.6.6 255.255.255.255 [250/0] via 192.168.1.2, outside
C    10.10.10.0 255.255.255.0 is directly connected, inside
S    10.10.40.2 255.255.255.255 [250/0] via 192.168.1.2, outside
C    192.168.1.0 255.255.255.0 is directly connected, outside
C    192.168.2.0 255.255.255.0 is directly connected, backup
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.1.2, outside

All of the routes are now going through the outside interface.  Traceroutes should now go through R2:

R1#traceroute 5.5.5.5

Type escape sequence to abort.
Tracing the route to 5.5.5.5

 1 192.168.1.2 24 msec 16 msec 12 msec
 2 10.10.20.1 40 msec *  28 msec

All traffic is going through R2 for the Internet.  The VPN:

ASA2# sh crypto isakmp sa

 Active SA: 1
 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 192.168.1.1
 Type    : L2L             Role    : responder
 Rekey   : no              State   : MM_ACTIVE

Yep, the ASA is terminating on the outside interface rather than the backup.  All of our testing is complete.

PEAP Authentication - Configuration example for Windows 7

Introduction:-



PEAP - Protected Extensible Authentication Protocol is one flavor of EAP It is a authentication protocol used in wireless and used for Point <to> Point connections. PEAP provides more security in authentication for 802.11 wireless local area networks that support 802.1X port access control.

PEAP authentication is managed between the PEAP supplicant and the authentication server (Radius). In first phase the client authenticates the server using a TLS -Transport Layer Security, certificate-based mechanism. This establishes an encrypted tunnel through which the second-phase PEAP credentials may be securely exchanged. The parameters used by the client in negotiating PEAP authentication are configured through the Windows Device Manager properties.

PEAP is based on server side EAP-TLS authentication. With PEAP many organizations can avoid the issues associated with installing digital certificates on every client device as required by EAP-TLS; instead, they can select the methods of client authentication, such as logon passwords or OTPs that best suit their corporate needs. Also PEAP is an enhancement of EAP-TLS authentication, PEAP encapsulates a second-phase authentication transaction within the TLS framework.

Prerequisites:-

Client running Windows 7 operating system with 802.1X support

Cisco Access Point

Cisco Access control Radius Server (ACS)

Network Diagram:-

• Click on the START menu and open the Control Panel.







• Click the link under Network and Internet called View network status and tasks. (Note: If the screen looks different, select Control Panel Home on the left.



• Click on the Mange Network Connections located on the left side of the window.





• Right click the Wireless Network Connection and select Connect/Disconnect.



• Click on Setup a connection or network located at the bottom of the window.





• Manually connect to a wireless network. Select Next.



• Choose the desired SSID of the network to be used for PEAP authentication from the Available networks list, and click Configure. Click Add in the Preferred networks section to configure a new network SSID.

• Choose the appropriate Network Authentication and Data Encryption parameters using the drop-down arrows.

• In this configuration example we used the Network Name is Private, Security Type is 802.1X, and Encryption type is WEP.Uncheck “Start this connection automatically”. Select Next.



• Click on the Settings button next to PEAP



• Check “Connect to these servers:” box . Add “IAS00 (dummy name)” to the box. Check any VeriSign Certificate Authorities. If you do not see any VeriSign Trust Network Options, continue on with the instructions.

• Check Validate server certificate.

Note:- If you do not check Validate server certificate, user credentials are not protected by the EAP server certificate. The configuration of the Microsoft PEAP (EAP-MSCHAP v2) supplicant (available in Windows XP SP1 and later and in Windows 2000 SP4)

Note:- For a computer to be successfully authenticated to a domain, the computer must be registered to the domain using a non-802.1X secured network (a wired connection) prior to attempting machine authentication with PEAP.

• In this example (above snapshot) we assumed that the server name is IAS00, certificate authority is VeriSign. It may be different depend upon network.

• Check the correct CA in the Trusted Root Certification Authorities list.

• Choose Secured password (EAP-MSCHAP v2) using the drop-down arrow in the Select Authentication Method field.

• Check Enable Fast Reconnect to enable client devices to perform a PEAP session resume with properly equipped and configured EAP servers. PEAP session resume enables client devices to re-authenticate with an EAP server after roaming to a new access point without submitting the second-phase PEAP credentials. The session is resumed using the cached TLS credentials.

• Click Configure, and the EAP MSCHAP V2 Properties screen appears



• Uncheck the box (Automatically use my Windows logon name and password).

If desired, check Automatically use my Windows logon name and password (and domain if any) to enable the Microsoft PEAP supplicant to use the Windows logon name for PEAP authentication. This enables the user to log in to the wireless network using their Windows credentials.

When this options is checked, the user credentials cannot be changed because they are stored in the user's profile, whether using manually entered credentials or using Windows credentials.

• Choose Private and click the Connect button

• Click Enter/select additional log on information.



• A box will appear in the bottom right of the screen as indicated below. Once you select it, a Server certificate box will appear. Select OK.

• Click on the box that appears in the bottom right of the screen.

• Return to the Protected EAP Properties box and check the boxes in front of VeriSign Trust Network.



• Another box will show up asking for a User name, password, and Domain. Type in your Username, your password, and Logon Domain. Click OK

• It will connect you to the wireless Network using PEAP. If this doesn't happen then a box will pop up at the bottom right hand corner (See below)

• Click on the box and another box will show up asking for a User name, password, and Domain. Type in your Username, your password, and Logon Domain. Click OK. It will connect you to the wireless Network using PEAP.

     

PEAP Authentication process:-

1. The client sends an EAP Start message to the access point

2. The access point replies with an EAP Request Identity message

3. The client sends its network access identifier (NAI), which is its username, to the access point in an EAP Response message

4. The access point forwards the NAI to the RADIUS server encapsulated in a RADIUS Access Request message

5. The RADIUS server will respond to the client with its digital certificate

6. The client will validate the RADIUS server's digital certificate

7. The client and server negotiate and create an encrypted tunnel

8. This tunnel provides a secure data path for client authentication

9. Using the TLS Record protocol, a new EAP authentication is initiated by the RADIUS server

10. The exchange will include the transactions specific to the EAP type used for client authentication

11. The RADIUS server sends the access point a RADIUS ACCEPT message, including the client's WEP key, indicating successful authentication