ASA3 Lab Guide v5.0.0

February, 2011

ASA 8.4 SSL VPN with Dynamic Access Policies (DAP)

Lab Guide

Version 5.0.0

Part of the Fuel Series brought to you by the ASTEC team

2

February, 2011 ASA 8.4 SSL VPN with DAP Lab Procedures

Table of Contents

Introduction......................................................................................................................... 3

Log into the lab portal ........................................................................................................ 9 Exercise 1: Prepare for Launch Meeting.......................................................................... 11 Exercise 2: Verify Initial Connectivity (Baseline) ............................................................ 12 Exercise 3: Install ASDM and review current ASA configurations .................................. 39 Exercise 4: Configure AnyConnect SSL VPN client ......................................................... 60

Exercise 5: Create new AD groups used for DAP AAA attributes and enable remote

desktop on DC ................................................................................................................. 140 Exercise 6: Configure DAP policies to control SSL VPN access ................................... 157

Exercise 7: Configure Advanced Endpoint Assessment remediation ............................. 288 Appendix A: Answers to Exercise Questions .................................................................. 305 Appendix B: Final ASA Configuration ........................................................................... 307

3


Introduction

Your company has successfully deployed an ASA 5510 firewall upgrade and an

active/standby high-availability solution for Inside.local, a mid-size organization that

employs 500 people and is growing. They are very happy with your work in deploying

the ASA and are calling upon you for your skills and knowledge of the ASA to help them

migrate from IPSec VPN to SSL VPN.

After reviewing Inside.local’s requirements, you determine that migrating to the

AnyConnect client is best suited for them with the opportunity to design and implement

Clientless SSL VPN in the future. You will discuss with Inside the benefit of SSL VPN

and show them how they can leverage Dynamic Access Policies (DAP) to provide

granular access to resources.

With the help of your advice, Inside has also purchased the Advanced Endpoint

Assessment license, which will enable them to implement remediation policies. They are

looking for guidance in designing and deploying this security strategy. There is a

scheduled outage to allow you to complete this deployment and for testing.

The customer is ready for you to do some more of your ASA magic!

What precipitated the engagement?

Inside is looking for a more flexible remote access solution that makes it easy for

remote workers to gain access to their resources.

Security is of great importance and they would like to provide granular level

access to the different departments within the organization.

They need to leverage their Active Directory accounts and groups for remote

access user authentication.

LAN Administrators connecting to the network via remote access must do so

from corporate assets only.

They need to be able to push down and deploy the VPN client as easily and

efficiently as possible.

Key requirements:

o You must provide the customer a logical topology diagram.

o You need to explain how group policies and DAP policies are applied and the

processing order.

o The Web Content department should only have access to the DMZ server web

site.

o The Quality Assurance department should only have access to the DMZ server

FTP and WWW sites.

o The LAN administrators should only have access to the DMZ server FTP and

WWW sites as well as remote desktop access to their domain controller.

o The ASA should retrieve the users’ group membership to determine their level

of access to the FTP and WWW resources .

4


o Enforce the policy that all remote access users have their MS personal firewall

enabled.

o Provide post-installation recommendations.

5


Logical Topology

The diagram below depicts the logical L3 and L2 topology of the network for this lab.

Please note that the UserPCs and Servers are VMware images and that if you shut down

any of these machines you will lose all changes. Please ensure that you use restart,

if/when needed. Unless otherwise specified, all logins are administrator and passwords

are cisco123, all in lower case, except for pc-inside.inside.local where the username is

johndoe and the password is cisco123.

L3

ASA

Exchange inside

DMZ inside

PC Inside

PC outside

DC inside

v20v10

v600

e0/0

e0/1

e0/2

Internet

Core-sw1

ISP Router

v500

lo0

10.0.2.0/2410.0.1.0/24

192.168.1.0/24

10.0.255.1/32

10.0.0.0/24

.1

.1.1

.254

.10

.10 .100DHCP

.1

192.0.2.50

.254

.254

192.0.0.0/24

ASA

e0/0

e0/1e0/2 .253

.253

.253

HA-State

HA-Failover.5

e0/3

.6

e0/3

.1

Mgt .2

MgtPrimary

Active

Secondary

Standby

192.168.60.0/30

192.168.60.4/30

6


L2

Core-sw1

ASA

Exchange inside

DMZ insidePC Inside

PC outside

DC inside

v20 v20

v10 v600

v600

g1/0/1 g1/0/2

g1/0/3 g1/0/4

g1/0/5 g1/0/6

e0/0

e0/1 e0/2

Virtual Internet

v500

ISP Router

ASA

v600

g1/0/8 g1/0/7

e0/0

e0/1 e0/2

v500

ISP Router

e0/3 e0/3HA-State

Mgt MgtHA-Failover

7


Disclaimer

This lab is intended to be a sample of one way to configure the ASA to provide the

customer the required connectivity. There are many ways the ASA can be configured,

which vary depending on the situation and the customer’s goals/requirements. Please

ensure that you consult all current official Cisco documentation before proceeding with a

design or installation. This lab is primarily intended to be a learning tool and may not

necessarily follow best practice recommendation at all times in order to convey specific

information.

Current documentation for ASA can be found on CCO:

Cisco ASA 5500 Series Configuration Guide using the CLI, v8.4 http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_config.html

Cisco ASA 5500 Series Configuration Guide using ASDM, v6.4 http://www.cisco.com/en/US/docs/security/asa/asa84/asdm64/configuration_guide/asdm_64_config.html

Cisco ASA 5500 Migration Guide for Version 8.3

http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html

Release Notes for the Cisco ASA 5500 Series, 8.4(x)

http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html

Memory Requirements for the Cisco ASA Software version 8.3 and later http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_bulletin_c25-586414.html

The labs were constructed using the following software versions:

ASA asa841-k8.bin

ASDM asdm-641.bin

AVC AnyConnect-win-3.0.0629-k9.pkg

VPN Client vpnclient-win-msi-5.0.07

Prerequisite knowledge

This lab is the third module in a series of ASA labs created by the ASTEC team. This lab

assumes that you have taken our first two labs, ASA 8.4 Basics and New Features, and

Licensing ASA 8.4 and Configuring High Availability or have viewed the recorded tech

sessions or have equivalent basic understanding of IP technologies and the Cisco ASA

5500. It is suggested that you take the modules in the recommended order unless you are

already familiar with the information in the previous modules.

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_config.html

http://www.cisco.com/en/US/docs/security/asa/asa84/asdm64/configuration_guide/asdm_64_config.html

http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html

http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_bulletin_c25-586414.html

8


*** Important ASA Lab Information***

The ASAs in the lab are configured with the configuration register set to boot from

ROMMON. This is part of Team ASTEC’s automation in preparing the ASA for your

lab. Once the ASA loads in your lab, it will have the factory-default configuration.

If you reload your ASA during the lab, it will initialize in ROMMON.

Should this happen, issue the following commands:

1- From ROMMON, type boot flash:asa841-k8.bin.

2- Once the ASA has reloaded, type copy startup-config running-config.

Some ASA firewalls have the AIP-SSM module therefore, you might see the IPS in

the ASDM. Please disregard the IPS module in this lab.

9


Log into the lab portal

These labs are browser agnostic and will work with most versions, however, they have

been tested using Firefox and Internet Explorer. The PC requirements are as follows: use

Java version 1.4.3 or better, disable pop-up blockers and personal firewalls, and

disconnect any current VPN connections you may have running.

Open a browser and type https://128.107.69.132

Your proctor will provide you with the login and pod number information. Type this into

the Username/Password box and click Login. Also write this information below.

Username __________________________

Password __________________________

Pod number __________________________

https://128.107.69.132/

10


Click Continue.

On the ASTEC Student Portal web page, when launching the web bookmarks to access

PC-Inside and PC-Outside, please click the Open in a new Browser icon.

11


Exercise 1: Prepare for Launch Meeting

Goal: Define the steps required to meet the customer’s requirements.

Inside has a large workforce and has many remote access users. They have identified

three users which we will be using to test our SSL VPN design and implementation:

Jane Doe – She and the others in the Web Content department should only have access

to the WWW site on the DMZ server.

John Doe – He and the others in the Quality Assurance department should only have

access to the FTP and WWW sites on the DMZ server.

Administrators – People in this group should only have access to the FTP and WWW

sites on the DMZ server and remote-desktop access to the domain controller. This access

should only be possible if the administrator is using a corporate computer or laptop.

Inside has placed a registry watermark into their computer and laptop builds which we

will use as an indicator to validate the remote access users’ endpoint.

12


Exercise 2: Verify Initial Connectivity (Baseline)

Goal: Execute some baseline tests to ensure the network is operational prior to beginning

the work.

From the ASTEC student portal, go to pc-inside.

13


Log in as johndoe with a password of cisco123.

Open a command prompt and issue the ipconfig command. There is a cmd prompt

shortcut on the desktop.

What is your IP address? _________________________

What is your subnet mask? ________________________

What is your default gateway? _____________________

From pc-inside.inside.local, ping the following destinations:

ping 10.0.1.1 pc-inside default gateway

ping 10.0.2.10 dc.inside.local

ping 10.0.2.100 exchange.inside.local

ping 10.0.0.254 ASA inside interface

ping 192.168.1.10 dmz.inside.local

14


15


From pc-inside, launch Internet Explorer and type ftp://192.168.1.10 to test access to the

DMZ FTP server.

Next, type http://192.168.1.10 in your browser to test access to the DMZ web server.

ftp://192.168.1.10/

http://192.168.1.10/

16


Let’s next test access to the webmail server. We don’t want to authenticate, just simply

validate that access is allowed and that this is operational. In the browser, type

http://10.0.2.100/exchange.

http://10.0.2.100/exchange

17


Click Cancel and close Internet Explorer.

From the ASTEC Student Portal, go to pc-outside.

Log in as administrator with a password of cisco123.

18


From the desktop, double click the VPN icon, highlight the Inside-ipsec profile and click

Connect.

19


20


Provide johndoe/cisco123 as the credentials when prompted.

Once you are connected, open a command prompt and type ipconfig.

21


What are your IP addresses? ______________________________________

Next, issue the following ping commands:

ping 10.0.2.10 DC

ping 192.168.1.10 DMZ server

22


From pc-outside, launch Internet Explorer and browse to the DMZ web server.

In the browser, type http://192.168.1.10.

http://192.168.1.10/

23


Next, type ftp://192.168.1.10 to access the FTP server in the DMZ.

ftp://192.168.1.10/

24


Lastly, type http://10.0.2.100/exchange to validate that access is allowed and that this is

operational. Click Cancel when prompted to login.


25


Right click the VPN icon the system ray and select Disconnect.

26


Now let’s re-launch the VPN and login as janedoe with cisco123 as the password.

27


Once logged in, issue the ping tests again.

ping 10.0.2.10 DC


28


Now let’s re-test access to the FTP and WWW sites on the DMZ server. Launch Internet

Explorer and type ftp://192.168.1.10.

ftp://192.168.1.10/

29


Now type http://192.168.1.10.

http://192.168.1.10/

30


And let’s test the webmail access again (http://10.0.2.100/exchange). Click Cancel when

prompted to provide credentials.

31


We have validated that John Doe and Jane Doe both can ping internal resources and can

access the FTP and WWW sites on the DMZ server and Webmail on the Email server.

Right click the VPN icon in the system tray and select Disconnect.

32


We will lastly validate that the administrator also has access to all the resources.

Open the VPN client and click Connect.

33


Type administrator and cisco123 in the username and password field.

Open the command prompt and re-issue the same ping test.

ping 10.0.2.10 DC


34


Launch Internet Explorer and type ftp://192.168.1.10 to test FTP access.

ftp://192.168.1.10/

35


Next, type http://192.168.1.10 to test WWW access to the DMZ server.

http://192.168.1.10/

36


Lastly, type http://10.0.2.100/exchange to test webmail. Click Cancel when you are

prompted to provide credentials.


37


Close Internet Explorer and right click and select Disconnect from the VPN icon in the

system tray.

38


We have confirmed that all three users, Jane Doe, John Doe and Administrator all have

the same level of access, which is to the FTP and Web server on the DMZ server and to

Webmail on the Email server.

As we deploy the SSL VPN solution, we need to remember that we need to limit access

based on Inside.local’s requirements.

Please notify your proctor if any ping tests or FTP and HTTP tests fail.

39


Exercise 3: Install ASDM and review current ASA

configurations

Goal: The goal is to install the ASDM and review the ASA configurations, specifically

the existing IPsec connection profile and group policy. Understanding how group policies

are applied will help us in our SSL VPN configuration.

Return to pc-inside and from the desktop, launch Internet Explorer.

Type https://10.0.0.254 in the address bar. This is the ASA’s inside IP address.

Click “Continue to this website (not recommended)”.

https://10.0.0.254/

40


Click the Install ASDM Launcher and Run ASDM button.

Type administrator and cisco123 in the username and password boxes.

41


Click Run.

42


Click Run again.

Click Next twice.

43


Click Install.

Then click Finish to complete the installation.

44


Let’s log onto the ASA’s inside IP address of 10.0.0.254 using the local administrator

account and cisco123 password.

Check Always trust content from this publisher and click Yes.

45


The ASDM will start loading the ASA’s configuration.

The ASDM should start parsing the configuration from the ASA. This may take about

one minute.

46


From the ASDM Tools drop-down menu, select ping.

Let’s test connectivity from the ASA. Ping the following addresses.

192.0.0.1 outside gateway

10.0.0.1 inside gateway

192.168.1.10 DMZ server

47


Click Close after completing the ping tests.

From the Device Dashboard tab in the ASDM Home page, we can see the ASA’s

hostname, uptime, code version, and other pertinent information.

Select the License tab.

48


Q3.1: How many SSL VPN peers are installed on this ASA? __________________

Click the More Licenses link.

From here, we can see that this ASA has both a permanent and time based license. Click

Show license details to see the permanent licenses on this ASA.

49


50


Q3.2: What is the purpose of the Advanced Endpoint Assessment license?

Click OK to close this box.

Let’s next review the IPsec connection profile and group policy settings. Navigate to

Configuration > Remote Access VPN > Network (Client) Access and select IPsec

(IKEv1) Connection Profiles.

Select the inside-ipsec-tunnelgroup connection profile and click Edit.

We can see some very pertinent information here: user authentication information, the

client IP address pool, which group policy is mapped to this connection profile, and other

information.

If no connection profiles are created, then the users will match the Default

connection profile depending on whether this is IPsec or SSL VPN.

Let’s verify the settings in this connection profile and understand the values. Click Select

in the Client Address Pools.

51


We can see the starting and ending IP address in this pool.

52


Q3.3: What is the starting and ending IP address in this pool? Do you recall what IP

address the pc-outside had when the IPsec VPN was established?

Click OK and select Manage in the User Authentication field.

From here we can see the AAA server groups that can be referenced for authentication.

The AD-server group was already created and is now being used for the IPsec VPN users.

This AAA server group uses LDAP as the protocol. We will also use this AAA server

group for our SSL VPN users but let’s better understand these settings first. Select the

AD-server server group object and click Edit.

53


We see that the Inside interface is used for the LDAP lookup and that the LDAP server’s

IP address is 10.0.2.10. If you recall, this is Inside.local’s domain controller. The ASA

will try to access this server for 10 seconds before it times out. The lookup uses port 389,

the standard LDAP port. We could use LDAP over SSL which will then use port 636 but

this requires additional configuration on the domain controller. Next we see that the

LDAP server is a Microsoft server. The Base DN (distinguished name) is the location of

where we want our LDAP lookup to start. Using an LDAP browser, you would be able to

see the LDAP hierarchy for Inside.local and that Inside.Local is the root of this hierarchy.

This is why we specified dc=inside,dc=local as the base DN. This tells the lookup to start

at the highest level in the LDAP hierarchy at the dc=domain_name component.

The Scope specifies the depth of the LDAP lookup. Here we are specifying All levels

beneath the Base DN. The Naming Attribute is the username of the remote access users.

This is represented by the sAMAccountName LDAP attribute.

The next two settings specify who is binding to the domain controller and performing this

LDAP lookup. We cannot simply type administrator. We need to provide the path in

LDAP form to specify where this user resides in the LDAP hierarchy and provide the

corresponding password.

54


Click Cancel to close this box. Also click OK to close the Configure AAA Server

Groups window.

Next let’s click Manage in the Group Policy settings.

55


This will open the Configure Group Policies dialog box. We see two group policies, the

inside-ipsec-tunnelgroup and DfltGrpPolicy. We can also see which tunneling protocols

are enabled for each group policy. Select inside-ipsec-tunnelgroup group policy and

select Edit.

56


Let’s explore the pertinent settings to this group policy.

Click on General and expand More Options. From here we can see the tunneling

protocols

57


Only IPsec IKEv1 is selected as the tunneling protocol.

Q3.4: Could we use this group policy for AnyConnect SSL VPN? If not, what would we

need to change?

Q3.5: Should we edit this group policy to allow AnyConnect SSL VPN or should we

create a new group policy and allow the SSL VPN tunneling protocol separately?

Q3.6: What would some of the benefits be for creating a separate group policy for SSL

VPN?

Click Servers.

58


We can see the DNS and WINS servers IP addresses. Expand More Options. We can see

the default domain is inside.local. Expand Advanced and select Split Tunneling.

59


Here we can see that split tunneling is disabled. Inside.local has determined that all

remote access traffic is to be sent to the ASA. This is defined in their security policy.

Our SSL VPN group policy will also not allow split tunneling.

Click Cancel three times.

60


Exercise 4: Configure AnyConnect SSL VPN client

Goal: The goal is to configure the AnyConnect SSL VPN and test access.

The first step in enabling AnyConnect SSL VPN is to download the AVC client from

CCO and to put this on the ASA flash. This step has already been completed. We have

also downloaded the Cisco Secure Desktop which we will be using to perform endpoint

host scanning.

In the ASDM, navigate to Configuration > Remote Access VPN > Network (Client)

Access and select AnyConnect Connection Profiles. Select Enable Cisco AnyConnect

VPN Client access on the interfaces selected in the table below box.

Click Yes in the Enable SSL VPN Client Access dialogue box.

61


Click Browse Flash.

Select the anyconnect-win-3.0.0629-k9.pkg file and click OK.

Expand Regular expression to match user-agent and select Windows NT from the

drop down menu.

62


This is an optional parameter that helps reduce time to select the correct client image for

the remote computer. If we had images for Linux and Mac computers, configuring

regular expressions would help reduce the time to select the correct image for the

platform.

Click OK.

Select Allow Access on the outside interface.

63


Notice that the Enable DTLS also becomes selected. Clear the Enable DTLS check box

and observe the warning message.

Notice the warming pop-up message? It is indicating that DTLS offers better

performance than TLS. Click No.

Click on Port Settings. Notice that AnyConnect uses port 443 for TLS and DTLS. The

difference being that TLS use TCP as the transport while DTLS uses UDP.

64


Click Cancel.

Click Apply.

Once we start testing our AVC SSL VPN, we will look at the real time log viewer and

see what is happening from a protocol basis when users are connecting and we will

observe the number of connections each AVC connection has.

Navigate to Configuration > Remote Access VPN > AAA/Local Users and select

Local Users.

65


We can see that there are two local users, the administrator which we are using to

configure the ASA, and janedoe, which was used to initially test our IPsec VPN from our

last engagement with Inside.local.

We also see that janedoe has the inside-ipsec-tunnelgroup group policy applied to her.

This means that if this local account was to VPN to the ASA, all settings in the group

policy would apply. Do you recall these group policy settings from before?

Let’s view the Real-Time Log viewer on the ASDM so that we can observe the log while

we perform our testing.

Keep the Real-Time Log Viewer open throughout the lab as we will be returning often

to review the log.

In the ASDM, navigate to Monitoring > Logging and select Real-Time Log Viewer.

Click View.

66


We can now see the logs from the ASA.

67


As we start performing our testing, we will be toggling back and forth between pc-

outside and pc-inside. We test our VPN from pc-outside and then return to pc-inside and

view the logs in the real-time log viewer. Always leave real time log viewer open.

From pc-outside, launch Internet Explorer and type, https://192.0.0.254 . Click Continue

to this website (not recommended).

Return to pc-inside and look at the Real-Time Log viewer.

https://192.0.0.254/

68


We see that the VPN traffic is reaching the firewall over port 443.

Return to pc-outside and we are prompted to provide credentials for the VPN. Which

accounts could we use? We know that there are two local accounts on the ASA,

administrator and janedoe. We also know from our earlier IPsec testing that there are also

Johndoe, Janedoe and Administrator accounts retrieved from the LDAP server.

Let’s start by trying the Johndoe account. Type johndoe and cisco123 in the username

and password fields and click Login.

69


We see that this has failed. Return to pc-inside and look at the log.

70


71


Looking at the log, we see that the authentication was rejected because it was invalid.

This attempt tried to use a local account and there is no local johndoe account. We also

see that the DfltGrpPolicy was matched. We will shortly review the settings in that group

policy.

Let’s next try providing janedoe and cisco123 as the credentials and click Login.

72


We are seeing a different message in our browser. Let’s return to pc-inside and look at

the log.

73


We can see that janedoe successfully authenticated using the local account but yet her

login was denied.

Q4.1: Why was janedoe’s login denied?

If you recall, the janedoe account had the inside-ipsec-tunnelgroup group policy assigned.

Q4.2: What tunneling protocols were enabled in that group policy?

We also see that janedoe also matched the DfltAccessPolicy DAP policy. DAP (dynamic

access policy) is a collection of AAA attributes and endpoint attributes that are defined,

and when matched, specific policies are applied. This provides granular level access to

resources. More on DAP later on.

74


Let’s edit janedoe’s local account and remove the assigned inside-ipsec-tunnelgroup

group policy.

In the ASDM, navigate to Configuration > Remote Access VPN > AAA/Local Users

and select Local Users. Select janedoe and Edit.

Select VPN Policy. Click Inherit in the Group Policy setting. Click Ok and Apply.

75


Q4.3: What does the Inherit check box do for the settings? Now by selecting Inherit,

what group policy setting will apply for janedoe?

Return to pc-outside and test the SSL VPN by providing janedoe credentials again. The

password is cisco123 and click Login.

76


We can see that Janedoe has logged in successfully to the Clientless SSL VPN. No

AnyConnect client was downloaded and installed.

77


Q4.4: Why didn’t the AVC client get installed?

Return to pc-inside and look at the ASA log.

78


There are a few log entries that we will examine; first is that janedoe was authenticated

locally and that the default group policy, DfltGrpPolicy, was applied. We also see that the

session type is WebVPN or Clientless.

This is not what we were expecting. We were expecting Janedoe to get the AVC client

installed.

Let’s look at the VPN log on the ASDM. Navigate to Monitoring > VPN > VPN

Statistics and click Sessions.

In the Filter By drop down menu, select Clientless SSL VPN and click Filter.

79


We can see which connection profile janedoe matched and which group policy got

applied.

80


We will review the DfltGrpPolicy group policy settings but before we do that, return to

pc-outside and log out as janedoe. Also close Internet Explorer.

From pc-inside, navigate to Configuration > Remote Access VPN > Network (Client)

Access and select Group Policies.

Select the DfltGrpPolicy and click Edit.

81


Click General and expand More Options. We can see that all the Tunneling Protocols

except the SSL VPN Client (AnyConnect) are selected. Also notice that there is no

Inherit settings on the DfltGrpPolicy group policy. This is because this is the catch all

group policy. Settings in this policy are applied if there is no value setting in another

matching group policy.

As we saw earlier when we looked at the inside-ipsec-tunnelgroup connection profile, we

can select a group policy which we want to apply. Those group policy settings will apply

and take precedence, however, any settings defined in the DfltGrpPolicy group policy not

defined elsewhere would also apply.

82


Click Servers.

83


Again, we do not see any Inherit check box. If all remote access users would have the

same DNS and WINS servers, we could define these values here and this would apply to

all users that would have Inherit in their matching group policies.

Click Cancel.

Let’s delete the janedoe local user and test again. In the ASDM, navigate to

Configuration > Remote Access VPN > AAA/Local Users and select Local Users.

Select janedoe and Delete.

Click Apply.

84


Return to pc-outside. Launch Internet Explorer and type https://192.0.0.254. Try to login

as janedoe with the password cisco123.

https://192.0.0.254/

85


We can see that this is now failing.

86


Let’s review the ASA log from pc-inside.

87


We can now confirm that there is no janedoe local user on the ASA and the ASA is not

retrieving LDAP information for authentication.

Q4.5: If we were to login as the administrator, would this be successful?

Q4.6: Would the administrator get the AVC downloaded and installed or would the SSL

VPN be Clientless?

Let’s test this by returning to pc-outside and typing https://192.0.0.254 into our browser

and providing administrator and cisco123 as the credentials. Click Login.

https://192.0.0.254/

88


Success, the administrator has logged in successfully but again, there is no AnyConnect.

The SSL VPN session is Clientless.

89


Let’s review the ASA log and see what policies are being applied.

90


We can determine that the local administrator user on the ASA is being authenticated and

that the DfltGrpPolicy is being applied. The DfltGrpPolicy does not have the SSL VPN

Client tunneling protocol enabled, thus we only are getting Clientless SSL VPN.

Ok, now we know that we will be creating a new Group Policy for AVC SSL VPN and

selecting SSL VPN Client (SVC) as a permitted tunneling protocol.

From the ASDM on pc-inside, navigate to Configuration > Remote Access VPN >

Network (Client) Access and select Group Policies. Click the Add pull-down menu and

select Internal Group Policy

91


Name this group policy inside-avc-gp. Expand More Options. Clear the Inherit

checkbox and select SSL VPN Client. Note that the client in our case will be

AnyConnect Client (AVC).

92


Click Servers and clear the Inherit check boxes for DNS and WINS servers. Type

10.0.2.10 as the IP address for both. Expand More Options in the Servers window and

clear the Inherit check box. Then type inside.local in the Default domain.

93


Click OK and Apply.

94


Let’s next create a connection profile that users will need to match so that we can apply

our new inside-avc-gp group policy.

From pc-inside, in the ASDM, navigate to Configuration > Remote Access VPN >

Network (Client) Access and select AnyConnect Connection Profiles.

Click Add.

For the new connection profile name, type inside-avc-cp. Select AD-server from the

AAA Server Group drop down menu and click Select for the Client Address Pools.

95


Select the inside-ipsec-vpn-pool and click Assign. Although this IP pool is used in the

inside-ipsec-tunnelgroup connection profile, it could also be used in this connection

profile.

Click OK.

96


From the Group Policy drop down menu, select inside-avc-gp.

97


The new connection profile should have the following settings as seen in this picture.

Click OK and Apply.

98


Click Save.

Now with the new connection profile (inside-avc-cp) and group policy (inside-avc-gp),

we are ready to test again using the LDAP user accounts johndoe, janedoe and

administrator.

From pc-outside, launch Internet Explorer if your browser was closed. Type

https://192.0.0.254 in the address bar. When prompted, provide johndoe and cisco123 as

the username and password and click Login.

https://192.0.0.254/

99


We see that the login is still failing.

100


Q4.7: Why do you suspect that the SSL VPN login is still failing?

Return to pc-inside and look at the ASA log. There might be an indication as to why the

login is failing.

101


From the above log, we see that the authentication is local database and we know there is

no johndoe user account and that the DfltGrpPolicy group policy is applied.

Q4.8: Why is the authentication going to the local database when we specified in our

inside-avc-cp connection profile to use the AD-server AAA server group?

Return to pc-outside and test again using janedoe as the user.

In the browser type janedoe and cisco123 as the username and password. Click Login.

102


This also fails.

103


Look at the ASA log on pc-inside to determine whether this is the same reason as for

johndoe.

104


As per the ASA log, it appears that the login for janedoe is also trying to use the local

database and the janedoe user was deleted earlier. This is not going to be successful.

So we know the problem now. The SSL VPN is not using our newly created connection

profile, inside-avc-cp. We will return to the ASDM and have a look at our AnyConnect

and connection profile settings and see if anything was missed.

From the ASDM on pc-inside, navigate to Configuration > Remote Access VPN >

Network (Client) Access and select AnyConnect Connection Profiles.

In reading the Login Page Setting, it starts making sense now. It indicates that unless an

alias is identified on the login page, the DefaultWEBVPNGroup connection profile will

be used. We need to select the check box to allow users to select an alias on their login

page!

Select the check box to Allow users to select the connection profiles in the Login Page

Setting.

105


We see that selecting the check box has generated an error message. We will need to

create an alias in our connection profile before we enable this check box. Click OK to

close the error message.

Select the inside-avc-cp connection profile and click Edit.

106


In the Basic settings, type inside-vpn in the Aliases box and click OK.

107


Returning to the AnyConnect Connection Profiles view, we can now see that there is a

defined alias for the inside-avc-cp connection profile.

We should now be able to select the Allow user to select connection profile check box.

Click Apply.

108


Return to pc-outside and type https://192.0.0.254 in your browser. We now see the

connection profile alias, inside-vpn, in the Group drop down menu. This is looking

better.

Type johndoe and cisco123 as the username and password and click Login.

https://192.0.0.254/

109


Success! We start seeing the installation of the AnyConnect Secure Mobility Client.

110


Click Install to the security warning pop-up message.

We see the installation progressing.

111


Click Yes to the security alert pop-up message.

While the AVC is being downloaded and installed, let’s return to pc-inside and look at

the ASA logs.

We can see some information about this SSL VPN connection. We can see that the IP

address 10.1.1.1 has been assigned. We can also see that the inside-avc-gp group policy

has been matched and applied, and that this is a SVC (SSL VPN Client) session.

112


Return to pc-outside and see if the AnyConnect has finished downloading and installing.

We can see that the connection is established and we now have the AVC icon in our

system tray, and we have a gold lock to indicate that the VPN is up.

At this point, you can close Internet Explorer.

113


Right click the AVC icon in the system tray and select Open AnyConnect.

114


Click Advanced. We can gather statistics from the Statistics tab on this VPN connection.

such as the connection status, IP address of the client and head end server (ASA), time

connected and number of sent and received bytes. The AnyConnect 3.0 client is more

than a client. It is more a platform today. Stay tuned for our next training release covering

Mobile User Security which will cover the AVC 3.0 in greater depth.

115


Of note, we can see that the transport protocol is DTLS and that there is no compression.

DTLS and compression are mutually exclusive. DTLS is used because it offers better

SSL VPN performance. DTLS uses UDP protocol as the transport which has less

overhead than the TCP protocol.

Let’s look at the ASDM monitoring on pc-inside and see if there is more information that

we could retrieve. In the ASDM from pc-inside, navigate to Monitoring > VPN > VPN

Statistics and select Sessions.

From the Filter By drop down menu, select AnyConnect Client and click Filter.

116


We see the username johndoe and IP address and 10.1.1.1. We can also confirm which

connection profile and group policy are matched and applied.

Click Details to retrieve more detailed information on this connection. Looking at the

details of johndoe’s connection, we see two tunnels, one SSL-Tunnel and one DTLS-

Tunnel. The SSL-Tunnel uses destination port TCP 443 and DTLS-Tunnel uses

destination port UDP 443. We can also see that each connection has its own tunnel ID.

When the AVC SSL VPN session is established, it will try to connect over TCP port 443

to establish the initial connection. Once this is established, it will try to connect over

UDP port 443. This second tunnel is what is used to send and receive data and because it

is using UDP as the protocol, it will be faster than TCP due to less overhead.

117


Click Close.

Return to pc-outside and let’s test access to resources. From pc-outside, ping the domain

controller and DMZ server.

Open the command prompt and type:

ping 10.0.2.10 domain controller


118


Next, open Internet Explorer and type ftp://192.168.1.10 to test FTP access.

ftp://192.168.1.10/

119


Now type http://192.168.1.10 to test access to the web site.

http://192.168.1.10/

120


Lastly, type http://10.0.2.100/exchange to test access to webmail on the email server.

Click Cancel when prompted for credentials.


121


We now have confirmed that, just like the IPsec VPN provided, we have access to the

resources through the AnyConnect SSL VPN.

Let’s test AnyConnect VPN using janedoe’s user account next. Disconnect the AVC

VPN by right clicking on the AVC icon in the system tray and select VPN Disconnect.

122


Now right click the AVC icon in the system tray and select Open AnyConnect and click

Connect.

123


Type janedoe and cisco123 in the username and password fields and click OK.

124


Minimize the AnyConnect client.

Now return to pc-inside and look at the ASA logs in the Real-Time Log viewer.

We can confirm that janedoe is authenticated from server 10.0.2.10, our domain

controller, and that the inside-avc-gp group policy is applied.

We also see a reference to a DAP policy being applied. More on DAP shortly.

Let’s look at additional information on this VPN connection. From the ASDM on pc-

inside, navigate to Monitoring > VPN > VPN Statistics and select Sessions.

In the Filter By drop down menu, select AnyConnect Client and click Filter.

125


We see information that is similar to what we saw for johndoe. Click Details to display

additional information.

126


In the details view, we now see the missing information; IP address and group policy.

Similar to johndoe’s session, we see two tunnels, one using TCP and the second using

UDP, and two different Tunnel IDs.

Note

The Tunnel IDs and Source Ports will vary with each connection.

127


Click Close.

With janedoe still connected, return to pc-outside and perform some tests. From the

command prompt, ping the DMZ server.

Ping 10.0.2.10 DC server


128


Let’s next test FTP access. Launch Internet Explorer and type ftp://192.168.1.10.

ftp://192.168.1.10/

129


Next, type http://192.168.1.10 in your browser.

http://192.168.1.10/

130


Lastly, type http://10.0.2.100/exchange to test webmail.

Click Cancel when prompted for credentials.


131


Close your browser and disconnect your VPN session. Right click the AVC icon in the

system tray and select VPN Disconnect.

132


We have one more user to test to confirm that all three user have worked successfully, the

administrator. Right click the AVC icon in the system tray and select Open

AnyConnect.

133


Click Connect.

Type administrator and cisco123 for the username and password fields and click OK

.

134


Let’s again return to pc-inside and look at the ASA Monitoring information on this VPN

connection. From the ASDM on pc-inside, navigate to Monitoring > VPN > VPN

Statistics and select Sessions.

In the Filter By drop down menu, select AnyConnect Client and click Filter.

We see information that is similar to what we saw for johndoe and janedoe.

Click Details.

135


Click Close.

Return to pc-outside and perform some tests. From the command prompt, ping the DMZ

server.


136


Let’s test FTP access. Launch Internet Explorer and type ftp://192.168.1.10.

Let’s next test access to the DMZ server web site. Type http://192.168.1.10 in the

browser.

ftp://192.168.1.10/

http://192.168.1.10/

137


Lastly, type http://10.0.2.100/exchange in the browser to test webmail. Click Cancel

when prompted for credentials.


138


Close Internet Explorer and right click the AVC icon in the system tray and VPN

Disconnect.

139


140


Exercise 5: Create new AD groups used for DAP AAA

attributes and enable remote desktop on DC

Goal: We will be logging onto the domain controller and creating new Windows groups.

These two new groups will be used in our DAP policies to determine the access level to

resources. We will also enable remote desktop on the domain controller.

From the ASTEC student portal web page, click on the DC-Inside web bookmark.

Type administrator and cisco123 as the username and password and click OK.

141


Launch Active Directory Users and Computers by clicking Start > Programs >

Administrative Tools > Active Directory Users and Computers.

142


Expand Inside.local and right-click the Users container and select New > Group from

the menu.

143


Type dmz-http-access-group as the group name and leave everything as default. Click

Next.

Click Next.

144


Click Finish.

Right click the Users container again and select New > Group from the menu.

145


Type dmz-http-ftp-access-group for the group name and click Next.

Click Next.

146


Click Finish.

We next want to add janedoe into the dmz-http-access group and johndoe into the dmz-

http-ftp-access-group. Right click the dmz-http-access-group and select Properties.

147


Click the Members tab and click Add.

148


Type janedoe and click Check Names. Click OK.

Click OK.

149


Right-click the dmz-http-ftp-access-group and select Properties.

150


Select the Members tab and click Add.

151


Type johndoe and click Check Names. Click OK.

Click OK.

152


We next need to enable remote desktop on the domain controller. Click Start > Settings

> Control Panel.

153


Double click System in the Control Panel.

154


Select the Remote tab and select the Enable Remote Desktop on this computer check

box.

155


Click OK to acknowledge the Remote Sessions pop-up warning.

Click OK.

156


Close the DC-Inside VNC window.

157


Exercise 6: Configure DAP policies to control SSL VPN access

Goal: The goal of this section is to configure DAP policies to provide granular access to

janedoe, johndoe and the administrator. We will accomplish this by retrieving AAA

attributes and applying Network ACLs. We will lastly enable Cisco Secure Desktop to

enable end point host scan to retrieve endpoint attributes to determine whether the

endpoint is a corporate asset or not.

From pc-inside, navigate the ASDM to Configuration > Remote Access VPN >

Network (Client) Access and select Dynamic Access Policies. Click Edit.

There are no AAA or endpoint attributes to retrieve in the DfltAccessPolicy DAP policy.

As we saw earlier while we were testing AVC SSL VPN access, a DAP policy was being

applied after each successful user VPN logon.

Think of this DfltAccessPolicy as a “permit any any” ACL. It is configured to allow all

VPN users to access all resources without any restrictions. This applies to IPsec, AVC

and Clientless VPN connections.

As we start to configure DAP policies which will have matching AAA attributes criteria

and access restrictions, it is best practice to change this DfltAccessPolicy to terminate.

158


Think of an ACL: you apply specific denies and permits and then have an explicit deny

all, so if a packet does not match any permit statement, it does not get forwarded. When

we configure DAP policies, this is what we will use the DfltAccessPolicy for.

Select Terminate and type the following message; “You are not authorized to have

remote access.” Click OK and Apply.

Let’s test the above statement and see whether the DfltAccessPolicy will terminate the

VPN connection attempts. From pc-outside, open the AnyConnect client and click

Connect. Type administrator and cisco123 in the username and password fields. We

know that this worked earlier.

Click OK.

159


We get the Login denied message with the banner we just typed in our DfltAccessPolicy.

160


Click OK.

Let’s review the ASA logs and confirm that the DAP policy is denying access. From pc-

inside, look at the Real-Time Log viewer.

We see that the administrator authentication was successful and that we used the domain

controller at 10.0.2.10 to validate the administrator’s credentials. We also see that the

inside-avc-gp group policy was matched. Lastly we see that the DfltAccessPolicy DAP

policy was matched and this takes precedence over any other policy. Since it was set to

terminate, the administrator was denied access!

161


Now that we know that the DfltAccessPolicy is denying everyone, we need to create

some DAP policies that will allow the remote users to connect.

In the ASDM, navigate to Configuration > Remote Access VPN > Network (Client)

Access and select Dynamic Access Policies. Click Add.

162


Type dmz-http-access for the Policy Name and Policy to permit http access to dmz

server in the Description. Type 50 for the ACL Priority. Select User has All of the

following AAA attributes values from the drop-down menu.

163


Click Add and select Cisco from the AAA Attribute type. Select the Connection Profile

check box and select inside-avc-cp and click OK.

164


Click Add again to add a second AAA attribute. This time select LDAP from the AAA

Attribute Type drop down menu. Leave the Attribute ID as memberOf and click Get

AD Groups.

165


Click Show All and select dmz-http-access-group. Click OK.

166


Click OK.

We just configured two AAA attributes in this DAP policy and selected a requirement to

match ALL. The first criterion is to match the inside-avc-cp connection profile and the

second criterion is to be a member of the dmz-http-access-group, which janedoe is .

167


As per Inside.local’s requirements, her division should only have access to the DMZ

server web site. We need to configure a policy to only grant access to this resource.

Select the Network ACL Filters (client) tab and click Manage.

In the ACL Manager, click Add ACL.

168


Type permit-http-2-dmz as the ACL Name and click OK.

169


Select the permit-http-2-dmz ACL and click Add ACE from the drop down menu.

Type the following information in the ACE.

Action: Permit

Source: Any

Destination: 192.168.1.10

Service: TCP/http

Description: permit http to dmz server

Click OK.

170


Click OK again.

171


Now select the permit-http-2-dmz ACL from the drop down selection and click Add.

172


Select the Access Method tab and select AnyConnect Client. This value is redundant

because the inside-avc-gp only has the SVC tunneling protocol enabled. Remote users

matching that group policy could not be using Clientless SSL VPN. However, if someone

was to check Clientless in that group policy, the DAP policy would take priority and

enforce only AnyConnect clients as the access method.

173


Click OK and Apply.

174


Return to pc-outside and let’s try to connect again using the AVC method. Type janedoe

and cisco123 in the username and password fields and click OK.

175


While the VPN session is processing, return to pc-inside and look at the ASA logs in the

Real-Time Log viewer.

We see that janedoe has been authenticated by the server 10.0.2.10 and that the inside-

avc-gp group policy has applied. We now see that the dmz-http-access DAP policy is also

applying. So janedoe should have access to the DMZ server web site.

Let’s return to pc-outside and test this.

176


Open a command prompt and try to ping the DMZ server at 192.168.1.10. We see that

this is now failing where this was successful earlier.

177


Launch Internet Explorer and type http://192.168.1.10.

http://192.168.1.10/

178


Great, this is working as expected. Now type ftp://192.168.1.10.

ftp://192.168.1.10/

179


The FTP failed to display.

Q6.1: Why is the FTP site now failing?

Let’s try accessing the webmail site. This also worked before. Type

http://10.0.2.100/exchange.


180


Same results as the FTP site. Both unsuccessful.

When we created our Net ACL and permitted TCP/http to our DMZ server, it applied an

implicit deny all ACL after our permit. This is why the ping test failed and both the FTP

and webmail failed.

We have accomplished our first task, which is to restrict janedoe’s access using AVC to

only the DMZ server web site.

Close the browser and right click the AVC icon in the system tray and select VPN

Disconnect.

181


Let’s try to login as johndoe. Open the AnyConnect client and click Connect. Type

johndoe and cisco123 in the username and password fields. Click OK.

182


We immediately get the login denied message. Click OK and return to pc-inside and look

at the ASA logs.

183


In the Real-Time log viewer, we confirm that johndoe matched the DfltAccessPolicy

DAP policy and was terminated. If you recall, he is member of the dmz-http-ftp-access-

group and we have no DAP policies that match this AAA attribute yet.

184


We will now create a DAP policy for the dmz-http-ftp-access-group. In the ASDM on pc-

inside, navigate to Configuration > Remote Access VPN > Network (Client) Access

and select Dynamic Access Policies. Click Add.

185


Type dmz-http-ftp-access and Policy to permit http and ftp access to dmz server in

the Policy Name and Description fields. Type 51 in the ACL Priority box and select

Users has ALL of the following AAA attributes values from the drop down menu.

186


Click Add and select Cisco from the AAA Attribute Type drop down list. Select the

Connection Profile box and select inside-avc-cp from the drop down list.

Click OK.

187


Click Add again to add the second AAA attribute. Select LDAP from the AAA Attribute

Type drop down list.

188


Select Get AD Groups. Click Show All. Then scroll down to find the dmz-http-ftp-

access-group and click OK.

189


Click OK.

190


Select the Network ACL Filters (client) tab and the permit-http-2-dmz Network ACL

from the drop down list. Click Add.

Now click Manage to create another ACL to permit traffic to the FTP site.

191


Click Add ACL in the ACL Manager.

192


Type permit-ftp-2-dmz for the ACL Name. Click OK.

193


Select the permit-ftp-2-dmz ACL and click Add ACE from the drop down menu.

194



Action: Permit

Source: Any


Service: TCP/ftp

Description: permit ftp to dmz server

Click OK.

195


Click OK.

196


Select the permit-ftp-2-dmz Network ACL from the drop down list and click Add.

197


Select the Access Method tab and select AnyConnect Client. Click OK.

198


We can see both DAP policies in the Dynamic Access Policies view. Notice that the

higher ACL Priority number is listed first in the list. The DAP policy with the ACL

Priority 51 is higher than the DAP policy with the ACL Priority 50. We will explain the

ACL Priority number shortly.

Click Apply.

199


We now return to pc-outside and test johndoe’s VPN. Open the AnyConnect client and

click Connect. Type johndoe and cisco123 in the username and password fields. Click

OK.

200


Let’s go to pc-inside and look at the ASA log again.

We confirm that johndoe is successfully authenticated by server 10.0.2.10, and that the

dmz-http-ftp-access DAP policy was matched and applied. This is what we expected.

201


Return to pc-outside to test access. Let’s start with a ping test. Try to ping the DMZ

server at 192.168.1.10.

202


Let’s next launch Internet Explorer and type ftp://192.168.1.10. This works as expected.

ftp://192.168.1.10/

203


Now type http://192.168.1.10 in the browser. This also works.

http://192.168.1.10/

204


Let’s test other resources that johndoe should not have access to. Type

http://10.0.2.100/exchange to test webmail access. This fails.


205


Lastly, let’s launch the remote desktop client and test access to the domain controller.

From pc-outside, click on Start > Programs > Accessories > Remote Desktop

Connection.

In the Remote Desktop Connection, type the domain controller’s IP address, 10.0.2.10

and click Connect.

206


Click Connect to confirm that you trust this connection.

We see that this connections fails, as expected. Johndoe only has access to the DMZ

server’s FTP and Web sites.

Click OK.

207


Close your browser and right click the AVC icon in the system tray and select VPN

Disconnect.

At this point we have created two DAP policies and both have tested as expected.

Janedoe has access to the DMZ server web site and johndoe has access to the DMZ

server web and FTP sites. We will create another DAP policy for the LAN administrators

and give them the same DMZ server access as johndoe and RDP access to the domain

controller. Lastly, this access is only permissible from a corporate asset computer.

From pc-inside, in the ASDM, navigate to Configuration > Remote Access VPN >

Network (Client) Access and select Dynamic Access Policies. Click Add.

208


Type dmz-http-ftp-and-dc-rdp-access and Policy to permit http and ftp access to

dmz server and rdp to the dc server in the Policy Name and Description. Type 52 in

the ACL Priority box.

209


Select Users has ALL of the following AAA attributes values and click Add. Select

Cisco from the AAA Attribute Type drop down list and inside-avc-cp in the Connection

Profile matching drop down list after you selected the check box.

Click OK.

210


Click Add again to add the second AAA attribute and select LDAP as the AAA Attribute

Type.

211


Click Get AD Groups the click Show All and select Administrators as the Group Name

and click OK twice.

212


Now that we have our AAA attributes, let’s add the Net ACLs. Select the Network ACL

Filters (client) tab and select permit-http-2-dmz and permit-ftp-2-dmz from the drop

down list and click Add.

Now click Manage to launch the ACL Manager.

213


Click Add ACL.

214


Type permit-rdp-2-dc for the ACL Name.

215


Select the permit-rdp-2-dc ACL and click Add ACE.

216



Action: Permit

Source: Any


Service: TCP/3389

Description: permit rdp to dc server

Click OK.

217


Click OK to close the ACL Manager.

218


Now select the newly created permit-rdp-2-dc ACL to our DAP policy. Select this ACL

from the drop down list and click Add.

Click OK.

219


Now we have all three DAP policies listed. Again, the DAP policy with the higher ACL

Priority value is listed higher on the DAP list and the DfltAccessPolicy does not have a

ACL Priority number. Let’s explain this value.

The ASA uses the ACL Priority value to logically sequence the ACL when aggregating

the network and web-type ACLs from multiple DAP records. These are sequenced from

higher to lower and are used to evaluate the processing order of ACLs.

There could be a likelihood that a remote access user matches more than one DAP policy;

therefore, the user may have different levels of access defined through the DAP policies.

Again, recall that to match a DAP policy, you will match any or all AAA and Endpoint

attributes. So when processing the Network and Web based ACLs, the DAP policy with

the highest ACL Priority is applied and takes precedence if the ACLs are conflicting,

otherwise, they are aggregated.

Click Apply.

When was the last time you saved your work? Click Save.

220


Let’s now return to pc-outside and test the administrator’s VPN. From pc-outside, type

administrator and cisco123 in the username and password fields and click OK.

221


Let’s look a the ASA log on pc-inside.

We are seeing that the administrator has successfully authenticated. We also see that the

administrator is matching the dmz-http-ftp-and-dc-rdp-access DAP policy. This is great!

222


Return to pc-outside and test access to resources. The administrator should be able to

access the web and FTP sites on the DMZ server and be able to remote to the domain

controller.

From pc-outside, launch Internet Explorer and type ftp://192.168.1.10. This works.

ftp://192.168.1.10/

223


Now type http://192.168.1.10. This also works.

http://192.168.1.10/

224


Let’s try to access the email server using webmail. Type http://10.0.2.100/exchange.

This does not work, as expected.


225


Try to connect to the domain controller through remote desktop. Click Start and Run.

Type mstsc (MS terminal services client) and click OK.

226


In the remote desktop connection, type 10.0.2.10 in the computer box and click Connect.

227


Click Connect to trust the remote computer.

Success! We get the Windows login page. Type administrator and cisco123 in the

username and password fields and click OK.

228


We can now see the domain controller’s desktop.

229


Let’s logoff the domain controller. Click Start and select Log Off Administrator.

***CAUTION***

Please do not shut down the server. It is a VM image with non-persistent hard drives.

There is no way for you to restart this image. We would have to manually restart this

image and you would lose all your settings on this server. Also, all LDAP authentication

using this server from the ASA would fail!!!!

230


Click Log Off to confirm.

231


Close your browser and right click the AVC icon in the system tray and select VPN

Disconnect.

232


If you recall, the requirement for the LAN administrators access should be only from

corporate assets. Inside.local has added a registry key into their laptop and computer

build to help them distinguish this asset.

We need to Edit the dmz-http-ftp-and-dc-rdp-access DAP policy to add this endpoint

attribute as part of the criteria.

In the ASDM from pc-inside, navigate to Configuration > Remote Access VPN >

Network (Client) Access and select Dynamic Access Policies. Select the dmz-http-ftp-

and-dc-rdp-access DAP policy and click Edit.

233


Click Add to add the endpoint attribute.

234


Select Registry from the drop down list.

235


We get a warning message that Cisco Secure Desktop is not enabled. This is required in

order to perform endpoint scans. Click OK.

236


Click Cancel to close the Edit Dynamic Access Policy window.

We can access Cisco Secure Desktop in a few ways.

237


In the Setup parameter, click Browse Flash to locate the CSD file.

238


Select the csd_3.5.2008-k9.pkg file and click OK.

Check the Enable Secure Desktop check box and click Apply.

239


Return to the Dynamic Access Policies and edit the dmz-http-ftp-and-dc-rdp-access

DAP policy. Navigate to Configuration > Remote Access VPN > Network (Client)

Access.

Click Edit.

240



241


Select Registry from the drop down list. This is looking different from the last time we

were trying to add the registry key.

242


We see no Endpoint ID to select. We need to create the Endpoint ID in the Host Scan

section on CSD and then reference that ID from the DAP policy afterward.

Click Cancel twice.

243


Navigate to Configuration > Remote Access VPN >Secure Desktop Manager and

select Host Scan. Notice the information posted on the Host Scan page?

We need to create the entries to be scanned here and then we reference these entries from

the DAP policies.

244


Enable the Endpoint Assessment ver 3.4.17.1 check box and click Add and select

Registry Scan from the drop down list.

245


Type corp-asset for the Endpoint ID. This is the value we will select in the DAP policy.

Select the HKEY_LOCAL_MACHINE\ value from the Entry Path drop down list.

Type SOFTWARE\CORPKEY\corpasset in the Entry Path. Click OK.

Click Apply All.

246


Return to the Dynamic Access Policies configuration and Edit the dmz-http-ftp-and-dc-

rdp-access DAP policy.


247


Select Registry from the Endpoint Attribute Type drop down list.

248


Select the newly created Endpoint ID corp-asset. Check the Value check box and select

string from the drop down list and type yes. Select the Caseless check box.

Click OK.

249


Click OK to close the DAP policy.

250


Click Apply.

You may have an Information pop-up message (if you have the enable preview

commands setting in the ASDM preferences) indicating that no CLI changes were made

but DAP Selection file needs to be updated. All the DAP information is stored in the

dap.xml file on flash. Good information to know because doing a copy startup-config

tftp will NOT back up your DAP policies. You would need to use the backup utility

from the ASDM. This is covered in our ASA 8.4 Basics and New Features and

Licensing ASA 8.4 and Configuring Failover tech session classes. For more

information, you can view these recordings here:

https://www.myciscocommunity.com/docs/DOC-6048

Click OK.

Return to pc-outside and edit the registry to emulate a corporate computer.

From pc-outside, click on Start > Run and type regedit. Click OK.

https://www.myciscocommunity.com/docs/DOC-6048

251


In the registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE. Right click on

the SOFTWARE key and select New > Key.

252


Type CORPKEY as the name for this new key. Right click CORPKEY and select New

> String Value. Type corpasset as the value.

253


Right click the corpasset string and select Modify.

254


Type yes as the value. Click OK.

Here is how the registry key should look like. Remember, any typing mistakes would

NOT allow the DAP policy to match and login would be denied.

255


Close the registry.

After changing the registry, you will need to close and re-launch the AnyConnect

Secure Mobility client.

Launch the AnyConnect client and type administrator and cisco123 in the username and

password fields. Click OK.

256


Looking good so far. We see that the VPN is being established.

257


Let’s test the access to the FTP and Web sites on the DMZ server.

258


259


Now let’s test remote access to the domain controller. Click Start > Run and type mstsc

and OK.

Type 10.0.2.10 in the Computer box and click Connect.

260


Click Connect in the trust this remote connection box.

Type administrator and cisco123 in the username and password fields and click OK.

261


We can see the domain controller’s desktop. Mission accomplished!

262


Close the Remote Desktop window and Disconnect the AVC VPN. Right click the AVC

icon in the system tray and click VPN Disconnect.

Time for a reality check. Where are we at with Inside.local’s requirements?

Let’s review these requirements and check off what has been completed.

Key requirements:

o You must provide the customer a logical topology diagram.

o You need to explain how group policies and DAP policies are applied and the

processing order.

o A department should only have access to the DMZ server FTP site.

o A second department should only have access to the DMZ server FTP and

WWW sites.

o The LAN Administrators should only have access to the DMZ server FTP and

WWW sites as well as remote desktop access to their domain controller.

263


o Retrieve the users’ group membership to determine their level of access to the

resources .

o Enforce the policy that all remote access users have their MS personal firewall

enabled.

o Provide post-installation recommendations.

We can check off the first six requirements. We are left with the last two. Before we

continue and complete the last two requirements, let’s test a few more things.

1- Let’s modify the registry on pc-outside to a non corporate build and test the

administrator’s VPN capability (this should fail)

2- Let’s test IPsec VPN. This was originally working and we want to be certain that

while Inside.local is migrating to SSL VPN, we did not break their current IPsec

VPN.

From pc-outside, let’s edit the registry and change the value from yes to no.

Click Start > Run and type regedit.

Navigate the registry to the following key,

HKEY_LOCAL_MACHINE\SOFTWARE\CORPKEY\corpasset. Right click

corpasset and select Modify.

264


Type no and click OK.

Close the registry and right click the AnyConnect client and select VPN Connect.

265


Type administrator and cisco123 for the username and password and click OK.

266


As expected, the login is denied. We know that the administrator is now matching the

DfltAccessPolicy which is set to Terminate.

267


Click OK. Let’s now return the registry string to indicate yes. Click Start > Run and

type regedit.

268


Navigate the registry to the following key,

HKEY_LOCAL_MACHINE\SOFTWARE\CORPKEY\corpasset. Right click

corpasset and select Modify.

269


Change the value to yes. Click OK.

270


Close the registry and test again.

271


Perfect, we have established the VPN connection.

272


Let’s review the ASA logs from pc-inside. We confirm that the administrator is now

matching the dmz-http-ftp-and-dc-rdp-access DAP policy, as expected.

273


Return to pc-outside and let’s disconnect the AVC client and test the IPsec client.

From pc-outside, right click the AVC icon in the system tray and select VPN Disconnect.

274


Launch the VPN Client shortcut on the desktop, select the inside-ipsec-profile and click

Connect.

275


Type johndoe and cisco123 for the username and password and click OK.

276


Not good! We receive a User authentication failed message.

277


Click OK.

Let’s return to pc-inside and review the ASA logs. We can see that johndoe

authentication is successful. We see that the inside-ipsec-tunnelgroup group policy is

matched and applied. However, if you recall, all the DAP policies are matching the

inside-avc-cp connection profile. The IPsec vpn is matching the inside-ipsec-tunnelgroup

connection profile; therefore, all IPsec connections will match the DfltAccessPolicy DAP

policy and fail.

278


We need to create one last DAP policy to permit IPsec remote access users to

successfully connect.


Network (Client)Access and select Dynamic Access Policies. Click Add.

279


Type permit-ipsec and Policy to permit ipsec vpn in the Policy Name and Description.

Type 53 in the ACL Priority box and select the Users has ALL of the following AAA

attributes values from the drop down list.

280


Click Add and select Cisco from the AAA Attribute Type drop down list. Check the

Connection Profile box and select inside-ipsec-tunnelgroup from the drop down list.

Click OK.

281


Review the DAP settings. Click OK.

282


Click Apply.

283


Return to pc-outside and test the IPsec VPN again.

Type johndoe and cisco123 in the username and password fields. Click OK.

284


Let’s look at the ASA logs on pc-inside. Success! We now see that the IPsec VPN is

matching the permit-ipsec DAP policy.

285


Return to pc-outside and test FTP access to the DMZ server. From pc-outside, launch

Internet Explorer and type ftp://192.168.1.10.

ftp://192.168.1.10/

286


Awesome! Close Internet Explorer and right click the IPsec icon in the system tray and

select Disconnect.

287


288


Exercise 7: Configure Advanced Endpoint Assessment

remediation

Goal: As part of Inside.local’s security policy, they would like to forcibly enable the

personal firewalls on all the remote access users. They are looking for a simple and

consistent method to deploy this solution. They would also like to have possible

remediation so that if any user disables the personal firewall, the policy would re-enable

this dynamically.

With your recommendation, Inside.local has purchased the Advanced Endpoint

Assessment license and planning to deploy policies to help enforce their security policy.

For now, we will test this and deploy a policy to forcibly enable the MS personal firewall

on all remote access users that have Windows XP with SP2 or higher.


Secure Desktop Manager and select Host Scan. Check the Advanced Endpoint

Assessment ver 3.4.17.1 box and click Configure.

Select the Windows tab and click Add for the Personal Firewall section.

289


Scroll down to Microsoft Corp. and select Microsoft Windows Firewall XP SP2+ and

click OK.

290


From the Firewall Action drop down list, select Force Enable. Please note the warning

message. This action will remain on the client after the VPN is terminated.

291


Scroll down and click OK

292


Click Apply All.

293


Let’s Save our work. Click Save.

294


Return to pc-outside and let’s test this new policy. Right click the LAN connection icon

in the system tray and select Change Windows Firewall settings.

We confirm that the personal firewall is Off. Click Cancel.

295


Open the AnyConnect client.

296


Click Connect. Type administrator and cisco123 in the username and password fields.

Click OK.

297


Review the ASA logs from pc-inside. We confirm that the administrator has been

authenticated and that the dmz-http-ftp-and-dc-rdp-access DAP policy was matched.

298


Let’s return to pc-outside and see if the personal firewall settings have changed from Off

to On.

Right click the LAN connection icon in the system tray and select Change Windows

Firewall settings.

299


We now see that the Firewall setting has indeed changed to On.

300


Select Off (not recommended) and click OK.

301


Launch Internet Explorer and type ftp://192.168.1.10. We do this to simply generate

traffic from the pc-outside.

ftp://192.168.1.10/

302


Right click the LAN connection icon in the system tray again and select Change

Windows Firewall settings.

303


Bingo! The firewall setting has changed again to On. Good job!

304


Congratulations. This completes the lab!

305


Appendix A: Answers to Exercise Questions

Q3.1: How many SSL VPN peers are installed on this ASA? 250 SSL VPN licenses

Q3.2: What is the purpose of the Advanced Endpoint Assessment license? With an

Advanced Endpoint Assessment License, you can enhance Host Scan by configuring an

attempt to update noncompliant computers to meet version and policy requirements.

Q3.3: What is the starting and ending IP address in this pools? Do you recall what

IP address the pc-outside had when the Ipsec VPN was established? The IP range

starts from 10.1.1.1 to 10.1.1.50. The pc-outside should have used the 1st available IP

address, 10.1.1.1.

Q3.4: Could we use this group policy for AnyConnect SSL VPN? If not, what

would we need to change? This group policy could not be used because only the IPsec

IKEv1 tunneling protocol is selected We would need to select the SSL VPN Client in the

tunneling protocols to be able to use this group policy.

Q3.5: Should we edit this group policy to allow AnyConnect SSL VPN or should we

create a new group policy and allow the SSL VPN tunneling protocol separately?

Although we could edit this group policy, you should create a different group policy for

the SSL VPN Client. This would provide you with better control over the 2 different

tunneling protocols.

Q3.6: What would some of the benefits be for creating a separate group policy for

SSL VPN? The first benefit is that each group policy could be mapped to different

connection profiles thus providing more granular control over how the group policies are

applied. Additional benefits are that we can have more specific settings for each protocol.

Q4.1: Why was janedoe’s login denied? Janedoe’s login was denied because she

matched the ipsec-inside-tunnelgroup group policy.

Q4.2: What tunneling protocols were enabled in that group policy? If you recall,

this group policy only had IPsec IKEv1 as the available tunneling protocol.

Q4.3: What does the Inherit check box do for the settings? Now by selecting

Inherit, what group policy setting will apply for janedoe? Understanding the hierarchy

of how policies are applied is critical to successfully deploying SSL VPN. The order of

which policies apply (processing order) is: DAP, user, Group policy, Group Policy

associated with a Connection Profile and the DfltGrpPolicy last. Any configured

parameter will apply. If no parameter is applied and Inherit is selected, the ASA will go

through the processing order until a value is retrieved and applied. By selecting Inherit

for Janedoe, the DfltGrpPolicy group policy settings will apply.

306


Q4.4: Why didn’t the AVC client get installed? Janedoe matched the DfltGrpPolicy

which has Clientless SSL VPN tunneling protocol enabled. Therefore she was able to

login with the Clientless VPN and no AVC software got installed.

Q4.5: If we were to login as the administrator, would this be successful? Yes, the

administrator’s login would be successful.

Q4.6: Would the administrator get the AVC downloaded and installed or would his

SSL VPN be Clientless? The administrator would login using Clientless SSL VPN.

Q4.7: Why do you suspect that the SSL VPN login is still failing? The login is failing

because the correct connection profile, inside-avc-cp, is not being matched.

Q4.8: Why is the authentication going to the local database when we specified in

our inside-avc-cp connection profile to use the AD-server AAA server group? The

inside-avc-cp is using the AD-server AAA server group however, the

DfltWEBVPNgroup connection profile is set to local and that connection profile is being

matched.

Q6.1: Why is the FTP site now failing? We only specified access to the DMZ server

using the HTTP service. The ASA applied an implicit deny all so all other attempts to

access resources will fail.

.

307


Appendix B: Final ASA Configuration ASA Version 8.4(1) ! hostname asa-lab domain-name inside.local enable password 9jNfZuG3TC5tCVH0 encrypted passwd 2KFQnbNIdI.2KYOU encrypted names ! interface Ethernet0/0 description Interface_2_Internet nameif outside security-level 0 ip address 192.0.0.254 255.255.255.0 standby 192.0.0.253 ! interface Ethernet0/1 description Interface_2_InsideLAN nameif inside security-level 100 ip address 10.0.0.254 255.255.255.0 standby 10.0.0.253 ! interface Ethernet0/2 description Interface_2_DMZ nameif dmz security-level 50 ip address 192.168.1.254 255.255.255.0 standby 192.168.1.253 ! interface Ethernet0/3 description STATE Failover Interface ! interface Management0/0 description LAN Failover Interface ! ftp mode passive clock timezone EST -5 clock summer-time EDT recurring dns server-group DefaultDNS domain-name inside.local object network InsideLAN subnet 10.0.0.0 255.0.0.0 description Inside-10-Network object network Outside_PAT_Address

308


host 192.0.0.252 description Address_2_PAT_InsideLAN object network Email_NAT_IP_Address host 192.0.0.250 description NAT-Address-4-EmailServer object network Email_server host 10.0.2.100 description Inside_email_server object network DMZ_server host 192.168.1.10 description DMZ_Web_Server object network Web_NAT_IP_Address host 192.0.0.251 description NAT-Address-4-WebServer object network VPN-IP-Pool subnet 10.1.1.0 255.255.255.192 object network DMZnetwork subnet 192.168.1.0 255.255.255.0 description DMZ network access-list outside_access_in remark ACE to allow SMTP traffic to the email server access-list outside_access_in extended permit tcp any object Email_server eq smtp access-list outside_access_in remark ACE to allow HTTP traffic to the web server access-list outside_access_in extended permit tcp any object DMZ_server eq www access-list outside_access_in extended permit tcp any object DMZ_server eq ftp access-list permit-http-2-dmz remark permit http tp dmz server access-list permit-http-2-dmz extended permit tcp any host 192.168.1.10 eq www access-list permit-ftp-2-dmz remark permit ftp tp dmz server access-list permit-ftp-2-dmz extended permit tcp any host 192.168.1.10 eq ftp access-list permit-rdp-2-dc remark permit rdp to dc server access-list permit-rdp-2-dc extended permit tcp any host 10.0.2.10 eq 3389 pager lines 24 logging enable logging asdm informational mtu outside 1500 mtu inside 1500 mtu dmz 1500 ip local pool inside-ipsec-vpn-pool 10.1.1.1-10.1.1.50 mask 255.255.255.0 failover failover lan unit primary failover lan interface failover Management0/0 failover replication http failover link state Ethernet0/3 failover interface ip failover 192.168.60.1 255.255.255.252 standby 192.168.60.2 failover interface ip state 192.168.60.5 255.255.255.252 standby 192.168.60.6

309


icmp unreachable rate-limit 1 burst-size 1 icmp permit any echo-reply outside icmp deny any outside asdm image disk0:/asdm-641.bin no asdm history enable arp timeout 14400 nat (inside,outside) source static InsideLAN InsideLAN destination static VPN-IP-Pool VPN-IP-Pool nat (dmz,outside) source static DMZnetwork DMZnetwork destination static VPN-IP-Pool VPN-IP-Pool ! object network Email_server nat (inside,outside) static Email_NAT_IP_Address object network DMZ_server nat (dmz,outside) static Web_NAT_IP_Address ! nat (inside,outside) after-auto source dynamic InsideLAN Outside_PAT_Address access-group outside_access_in in interface outside route outside 0.0.0.0 0.0.0.0 192.0.0.1 1 route inside 10.0.0.0 255.0.0.0 10.0.0.1 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00 timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute timeout tcp-proxy-reassembly 0:01:00 dynamic-access-policy-record DfltAccessPolicy user-message "You are not authorized to have remote access." action terminate dynamic-access-policy-record permit-ipsec description "Policy to permit ipsec vpn" priority 53 dynamic-access-policy-record dmz-http-access description "Policy to permit http access to dmz server" network-acl permit-http-2-dmz priority 50 webvpn svc ask none default svc dynamic-access-policy-record dmz-http-ftp-access description "Policy to permit http and ftp access to dmz server" network-acl permit-http-2-dmz network-acl permit-ftp-2-dmz priority 51 webvpn

310


svc ask none default svc dynamic-access-policy-record dmz-http-ftp-and-dc-rdp-access description "Policy to permit http and ftp access to dmz server and rdp to dc server" network-acl permit-http-2-dmz network-acl permit-ftp-2-dmz network-acl permit-rdp-2-dc priority 52 aaa-server AD-server protocol ldap aaa-server AD-server (inside) host 10.0.2.10 ldap-base-dn dc=inside,dc=local ldap-scope subtree ldap-naming-attribute sAMAccountName ldap-login-password ***** ldap-login-dn cn=administrator,cn=users,dc=inside,dc=local server-type microsoft aaa authentication ssh console LOCAL aaa authentication telnet console LOCAL http server enable http 10.0.0.0 255.0.0.0 inside no snmp-server location no snmp-server contact snmp-server enable traps snmp authentication linkup linkdown coldstart service resetoutside crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto ipsec ikev1 transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac crypto ipsec ikev1 transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto ipsec ikev1 transform-set ESP-DES-MD5 esp-des esp-md5-hmac crypto ipsec ikev1 transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac crypto ipsec ikev1 transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac crypto ipsec ikev1 transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1 crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5 crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP crypto map outside_map interface outside crypto ikev1 enable outside crypto ikev1 policy 10 authentication pre-share encryption 3des hash sha

311


group 2 lifetime 86400 crypto ikev1 policy 65535 authentication pre-share encryption 3des hash sha group 2 lifetime 86400 telnet 10.0.0.0 255.0.0.0 inside telnet timeout 5 ssh 10.0.0.0 255.0.0.0 inside ssh timeout 5 console timeout 0 ! tls-proxy maximum-session 125 ! threat-detection basic-threat threat-detection statistics host threat-detection statistics port threat-detection statistics protocol threat-detection statistics access-list no threat-detection statistics tcp-intercept webvpn enable outside csd image disk0:/csd_3.5.2008-k9.pkg csd enable anyconnect image disk0:/anyconnect-win-3.0.0629-k9.pkg 1 regex "Windows NT" anyconnect enable tunnel-group-list enable group-policy inside-ipsec-tunnelgroup internal group-policy inside-ipsec-tunnelgroup attributes wins-server value 10.0.2.10 dns-server value 10.0.2.10 vpn-tunnel-protocol ikev1 default-domain value inside.local group-policy inside-avc-gp internal group-policy inside-avc-gp attributes wins-server none dns-server value 10.0.2.10 vpn-tunnel-protocol ssl-client default-domain value inside.local username administrator password e1z89R3cZe9Kt6Ib encrypted privilege 15 tunnel-group inside-ipsec-tunnelgroup type remote-access tunnel-group inside-ipsec-tunnelgroup general-attributes

312


address-pool inside-ipsec-vpn-pool authentication-server-group AD-server default-group-policy inside-ipsec-tunnelgroup tunnel-group inside-ipsec-tunnelgroup ipsec-attributes ikev1 pre-shared-key ***** tunnel-group inside-avc-cp type remote-access tunnel-group inside-avc-cp general-attributes address-pool inside-ipsec-vpn-pool authentication-server-group AD-server default-group-policy inside-avc-gp tunnel-group inside-avc-cp webvpn-attributes group-alias inside-vpn enable ! class-map inspection_default match default-inspection-traffic ! ! policy-map type inspect dns migrated_dns_map_1 parameters message-length maximum client auto message-length maximum 512 policy-map global_policy class inspection_default inspect dns migrated_dns_map_1 inspect ftp inspect h323 h225 inspect h323 ras inspect ip-options inspect netbios inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp inspect icmp ! service-policy global_policy global prompt hostname context service call-home call-home

313


contact-email-addr [email protected] contact-name JohnDoe contract-id 123456789 customer-id 145689 phone-number 1-234-567-8901 sender from [email protected] sender reply-to [email protected] site-id 1 street-address 123 ABC street, Nowherville, ZX mail-server 10.0.2.100 priority 1 profile CiscoTAC-1 no active destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService destination address email [email protected] destination transport-method http subscribe-to-alert-group diagnostic subscribe-to-alert-group environment subscribe-to-alert-group inventory periodic monthly subscribe-to-alert-group configuration periodic monthly subscribe-to-alert-group telemetry periodic daily profile Inside destination address email [email protected] destination transport-method email subscribe-to-alert-group configuration export full Cryptochecksum:68d5be83450be2c7d6042c5b2f065a8d : end asdm image disk0:/asdm-641.bin no asdm history enable

ASA3 Lab Guide v5.0.0

Documents

Transcript of ASA3 Lab Guide v5.0.0