sa - shov

same-security-traffic

To permit communication between interfaces with equal security levels, or to allow traffic to enter and exit the same interface, use the same-security-traffic command in global configuration mode. To disable the same-security traffic, use the no form of this command.

same-security-traffic permit { inter-interface | intra-interface }

no same-security-traffic permit { inter-interface | intra-interface }

Syntax Description

inter-interface

Permits communication between different interfaces that have the same security level.

intra-interface

Permits communication in and out of the same interface.

Command Default

This command is disabled by default.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

7.2(1)

The intra-interface keyword now allows all traffic to enter and exit the same interface, and not just IPsec traffic.

Usage Guidelines

Allowing communication between same security interfaces (enabled by the same-security-traffic inter-interface command) provides the following benefits:

  • You can configure more than 101 communicating interfaces. If you use different levels for each interface, you can configure only one interface per level (0 to 100).

  • You can allow traffic to flow freely between all same security interfaces without access lists.

The same-security-traffic intra-interface command lets traffic enter and exit the same interface, which is normally not allowed. This feature might be useful for VPN traffic that enters an interface, but is then routed out the same interface. The VPN traffic might be unencrypted in this case, or it might be re-encrypted for another VPN connection. For example, if you have a hub and spoke VPN network, where the Secure Firewall ASA is the hub, and remote VPN networks are spokes, for one spoke to communicate with another spoke, traffic must go into the ASA and then out again to the other spoke.


Note


All traffic allowed by the same-security-traffic intra-interface command is still subject to firewall rules. Be careful not to create an asymmetric routing situation that can cause return traffic not to traverse the ASA.

Examples

The following example shows how to enable the same-security interface communication:


ciscoasa(config)# same-security-traffic permit inter-interface
         

The following example shows how to enable traffic to enter and exit the same interface:


ciscoasa(config)# same-security-traffic permit intra-interface
         

sasl-mechanism

To specify a SASL (Simple Authentication and Security Layer) mechanism for authenticating an LDAP client to an LDAP server, use the sasl-mechanism command in aaa-server host configuration mode. The SASL authentication mechanism options are digest-md5 and kerberos .

To disable an authentication mechanism, use the no form of this command.

sasl-mechanism { digest-md5 | kerberos server-group-name }

no sasl-mechanism { digest-md5 | kerberos server-group-name }


Note


Because the ASA serves as a client proxy to the LDAP server for VPN users, the LDAP client referred to here is the ASA.

Syntax Description

digest-md5

The ASA responds with an MD5 value computed from the username and password.

kerberos

The ASA responds by sending the username and realm using the GSSAPI (Generic Security Services Application Programming Interface) Kerberos mechanism.

server-group-name

Specifies the Kerberos aaa-server group, up to 64 characters.

Command Default

No default behavior or values. The ASA passes the authentication parameters to the LDAP server in plain text.


Note


We recommend that you secure LDAP communications with SSL using the ldap-over-ssl command if you have not configured SASL.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

aaa-server host configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.1(1)

This command was added.

Usage Guidelines

Use this command to specify ASA authentication to an LDAP server using SASL mechanisms.

Both the ASA and the LDAP server can support multiple SASL authentication mechanisms. When negotiating SASL authentication, the ASA retrieves the list of SASL mechanisms configured on the server and sets the authentication mechanism to the strongest mechanism configured on both the ASA and the server. The Kerberos mechanism is stronger than the Digest-MD5 mechanism. To illustrate, if both the LDAP server and the ASA support both mechanisms, the ASA selects Kerberos, the stronger of the mechanisms.

When disabling the SASL mechanisms, you must enter a separate no command for each mechanism you want to disable because they are configured independently. Mechanisms that you do not specifically disable remain in effect. For example, you must enter both of the following commands to disable both SASL mechanisms:

no sasl-mechanism digest-md5

no sasl-mechanism kerberos server-group-name

Examples

The following examples, entered in aaa-server host configuration mode, enable the SASL mechanisms for authentication to an LDAP server named ldapsvr1 with an IP address of 10.10.0.1. This example enables the SASL digest-md5 authentication mechanism:


ciscoasa(config)# aaa-server ldapsvr1 protocol ldap
ciscoasa(config-aaa-server-group)# aaa-server ldapsvr1 host 10.10.0.1
ciscoasa(config-aaa-server-host)# sasl-mechanism digest-md5
         

The following example enables the SASL Kerberos authentication mechanism and specifies kerb-servr1 as the Kerberos AAA server:


ciscoasa(config)# aaa-server ldapsvr1 protocol ldap
ciscoasa(config-aaa-server-group)# aaa-server ldapsvr1 host 10.10.0.1
ciscoasa(config-aaa-server-host)# sasl-mechanism kerberos kerbsvr1
         

saml idp

To add a new SAML IdP, use the saml idp command in webvpn configuration mode. To remove a SAML IdP, use the no form of this command.

saml idp idp-entityID

no saml idp idp-entityID

Syntax Description

base-URL

The Clientless VPN’s base URL. It is used in SAML metadata that is provided to third-party IdPs, so that IdPs can redirect end users back to the ASA.

clock-skew <value>

Clock skew which will tolerate the NotBefore and NotOnOrAfter SAML assertions. By default the clock-skew should be disabled. The default value for the clock-skew is 1 second. The allowed range is 1 - 180 seconds.

idp-entityID

The entity ID of the SAML Idp you are configuring the ASA to use.

internal

Set this flag if the IdP is in the internal network.

signature

signature <value>

Enable or disable signature in a SAML request.

(Optional) Enable signature and use a specific method in a SAML request.

timeout assertion

Overrides NoOnOrAfter if the sum of NotBefore and timeout is earlier than NoOnOrAfter.

timeout-in-seconds

The SAML timeout value in seconds. By default, there is no SAML timeout. NotBefore and NotOnOrAfter in the assertion is used to determine the validity.

trustpoint [idp | sp] <trustpoint-name>

The trustpoint idp contains the IdP certificate for ASA to verify SAML assertions.

The trustpoint-name is one of the existing trustpoint names.

The trustpoint sp contains the ASA (SP’s) certificate for IdP to verify the ASA’s signature or encrypt SAML assertion.

url [sign-in | sign-out] <value>

The URL is the IdP’s sign-in and sign-out URL.

The value of the URL for signing into the IdP. The url value must contain 4 to 2000 characters.

Command Default

None.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

webvpn

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.5(2)

This command was added.

9.7(1)

The internal attribute was added.

9.8(1)

Added SHA2 support and the ability to specify a signature method in a SAML request.

Usage Guidelines

This command configures one or more third party SAML identity provider's settings. The IdP settings are not used until they are applied in a tunnel group.

The SAML IdP's sign-in url, sign-out url, signing certificate can be found on the vendor's website. You must create a trustpoint to hold the IdP's signing certificate. The trustpoint name will be used by trustpoint idp.

Creating an Idp in webvpn mode puts you into saml-idp sub-mode, where you configure the following settings for this Idp:

  • url sign-in—URL to sign in to the Idp.

  • url sign-out—URL for redirecting to when signing out of the IdP.

  • signature—Enable or disable signature in SAML request. By default, the signature is disabled.

  • signature <value>—Enable signature and specify the method as rsa-sha1, rsa-sha256, rsa-sha384, or rsa-sha512. By default the signature is disabled.

  • time-out—SAML timeout value in seconds.

  • base-url—URL is provided to third-party IdPs to redirect end-users back to the ASA. When base-url is not configured, the URL comes from the ASA’s hostname and domain-name. For example, https://ssl-vpn.cisco.com as the base URL in show saml metadata when hostname is “ssl-vpn” and domain name is “cisco.com.” If neither base-url or hostname/domain-name are configured, show saml metadata returns an error.

  • trustpoint—Assigns an existing trustpoint based on the ASA (SP)'s or IDP certificate that the IdP can use to verify ASA's signature or encrypt SAML assertion.

Examples

The following example shows how to define an Idp, and configure the Idp settings:


ciscoasa(config)# same-security-traffic permit inter-interface
ciscoasa(config-webvpn)# saml idp salesforce_idp
 
ciscoasa(config-webvpn-saml-idp)# url sign-in
 https://asa-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect
 
ciscoasa(config-webvpn-saml-idp)# url sign-out
 https://asa-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect
ciscoasa(config-webvpn-saml-idp)# trustpoint idp salesforce_trustpoint
ciscoasa(config-webvpn-saml-idp)# trustpoint sp asa_trustpoint
ciscoasa(config-webvpn)# saml idp feide_idp
 
ciscoasa(config-webvpn-saml-idp)# url sign-in http://cisco.feide.no/simplesaml/saml2/idp/SSOService.php
 
ciscoasa(config-webvpn-saml-idp)# trustpoint idp feide_trustpoint
ciscoasa(config-webvpn-saml-idp)# trustpoint sp asa_trustpoint
ciscoasa(config-webvpn-saml-idp)# signature
ciscoasa(config-webvpn-saml-idp)# timeout assertion 120
ciscoasa(config-webvpn-saml-idp)# base-url https://ssl-vpn.cisco.com

saml idp-trustpoint

To override the trustpoint IdP setting in the SAML IdP configuration, use the saml idp-trustpoint command in the webvpn tunnel group configuration mode. To remove the IdP trustpoint settings, use the no form of the command

saml idp-trustpoint trustpoint_name [ trustpoint_name2 ]

no saml idp-trustpoint name

Syntax Description

trustpoint_name

Name of the IdP trustpoint.

trustpoint_name2

Name of the second IdP trustpoint.

Command Default

Not enabled.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

config-tunnel-webvpn

  • Yes

  • Yes

  • Yes

  • No

Command History

Release

Modification

9.17(1)

This command was added.

9.20(3)

trustpoint_name2 variable was added.

Usage Guidelines

Existing ASA SAML configurations support only one IDP trustpoint for each configured SAML IDP. The saml idp-trustpoint command overrides the IdP settings to support the Microsoft Azure multiple application deployment scenario.

If the IdP trustpoint setting is present in the tunnel-group, the command overrides the trustpoint IdP setting in the IdP configuration, which is referenced by the saml identity-provider command in the tunnel group.

You can now configure two tunnel-group-specific IdP certificates. This feature lets you trust an old certificate as well as a new certificate, making migration to the new certificate easier. If your IdP, for example Azure IdP, has multiple applications but share the same SAML entity ID, and each application has its own certificate. You can use this command to override the main webvpn saml truspoint configuration.

Examples

The following example shows how to override the IdP settings in trustpoint IdP configuration:


ciscoasa(config)# same-security-traffic permit inter-interface
ciscoasa(config-webvpn)# tunnel-group Sales webvpn-attributes
ciscoasa(config-tunnel-webvpn)# saml idp-trustpoint _SmartCallHome_ServerCA _SmartCallHome_ServerCA2
 

saml identity-provider

Use this CLI in config-tunnel-webvpn mode to assign a SAML IdP to a tunnel group (connection profile)

saml identity-provider name

no saml identity-provider name

Syntax Description

name

The name of the SAML Idp you are configuring the ASA to use.

Command Default

None.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

webvpn

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.5(2)

This command was added.

Usage Guidelines

This names this configuration of a third-party SAML identity provider in the ASA.


Note


While adding the SAML identity provider name, if you get the error "ERROR: SAML configuration could not be built", check your tunnel group name to ensure that the tunnel-group name does not contain the following special characters: &, ", or <. The tunnel group name is added using the tunnel-group webvpn-attributes command.

sast

To specify the number of SAST certificates to create in the CTL record, use the sast command in ctl-file configuration mode. To set the number of SAST certificates in the CTL file back to the default value of 2, use the no form of this command.

sast number_sasts

no sast number_sasts

Syntax Description

number_sasts

Specifies the number of SAST keys to create. The default is 2. The maximum allowed is 5.

Command Default

No default behavior or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl-file configuration

  • Yes

  • Yes

Command History

Release

Modification

8.0(4)

The command was added.

Usage Guidelines

CTL files are signed by a System Administrator Security Token (SAST).

Because the Phone Proxy generates the CTL file, it needs to create the SAST key to sign the CTL file itself. This key can be generated on the ASA. A SAST is created as a self-signed certificate.

Typically, a CTL file contains more than one SAST. In case a SAST is not recoverable, the other one can be used to sign the file later.

Examples

The following example shows the use of the sast command to create 5 SAST certificates in the CTL file:


ciscoasa
(
config-ctl-file
)# sast 5

scansafe

To enable Cloud Web Security inspection for a context, use the scansafe command in context configuration mode. To disable Cloud Web Security, use the no form of this command.

scansafe [ license key ]

no scansafe [ license key ]

Syntax Description

license key

Enters an authentication key for this context. If you do not specify a key, the context uses the license configured in the system configuration. The ASA sends the authentication key to the Cloud Web Security proxy servers to indicate from which organization the request comes. The authentication key is a 16-byte hexadecimal number.

Command Default

By default, the context uses the license entered in the system configuration.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

In multiple context mode, you must allow Cloud Web Security per context.

Examples

The following sample configuration enables Cloud Web Security in context one with the default license and in context two with the license key override:


! System Context
!
scansafe general-options
server primary ip 180.24.0.62 port 8080
retry-count 5
license 366C1D3F5CE67D33D3E9ACEC265261E5 
!
context one
 allocate-interface GigabitEthernet0/0.1
 allocate-interface GigabitEthernet0/1.1
 allocate-interface GigabitEthernet0/3.1
 scansafe
 config-url disk0:/one_ctx.cfg
!
context two
 allocate-interface GigabitEthernet0/0.2
 allocate-interface GigabitEthernet0/1.2
 allocate-interface GigabitEthernet0/3.2
 scansafe license 366C1D3F5CE67D33D3E9ACEC26789534
 config-url disk0:/two_ctx.cfg
!

scansafe general-options

To configure communication with the Cloud Web Security proxy server, use the scansafe general-options command in global configuration mode. To remove the server configuration, use the no form of this command.

scansafe general-options

no scansafe general-options

Syntax Description

This command has no arguments or keywords.

Command Default

No default behavior or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

You can configure a primary and backup proxy server for Cloud Web Security.

Examples

The following example configures a primary server:


scansafe general-options
 server primary ip 180.24.0.62 port 8080
 retry-count 5
 license 366C1D3F5CE67D33D3E9ACEC265261E5

scep-enrollment enable

To enable or disable the Simple Certificate Enrollment Protocol for a tunnel group, use the scep-enrollment enable command in tunnel-group general-attributes mode.

To remove the command from the configuration, use the no form of this command.

scep-enrollment enable

no scep-enrollment enable

Syntax Description

This command has no arguments or keywords.

Command Default

By default, this command is not present in the tunnel group configuration.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tunnel-group general-attributes configuration

  • Yes

  • Yes

Command History

Release

Modification

8.4(1)

This command was added.

Usage Guidelines

Only the Cisco Secure Client, Release 3.0 and later, supports this feature.

The ASA can proxy SCEP requests between Secure Client and a third-party certificate authority. The certificate authority only needs to be accessible to the ASA if it is acting as the proxy. For the ASA to provide this service, the user must authenticate using any of the methods supported by AAA before the ASA sends an enrollment request. You can also use Host Scan and dynamic access policies to enforce rules of eligibility to enroll.

The ASA supports this feature only with an AnyConnect SSL or IKEv2 VPN session. It supports all SCEP-compliant certificate authorities, including IOS CS, Windows Server 2003 CA, and Windows Server 2008 CA.

Clientless (browser-based) access does not support SCEP Proxy, although WebLaunch—clientless-initiated Secure Client—does support it.

The ASA does not support polling for certificates.

The ASA supports load balancing for this feature.

Examples

The following example, entered in global configuration mode, creates a remote access tunnel group named remotegrp and enables SCEP for the group policy:


ciscoasa(config)# tunnel-group remotegrp type remote-access
ciscoasa(config)# tunnel-group remotegrp general-attributes
ciscoasa(config-tunnel-general)# scep-enrollment enable
INFO: 'authentication aaa certificate' must be configured to complete setup of this option.

scep-forwarding-url

To enroll an SCEP certificate authority for a group policy, use the scep-forwarding-url command in group-policy configuration mode.

To remove the command from the configuration, use the no form of this command.

scep-forwarding-url { none | value [ URL ] }

no scep-forwarding-url

Syntax Description

none

Specifies no certificate authority for the group policy.

URL

Specifies the SCEP URL of the certificate authority.

value

Enables this feature for clientless connections.

Command Default

By default, this command is not present.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Group-policy configuration

  • Yes

  • Yes

Command History

Release

Modification

8.4(1)

This command was added.

Usage Guidelines

Enter this command once per group policy to support a third-party digital certificate.

Examples

The following example, entered in global configuration mode, creates a group policy named FirstGroup and enrolls a certificate authority for the group policy:


ciscoasa(config)# group-policy FirstGroup internal
ciscoasa(config)# group-policy FirstGroup attributes
ciscoasa(config-group-policy)# scep-forwarding-url value http://ca.example.com:80/
Attempting to retrieve the CA/RA certificate(s) using the URL. Please wait ...

secondary

To set the preferred unit for a failover group when using the preempt command, use the secondary command in failover group configuration mode. To restore the default value, use the no form of this command.

secondary

no secondary

Syntax Description

This command has no arguments or keywords.

Command Default

If primary or secondary is not specified for a failover group, the failover group defaults to primary .

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Failover group configuration

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

9.0(1)

Earlier software versions allowed “simultaneous” boot up so that the failover groups did not require the preempt command to become active on the preferred unit. However, this functionality has now changed so that both failover groups become active on the first unit to boot up.

Usage Guidelines

Assigning a primary or secondary preference to a failover group specifies which unit the failover group becomes active on when you set the preempt command. Both failover groups become active on the first unit that boots up (even if it seems like they boot simultaneously, one unit becomes active first), despite the primary or secondary setting for the group. When the other unit comes online, any failover groups that have the second unit as a priority do not become active on the second unit unless the failover group is configured with the preempt command or is manually forced to the other unit with the no failover active command. If the failover group is configured with the preempt command, the failover group automatically becomes active on the designated unit.

Examples

The following example configures failover group 1 with the primary unit as the higher priority and failover group 2 with the secondary unit as the higher priority. Both failover groups are configured with the preempt command, so the groups will automatically become active on their preferred unit as the units become available.


ciscoasa(config)# failover group 1
 
ciscoasa(config-fover-group)# primary
ciscoasa(config-fover-group)# preempt 100
ciscoasa(config-fover-group)# exit
ciscoasa(config)# failover group 2
ciscoasa(config-fover-group)# secondary
ciscoasa(config-fover-group)# preempt 100
ciscoasa(config-fover-group)# mac-address e1 0000.a000.a011 0000.a000.a012
 
ciscoasa(config-fover-group)# exit
ciscoasa(config)#

secondary-authentication-server-group

To specify a secondary authentication server group to associate with the session when double authentication is enabled, use the secondary-authentication-server-group command in tunnel-group general-attributes mode. To remove the attribute from the configuration, use the no form of this command.

secondary-authentication-server-group [ interface_name] { none | LOCAL |groupname [ LOCAL ]} [ use-primary-username ]

no secondary-authentication-server-group

Syntax Description

interface_name

(Optional) Specifies the interface where the IPsec tunnel terminates.

LOCAL

(Optional) Requires authentication against the local user database if all of the servers in the server group have been deactivated due to communication failures. If the server group name is either LOCAL or NONE, do not use the LOCAL keyword here.

none

(Optional) Specifies the server group name as NONE , indicating that authentication is not required.

groupname [ LOCAL ]

Identifies the previously configured authentication server or group of servers. Optionally, this can be the LOCAL group.

use-primary-username

Use the primary username as the username for the secondary authentication.

Command Default

The default value is none .

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tunnel-group general-attributes configuration

  • Yes

  • Yes

Command History

Release

Modification

8.2(1)

This command was added.

Usage Guidelines

This command is meaningful only when double authentication is enabled. The secondary-authentication-server-group command specifies the secondary AAA server group. The secondary server group cannot be an SDI server group.

If the use-primary-username keyword is configured, then only one username is requested in the login dialog.

If the usernames are extracted from a digital certificate, only the primary username is used for authentication.

Examples

The following example, entered in global configuration mode, creates a remote access tunnel group named remotegrp and specifies the use of the group sdi_server as the primary server group and the group ldap_ server as the secondary authentication server group for the connection:


ciscoasa(config)# tunnel-group remotegrp type remote-access
ciscoasa(config)# tunnel-group remotegrp general-attributes
ciscoasa(config-tunnel-webvpn)# authentication-server-group sdi_server
ciscoasa(config-tunnel-webvpn)# secondary-authentication-server-group ldap_server
ciscoasa(config-tunnel-webvpn)# 

secondary-color

To set a secondary color for the WebVPN login, home page, and file access page, use the secondary-color command in webvpn configuration mode. To remove a color from the configuration and reset the default, use the no form of this command.

secondary-color [ color ]

no secondary-color

Syntax Description

color

(Optional) Specifies the color. You can use a comma separated RGB value, an HTML color value, or the name of the color if recognized in HTML.

  • RGB format is 0,0,0, a range of decimal numbers from 0 to 255 for each color (red, green, blue); the comma separated entry indicates the level of intensity of each color to combine with the others.

  • HTML format is #000000, six digits in hexadecimal format; the first and second represent red, the third and fourth green, and the fifth and sixth represent blue.
  • Name length maximum is 32 characters

Command Default

The default secondary color is HTML #CCCCFF, a lavender shade.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Webvpn configuration

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

The number of RGB values recommended for use is 216, many fewer than the mathematical possibilities. Many displays can handle only 256 colors, and 40 of those look differently on MACs and PCs. For best results, check published RGB tables. To find RGB tables online, enter RGB in a search engine.

Examples

The following example shows how to set an HTML color value of #5F9EAO, which is a teal shade:


ciscoasa
(config)#
 webvpn
ciscoasa(config-webvpn)# secondary-color #5F9EAO

secondary-pre-fill-username

To enable the extraction of a username from a client certificate for use in double authentication for a clientless or an Secure Client connection, use the secondary-pre-fill-username command in tunnel-group webvpn-attributes mode. To remove the attribute from the configuration, use the no form of this command.

secondary-pre-fill-username { clientless | ssl-client } [ hide ]

secondary-pre-fill-username { clientless | ssl-client } hide [ use-primary-password | use-common-password [ type_num ] password ]

no secondary-pre-fill-username

Syntax Description

clientless

Enables this feature for clientless connections.

hide

Hides the username to be used for authentication from the VPN user.

password

Enter the password string.

client

ssl-client

Enables this feature for AnyConnect VPN client connections. Use the client keyword in 9.8(1)+.

type_num

Enter one of the following options:

  • 0 if the password to be entered is plain text.

  • 8 if the password to be entered is encrypted. The password appears as asterisks as you type.

use-common-password

Specifies a common secondary authentication password to use without prompting the user for it.

use-primary-password

Reuses the primary authentication password for secondary authentication without prompting the user for it.

Command Default

This feature is disabled by default. Entering this command without the hide keyword reveals the extracted username to the VPN user. The user receives a password prompt if you specify neither the use-primary-password nor the use-common-password keywords. The default value of type_num is 8.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tunnel-group webvpn-attributes configuration

  • Yes

  • Yes

Command History

Release

Modification

8.2(1)

This command was added.

8.3(2)

The [ use-primary-password | use-common-password [type_num ] password ] option was added.

9.8(1)

The ssl-client keyword was changed to client .

Usage Guidelines

To enable this feature, you must also enter the secondary-username-from-certificate command in tunnel-group general-attributes mode.

This command is meaningful only if double authentication is enabled. The secondary-pre-fill-username command enables the use of a username extracted from the certificate field specified in the secondary-username-from-certificate command as the username for secondary username/password authentication. To use this secondary-pre-fill username-from-certificate feature, you must configure both commands.


Note


Clientless and SSL-client connections are not mutually exclusive options. Only one can be specified per command line, but both can be enabled at the same time.


If you hide the second username and use a primary or common password, the user experience is similar to single authentication. Using the primary or common password makes the use of device certificates to authenticate a device a seamless user experience.

The use-primary-password keyword specifies the use of the primary password as the secondary password for all authentications.

The use-common-password keyword specifies the use of a common secondary password for all secondary authentications. If a device certificate installed on the endpoint contains a BIOS ID or some other identifier, a secondary authentication request can use the pre-filled BIOS ID as the second username and use a common password configured for all authentications in that tunnel group.

Examples

The following example creates an IPsec remote access tunnel group named remotegrp, and specifies the reuse of a name from the digital certificate on the endpoint as the name to be used for an authentication or authorization query when the connections are browser-based.


ciscoasa(config)# tunnel-group remotegrp type ipsec_ra
ciscoasa(config)# tunnel-group remotegrp webvpn-attributes
ciscoasa(config-tunnel-webvpn)# secondary-pre-fill-username clientless

The following example performs the same function as the previous command, but hides the extracted username from the user:


ciscoasa(config-tunnel-webvpn)# secondary-pre-fill-username clientless hide

The following example performs the same function as the previous command, except that it applies only to Secure Client connections:


ciscoasa(config-tunnel-webvpn)# secondary-pre-fill-username client hide

The following example hides the username and reuses the primary authentication password for secondary authentication without prompting the user:


ciscoasa(config-tunnel-webvpn)# secondary-pre-fill-username client hide use-primary-password

The following example hides the username and uses the password you enter for secondary authentication:


ciscoasa(config-tunnel-webvpn)# secondary-pre-fill-username client hide use-common-password **********

secondary-text-color

To set the secondary text color for the WebVPN login, home page and file access page, use the secondary-text-color command in webvpn mode. To remove the color from the configuration and reset the default, use the no form of this command.

secondary-text-color [ black | white ]

no secondary-text-color

Syntax Description

auto

Chooses black or white based on the settings for the text-color command. That is, if the primary color is black, this value is white.

black

The default secondary text color is black.

white

You can change the text color to white.

Command Default

The default secondary text color is black.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Webvpn

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Examples

The following example shows how to set the secondary text color to white:


ciscoasa
(config)#
 webvpn
ciscoasa(config-webvpn)# secondary-text-color white

secondary-username -from-certificate

To specify the field in a certificate to use as the secondary username for double authentication for a clientless or AnyConnect (SSL-client) connection, use the secondary-username-from-certificate command in tunnel-group general-attributes mode.

To remove the attribute from the configuration and restore default values, use the no form of this command.

secondary-username-from-certificate { primary-attr [ secondary-attr ] | use-entire-name | use-script }

no secondary-username-from-certificate

Syntax Description

primary-attr

Specifies the attribute to use to derive a username for an authorization query from a certificate. If pre-fill-username is enabled, the derived name can also be used in an authentication query.

secondary-attr

(Optional) Specifies an additional attribute to use with the primary attribute to derive a username for an authentication or authorization query from a digital certificate. If pre-fill-username is enable, the derived name can also be used in an authentication query.

use-entire-name

Specifies that the ASA must use the entire subject DN (RFC1779) to derive a name for an authorization query from a digital certificate.

use-script

Specifies the use of a script file generated by Adaptive Security Device Manager (ASDM) to extract the DN fields from a certificate for use as a username.

Command Default

This feature is disabled by default and is meaningful only when double authentication is enabled.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tunnel-group general-attributes configuration

  • Yes

  • Yes

Command History

Release

Modification

8.2(1)

This command was added.

Usage Guidelines

This command is meaningful only when double authentication is enabled.

When double authentication is enabled. this command selects one or more fields in a certificate to use as the username. The secondary-username-from-certificate command forces the security appliance to use the specified certificate field as the second username for the second username/password authentication.

To use this derived username in the pre-fill username from certificate feature for the secondary username/password authentication or authorization, you must also configure the pre-fill-username and secondary-pre-fill-username commands in tunnel-group webvpn-attributes mode. That is, to use the secondary pre-fill username feature, you must configure both commands.

Possible values for primary and secondary attributes include the following:

Attribute

Definition

C

Country: the two-letter country abbreviation. These codes conform to ISO 3166 country abbreviations.

CN

Common Name: the name of a person, system, or other entity. Not available a s a secondary attribute.

DNQ

Domain Name Qualifier.

EA

E-mail address.

GENQ

Generational Qualifier.

GN

Given Name.

I

Initials.

L

Locality: the city or town where the organization is located.

N

Name.

O

Organization: the name of the company, institution, agency, association or other entity.

OU

Organizational Unit: the subgroup within the organization (O).

SER

Serial Number.

SN

Surname.

SP

State/Province: the state or province where the organization is located

T

Title.

UID

User Identifier.

UPN

User Principal Name.

use-entire-name

Use entire DN name. Not available a s a secondary attribute.

use-script

Use a script file generated by ASDM.


Note


If you also specify the secondary-authentication-server-group command, along with the secondary-username-from-certificate command, only the primary username is used for authentication.

Examples

The following example, entered in global configuration mode, creates a remote access tunnel group named remotegrp and specifies the use of CN (Common Name) as the primary attribute and OU as the secondary attribute to use to derive a name for an authorization query from a digital certificate:


ciscoasa(config)# tunnel-group remotegrp type remote-access
ciscoasa(config)# tunnel-group remotegrp general-attributes
ciscoasa(config-tunnel-general)# username-from-certificate CN
ciscoasa(config-tunnel-general)# secondary-username-from-certificate OU
ciscoasa(config-tunnel-general)# 

The following example shows how to modify the tunnel-group attributes to configure the pre-fill username.


username-from-certificate {use-entire-name | use-script | <primary-attr>} [secondary-attr] secondary-username-from-certificate {use-entire-name | use-script | <primary-attr>} [secondary-attr] ; used only for double-authentication

secondary-username-from-certificate-choice

To select the certificate from where the username should be used for pre-fill username field for secondary authentication or authorization, use the secondary-username-from-certificate-choice command. Use this command in tunnel-group general-attributes mode. To use the username from the default certificate, use the no form of the command.

secondary-username-from-certificate-choice { first-certificate | second-certificate }

no secondary-username-from-certificate-choice { first-certificate | second-certificate }

Syntax Description

first-certificate

Specifies if the username from the machine certificate sent in SSL or IKE to be used in pre-fill username field for secondary authentication.

second-certificate

Specifies if the username from the user certificate from client to be used in pre-fill username field for secondary authentication.

Command Default

The username for prefill is retrieved from the second certificate by default.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.14(1)

This command was added.

Usage Guidelines

The multiple certificates option allows certificate authentication of both the machine and user via certificates. The pre-fill username field allows a field from the certificates to be parsed and used for subsequent (primary and secondary)AAA authentication in a AAA and certificate authenticated connection. The username for prefill is always retrieved from the second (user) certificate received from the client.

Beginning with 9.14(1), ASA allows you to choose whether the first certificate (machine certificate) or second certificate (user certificate) should be used to derive the username for the pre-fill username field.

This command is available and can be configured for any tunnel groups irrespective of the authentication type (aaa, certificate, or multiple-certificate). However, the configuration takes effect only for Multiple Certificate Authentication (multiple-certificate or aaa multiple-certificate). When the option is not used for Multiple Certificate Authentication, the second certificate is used by default for authentication or authorization purpose.

Examples

The following example shows how to configure the certificate to be used for prefill username for primary and secondary authentication or authorization:


ciscoasa(config)#tunnel-group tg1 type remote-access
ciscoasa(config)#tunnel-group tg1 general-attributes
ciscoasa(config-tunnel-general)# address-pool IPv4
ciscoasa(config-tunnel-general)# secondary-authentication-server-group LOCAL/<Auth-Server> 
ciscoasa(config-tunnel-general)# username-from-certificate-choice first-certificate
ciscoasa(config-tunnel-general)# secondary-username-from-certificate-choice first-certificate
ciscoasa(config)# tunnel-group tg1 webvpn-attributes
ciscoasa(config-tunnel-webvpn)# authentication aaa multiple-certificate
ciscoasa(config-tunnel-webvpn)# pre-fill-username client
ciscoasa(config-tunnel-webvpn)# secondary-pre-fill-username client

secure-unit-authentication

To enable secure unit authentication, use the secure-unit-authentication enable command in group-policy configuration mode. To disable secure unit authentication, use the secure-unit-authentication disable command. To remove the secure unit authentication attribute from the running configuration, use the no form of this command.

secure-unit-authentication { enable | disable }

no secure-unit-authentication

Syntax Description

disable

Disables secure unit authentication.

enable

Enables secure unit authentication.

Command Default

Secure unit authentication is disabled.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Group-policy configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

Secure unit authentication requires that you have an authentication server group configured for the tunnel group the hardware client(s) use.

If you require secure unit authentication on the primary ASA, be sure to configure it on any backup servers as well.

The no option allows inheritance of a value for secure unit authentication from another group policy.

Secure unit authentication provides additional security by requiring VPN hardware clients to authenticate with a username and password each time the client initiates a tunnel. With this feature enabled, the hardware client does not have a saved username and password.


Note


With this feature enabled, to bring up a VPN tunnel, a user must be present to enter the username and password.

Examples

The following example shows how to enable secure unit authentication for the group policy named FirstGroup:


ciscoasa(config)# group-policy FirstGroup attributes
ciscoasa(config-group-policy)# secure-unit-authentication
 enable

security-group

To add a security group to a security object group for use with Cisco TrustSec, use the security-group command in object-group security configuration mode. To remove the security group, use the no form of this command.

security-group { tag sgt## | name sg_name }

no security-group { tag sgt## | name sg_name }

Syntax Description

tag sgt#

Specifies the security group object as an inline tag. Enter a number from 1 to 65533 for a Tag security type.

An SGT is assigned to a device through IEEE 802.1X authentication, web authentication, or MAC authentication bypass (MAB) by the ISE. Security group names are created on the ISE and provide user-friendly names for security groups. The security group table maps SGTs to security group names.

name sg_name

Specifies the security group object as a named object. Enter a 32-byte case-sensitive string for a Name security type. The sg_name can contain any character including [a-z], [A-Z], [0-9], [!@#$%^&()-_{}. ].

Command Default

No default behavior or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Object-group security configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

You can create security group object groups for use in features that support Cisco TrustSec by including the group in an extended ACL, which in turn can be used in an access rule, for example.

When integrated with Cisco TrustSec, the ASA downloads security group information from the ISE. The ISE acts as an identity repository, by providing Cisco TrustSec tag to user identity mapping and Cisco TrustSec tag to server resource mapping. You provision and manage security group access lists centrally on the ISE.

However, the ASA might have localized network resources that are not defined globally that require local security groups with localized security policies. Local security groups can contain nested security groups that are downloaded from the ISE. The ASA consolidates local and central security groups.

To create local security groups on the ASA, you create a local security object group. A local security object group can contain one or more nested security object groups or Security IDs or security group names. User can also create a new Security ID or security group name that does not exist on the ASA.

You can use the security object groups you create on the ASA to control access to network resources. You can use the security object group as part of an access group or service policy.

Examples

The following example shows how to configure a security group object:


ciscoasa(config)# object-group security mktg-sg
ciscoasa(config)# security-group name mktg
ciscoasa(config)# security-group tag 1

The following example shows how to configure a security group object:


ciscoasa(config)# object-group security mktg-sg-all
ciscoasa(config)# security-group name mktg-managers
ciscoasa(config)# group-object mktg-sg // nested object-group

security-group-tag

To configure a security group tag attribute in a remote access VPN group policy or for a user in the LOCAL user database, use the security-group-tag value command in group-policy or username configuration mode. To remove the security group tag attribute, use the no form of this command.

security-group-tag { none | value sgt }

no security-group-tag { none | value sgt }

Syntax Description

none

Do not set a security group tag for this group policy or user.

value sgt

Specifies the security group tag number.

Command Default

The default is security-group-tag none , which means that there is no security group tag in this attribute set.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Group-policy or username configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.3(1)

This command was added.

Usage Guidelines

ASA supports security group tagging of VPN sessions. You can assign a Security Group Tag (SGT) to a VPN session using an external AAA server, or by configuring a security group tag for a local user or for a VPN group policy. This tag can then be propagated through the Cisco TrustSec system over Layer 2 Ethernet. Security group tags are useful on group policies and for local users when the AAA server cannot provide an SGT.

Following is the typical process for assigning an SGT to a VPN user:

1. A user connects to a remote access VPN that uses a AAA server group containing ISE servers.

2. The ASA requests AAA information from ISE, which might include an SGT. The ASA also assigns an IP address for the user’s tunneled traffic.

3. The ASA uses AAA information to authenticate the user and creates a tunnel.

4. The ASA uses the SGT from AAA information and the assigned IP address to add an SGT in the Layer 2 header.

5. Packets that include the SGT are passed to the next peer device in the Cisco TrustSec network.

If there is no SGT in the attributes from the AAA server to assign to a VPN user, then the ASA uses the SGT in the group policy. If there is no SGT in the group policy, then tag 0x0 is assigned.

Examples

The following example shows how to configure SGT attributes for a group policy.


ciscoasa(config-group-policy)# security-group-tag value 101

security-level

To set the security level of an interface, use the security-level command in interface configuration mode. To set the security level to the default, use the no form of this command. The security level protects higher security networks from lower security networks by imposing additional protection between the two.

security-level number

no security-level

Syntax Description

number

An integer between 0 (lowest) and 100 (highest).

Command Default

By default, the security level is 0.

If you name an interface “inside” and you do not set the security level explicitly, then the ASA sets the security level to 100 (see the nameif command). You can change this level if desired.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Interface configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was moved from a keyword of the nameif command to an interface configuration mode command.

Usage Guidelines

The level controls the following behavior:

  • Network access—By default, there is an implicit permit from a higher security interface to a lower security interface (outbound). Hosts on the higher security interface can access any host on a lower security interface. You can limit access by applying an access list to the interface.

For same security interfaces, there is an implicit permit for interfaces to access other interfaces on the same security level or lower.

  • Inspection engines —Some inspection engines are dependent on the security level. For same security interfaces, inspection engines apply to traffic in either direction.

  • NetBIOS inspection engine—Applied only for outbound connections.

  • OraServ inspection engine—If a control connection for the OraServ port exists between a pair of hosts, then only an inbound data connection is permitted through the ASA.

  • Filt ering—HTTP(S) and FTP filtering applies only for outbound connections (from a higher level to a lower level).

For same security interfaces, you can filter traffic in either direction.

  • NAT control—When you enable NAT control, you must configure NAT for hosts on a higher security interface (inside) when they access hosts on a lower security interface (outside).

Without NAT control, or for same security interfaces, you can choose to use NAT between any interface, or you can choose not to use NAT. Keep in mind that configuring NAT for an outside interface might require a special keyword.

  • established com mand—This command allows return connections from a lower security host to a higher security host if there is already an established connection from the higher level host to the lower level host.

For same security interfaces, you can configure established commands for both directions.

Normally, interfaces on the same security level cannot communicate. If you want interfaces on the same security level to communicate, see the same-security-traffic command. You might want to assign two interfaces to the same level and allow them to communicate if you want to create more than 101 communicating interfaces, or you want protection features to be applied equally for traffic between two interfaces; for example, you have two departments that are equally secure.

If you change the security level of an interface, and you do not want to wait for existing connections to time out before the new security information is used, you can clear the connections using the clear local-host command.

Examples

The following example configures the security levels for two interfaces to be 100 and 0:


ciscoasa(config)# interface gigabitethernet0/0
ciscoasa(config-if)# nameif inside
ciscoasa(config-if)# security-level 100
ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface gigabitethernet0/1
ciscoasa(config-if)# nameif outside
ciscoasa(config-if)# security-level 0
ciscoasa(config-if)# ip address 10.1.2.1 255.255.255.0
ciscoasa(config-if)# no shutdown

segment-id

To specify the VXLAN ID for a VNI interface, use the segment-id command in interface configuration mode. To remove the ID, use the no form of this command.

segment-idid

no segment-id id

Syntax Description

id

Sets the ID between 1 and 16777215.

Command Default

No default behavior or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Interface configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.4(1)

This command was added.

Usage Guidelines

The segment ID is used for VXLAN tagging.

Examples

The following example configures the VNI 1 interface and specifies a segment ID of 1000:


ciscoasa(config)# interface vni 1
ciscoasa(config-if)# segment-id 1000
ciscoasa(config-if)# vtep-nve 1
ciscoasa(config-if)# nameif vxlan1000
ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0 standby 10.1.1.2
ciscoasa(config-if)# ipv6 address 2001:0DB8::BA98:0:3210/48
ciscoasa(config-if)# security-level 50
ciscoasa(config-if)# mcast-group 236.0.0.100

send response

To send a RADIUS Accounting-Response Start and Accounting-Response Stop message to the sender of the RADIUS Accounting-Request Start and Stop messages, use the send response command in radius-accounting parameter configuration mode, which is accessed by using the inspect radius-accounting command.

This option is disabled by default.

send response

no send response

Syntax Description

This command has no arguments or keywords.

Command Default

No default behaviors or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Radius-accounting parameter configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.2(1)

This command was added.

Examples

The following example shows how to send a response with RADIUS accounting:


hostname(config)# policy-map type inspect radius-accounting ra
ciscoasa(config-pmap)# send response
ciscoasa(config-pmap-p)# send response

seq-past-window

To set the action for packets that have past-window sequence numbers (the sequence number of a received TCP packet is greater than the right edge of the TCP receiving window), use the seq-past-window command in tcp-map configuration mode. To set the value back to the default, use the no form of this command. This command is part of the TCP normalization policy enabled using the set connection advanced-options command.

seq-past-window { allow | drop }

no seq-past-window

Syntax Description

allow

Allows packets that have past-window sequence numbers. This action is only allowed if the queue-limit command is set to 0 (disabled).

drop

Drops packets that have past-window sequence numbers.

Command Default

The default action is to drop packets that have past-window sequence numbers.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tcp-map configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.2(4)/8.0(4)

This command was added.

Usage Guidelines

To enable TCP normalization, use the Modular Policy Framework:

1.tcp-map —Identifies the TCP normalization actions.

a.seq-past-window —In tcp-map configuration mode, you can enter the seq-past-window command and many others.

2.class-map —Identify the traffic on which you want to perform TCP normalization.

3.policy-map —Identify the actions associated with each class map.

a.class —Identify the class map on which you want to perform actions.

b.set connection advanced-options —Identify the tcp-map you created.

4.service-policy —Assigns the policy map to an interface or globally.

Examples

The following example sets the ASA to allow packets that have past-window sequence numbers:


ciscoasa(config)# tcp-map tmap
ciscoasa(config-tcp-map)# seq-past-window allow
ciscoasa(config)# class-map cmap
ciscoasa(config-cmap)# match any
ciscoasa(config)# policy-map pmap
ciscoasa(config-pmap)# class cmap
ciscoasa(config-pmap)# set connection advanced-options tmap
ciscoasa(config)# service-policy pmap global
ciscoasa(config)#

serial-number

To include the ASA serial number in the certificate during enrollment, use the serial-number command in crypto ca trustpoint configuration mode. To restore the default setting, use the no form of the command.

serial-number

no serial-number

Syntax Description

This command has no arguments or keywords.

Command Default

The default setting is to not include the serial number.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Crypto ca trustpoint configuration

  • Yes

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Examples

The following example enters crypto ca trustpoint configuration mode for trustpoint central, and includes the ASA serial number in the enrollment request for trustpoint central:


ciscoasa(config)# crypto ca trustpoint central
ciscoasa(ca-trustpoint)# serial-number

server (pop3s, imap4s, smtps) (Deprecated)


Note


The last supported release for this command was Version 9.5(1).

To specify a default e-mail proxy server, use the server command in the applicable e-mail proxy configuration mode. To remove the attribute from the configuration, use the no version of this command. The ASA sends requests to the default e-mail server when the user connects to the e-mail proxy without specifying a server. If you do not configure a default server, and a user does not specify a server, the ASA returns an error.

server { ipaddr or hostname }

no server

Syntax Description

hostname

The DNS name of the default e-mail proxy server.

ipaddr

The IP address of the default e-mail proxy server.

Command Default

There is no default e-mail proxy server by default.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Pop3s configuration

  • Yes

  • Yes

  • Yes

Imap4s configuration

  • Yes

  • Yes

  • Yes

Smtps configuration

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

9.5.2

This command was deprecated.

Examples

The following example shows how to set a default POP3S e-mail server with an IP address. of 10.1.1.7:


ciscoasa
(config)#
 pop3s
ciscoasa(config-pop3s)# server 10.1.1.7
         

server (scansafe general-options)

To configure the primary and backup Cloud Web Security proxy servers, use the server command in scansafe general-options configuration mode. To remove the server, use the no form of this command.

server { primary | backup } { ip ip_address | fqdn fqdn }[ port port ]

no server { primary | backup } { ip ip_address | fqdn fqdn }[ port port

Syntax Description

backup

Specifies that you are identifying the backup server.

ip ip_address

Specifies the server IP address.

fqdn fqdn

Specifies the server fully-qualified domain name (FQDN).

port port

(Optional) By default, the Cloud Web Security proxy server uses port 8080 for both HTTP and HTTPS traffic; do not change this value unless directed to do so.

primary

Specifies that you are identifying the primary server.

Command Default

The default port is 8080.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Scansafe general-options configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

When you subscribe to the Cisco Cloud Web Security service, you are assigned a primary Cloud Web Security proxy server and backup proxy server. These servers are routinely polled to check for their availability. If your ASA is unable to reach the Cloud Web Security proxy server (for example, if no SYN/ACK packets arrive from the proxy server), then the proxy server is polled through a TCP three-way handshake to check its availability. If the proxy server is unavailable after a configured number of retries (the default is five), the server is declared as unreachable, and the backup proxy server becomes active.


Note


You can further refine failover by checking the health of the Cloud Web Security application. In some cases, the server can complete the TCP three-way handshake, yet the Cloud Web Security application on the server is not functioning correctly. If you enable application health checking, the system can fail over to the backup server even if the three-way handshake completes, if the application itself does not respond. This provides a more reliable failover setup. Use the health-check application command to enable this extra check.

The ASA automatically falls back to the primary Cloud Web Security proxy server from the backup server after continued polling shows that the primary server is active for two consecutive retry count periods. You can change this polling interval using the retry-count command.

Traffic Conditions Under Which Proxy Server Is Not Reachable

Server Timeout Calculation

Connection Timeout Result

High traffic

Client half open connection timeout + ASA TCP connection timeout

(30 + 30) = 60 seconds

Single connection failure

Client half open connection timeout + ((retry threshold - 1) x (ASA TCP connection timeout))

(30 + ((5-1) x (30)) = 150 seconds

Idle—No connections are passing

15 minutes + ((retry threshold) x (ASA TCP connection timeout))

900 + (5 x (30) = 1050 seconds

Examples

The following example configures a primary and backup server. You must enter the command separately for the primary and backup server.


scansafe general-options
 server primary ip 10.24.0.62 port 8080
 server backup ip 10.10.0.7 port 8080
 health-check application 
 retry-count 7
 license 366C1D3F5CE67D33D3E9ACEC265261E5

server (ssh pubkey-chain)

To manually add or delete SSH servers and their keys from the ASA database for the on-board Secure Copy (SCP) client, use the server command in ssh pubkey-chain configuration mode. To remove a server and its host key, use the no form of this command.

server ip_address

no server ip_address

Syntax Description

ip_address

Specifies the SSH server IP address.

Command Default

No default behavior or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ssh pubkey-chain configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.1(5)

This command was added.

Usage Guidelines

You can copy files to and from the ASA using the on-board SCP client. The ASA stores the SSH host key for each SCP server to which it connects. You can manually add or delete servers and their keys from the ASA database if desired.

For each server, you can specify the key-string (public key) or key-hash (hashed value) of the SSH host.

Examples

The following example adds an already hashed host key for the server at 10.86.94.170:


ciscoasa(config)# ssh pubkey-chain
ciscoasa(config-ssh-pubkey-chain)# server 10.86.94.170
ciscoasa(config-ssh-pubkey-server)# key-hash sha256 65:d9:9d:fe:1a:bc:61:aa:64:9d:fc:ee:99:87:38:df:a8:8e:d9:e9:ff:42:de:e8:8d:2d:bf:a9:2b:85:2e:19

The following example adds a host string key for the server at 10.7.8.9:


ciscoasa(config)# ssh pubkey-chain
ciscoasa(config-ssh-pubkey-chain)# server 10.7.8.9
ciscoasa(config-ssh-pubkey-server)# key-string
Enter the base 64 encoded RSA public key.
End with the word "exit" on a line by itself
ciscoasa(config-ssh-pubkey-server-string)# c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87
ciscoasa(config-ssh-pubkey-server-string)# exit

server authenticate-client

To enable the ASA to authenticate the TLS client during TLS handshake, use the server authenticate-client command in tls-proxy configuration mode.

To bypass client authentication, use the no form of this command.

server authenticate-client

no server authenticate-client

Syntax Description

This command has arguments or keywords.

Command Default

This command is enabled by default, which means the TLS client is required to present a certificate during handshake with the ASA.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tls-proxy configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

8.0(4)

This command was added.

Usage Guidelines

Use the server authenticate-client command to control whether a client authentication is required during TLS Proxy handshake. When enabled (by default), the security appliance sends a Certificate Request TLS handshake message to the TLS client, and the TLS client is required to present its certificate.

Use the no form of this command to disable client authentication. Disabling TLS client authentication is suitable when the ASA must interoperate with CUMA client or clients such as a Web browser that are incapable of sending a client certificate.

Examples

The following example configures a TLS proxy instance with client authentication disabled:


ciscoasa(config)# tls-proxy mmp_tls
ciscoasa(config-tlsp)# no server authenticate-client
ciscoasa(config-tlsp)# server trust-point cuma_server_proxy

server cipher-suite

To define the ciphers that the TLS proxy server can use, use the server cipher suite command in tls-proxy configuration mode. To use the global cipher setting, use the no form of this command.

server cipher-suite cipher_list

no server cipher-suite cipher_list

Syntax Description

cipher_list

Sets the ciphers to include any combination of the following:

  • 3des-sha1

  • aes128-sha1

  • aes256-sha1

  • des-sha1

  • null-sha1

  • rc4-sha1

Separate multiple options with spaces.

Command Default

If you do not define the ciphers the TLS proxy can use, the proxy server uses the global cipher suite defined by the ssl cipher command. By default, the global cipher level is medium, which means all ciphers are available except for NULL-SHA, DES-CBC-SHA, and RC4-MD5.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tls-proxy configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.8(1)

We introduced this command.

Usage Guidelines

You can now set the SSL cipher suite when the ASA acts as a TLS proxy server. Formerly, you could only set global settings for the ASA using the ssl cipher command.

Specify the server cipher-suite command only if you want to use a different suite than the one generally available on the ASA (the ssl cipher command).

To set the minimum TLS version for all SSL server connections on the ASA, see the ssl server-version command. The default is TLS v1.0.

Examples

The following example sets the TLS proxy server ciphers:


ciscoasa(config)# tls-proxy test
ciscoasa(config-tlsp)# server cipher-list aes128-sha1 aes256-sha1

server-port

To configure a AAA server port for a host, use the server-port command in aaa-server host mode. To remove the designated server port, use the no form of this command.

server-port port-number

no server-port port-number

Syntax Description

port-number

A port number in the range of 0 through 65535.

Command Default

The default server ports are as follows:

  • SDI—5500

  • LDAP—389

  • Kerberos—88

  • NT—139

  • TACACS+—49

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Aaa-server group

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Examples

The following example configures an SDI AAA server named srvgrp1 to use server port number 8888:


ciscoasa
(config)# 
aaa-server srvgrp1 protocol sdi
ciscoasa
(config-aaa-server-group)# 
aaa-server srvgrp1 host 192.168.10.10
ciscoasa
(config-aaa-server-host)# 
server-port 8888

server-separator (pop3s, imap4s, smtps) (Deprecated)


Note


The last supported release for this command was Version 9.5(1).

To specify a character as a delimiter between the e-mail and VPN server names, use server-separator command in the applicable e-mail proxy mode. To revert to the default, “:”, use the no form of this command.

server-separator { symbol }

no server-separator

Syntax Description

symbol

The character that separates the e-mail and VPN server names. Choices are “@,” (at) “|” (pipe), “:”(colon), “#” (hash), “,” (comma), and “;” (semi-colon).

Command Default

The default is “@” (at).

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Pop3s

  • Yes

  • Yes

Imap4s

  • Yes

  • Yes

Smtps

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

9.5.2

This command was deprecated.

Usage Guidelines

The server separator must be different from the name separator.

Examples

The following example shows how to set a pipe (|) as the server separator for IMAP4S:


ciscoasa
(config)#
 imap4s
ciscoasa(config-imap4s)# server-separator |

server trust-point

To specify the proxy trustpoint certificate to present during TLS handshake, use the server trust-point command in TLS server configuration mode.

server trust-point proxy_trustpoint

Syntax Description

proxy_trustpoint

Specifies the trustpoint defined by the crypto ca trustpoint command.

Command Default

No default behavior or values.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

TLS-proxy configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

8.0(4)

This command was added.

Usage Guidelines

The trustpoint can be self-signed, enrolled with a certificate authority, or from an imported credential. The server trust-point command has precedence over the global ssl trust-point command.

The server trust-point command specifies the proxy trustpoint certificate presented during TLS handshake. The certificate must be owned by the ASA (identity certificate). The certificate can be self-signed, enrolled with a certificate authority, or from an imported credential.

Create TLS proxy instances for each entity that can initiate a connection. The entity that initiates the TLS connection is in the role of TLS client. Because the TLS Proxy has strict definition of client proxy and server proxy, two TLS proxy instances must be defined if either of the entities could initiate the connection.


Note


When you are creating the TLS proxy instance to use with the Phone Proxy, the server trustpoint is the internal Phone Proxy trustpoint created the CTL file instance. The trustpoint name is in the forminternal_PP_<ctl-file_instance_name>

Examples

The following example shows the use of the server trust-point command to specify the proxy trustpoint certificate to present during TLS handshake:


ciscoasa
(config-tlsp)# server trust-point ent_y_proxy

server-type

To manually configure the LDAP server model, use the server-type command in aaa-server host configuration mode. The ASA supports the following server models:

  • Microsoft Active Directory

  • Sun Microsystems JAVA System Directory Server, formerly named the Sun ONE Directory Server

  • Generic LDAP directory servers that comply with LDAPv3 (no password management)

To disable this command, use the no form of this command.

server-type { auto-detect | microsoft | sun | generic | openldap | novell }

no server-type { auto-detect | microsoft | sun | generic | openldap | novell }

Syntax Description

auto-detect

Specifies that the ASA determines the LDAP server type through auto-detection.

generic

Specifies LDAP v3-compliant directory servers other than Sun and Microsoft LDAP directory servers. Password management is not supported with generic LDAP servers.

microsoft

Specifies that the LDAP server is a Microsoft Active Directory.

openldap

Specifies that the LDAP server is an OpenLDAP server.

novell

Specifies that the LDAP server is a Novell server.

sun

Specifies that the LDAP server is a Sun Microsystems JAVA System Directory Server.

Command Default

By default, auto-detection attempts to determine the server type.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Aaa-server host configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.1(1)

This command was added.

8.0(2)

Support for the OpenLDAP and Novell server types was added.

Usage Guidelines

The ASA supports LDAP version 3 and is compatible with the Sun Microsystems JAVA System Directory Server, the Microsoft Active Directory, and other LDAPv3 directory servers.


Note


Sun—The DN configured on the ASA to access a Sun directory server must be able to access the default password policy on that server. We recommend using the directory administrator, or a user with directory administrator privileges, as the DN. Alternatively, you can place an ACI on the default password policy.
  • Microsoft—You must configure LDAP over SSL to enable password management with Microsoft Active Directory.

  • Generic—Password management features are not supported.


By default, the ASA auto-detects whether it is connected to a Microsoft directory server, a Sun LDAP directory server, or a generic LDAPv3 server. However, if auto-detection fails to determine the LDAP server type and if you know the server is either a Microsoft or Sun server, you can use the server-type command to manually configure the server as either a Microsoft or a Sun Microsystems LDAP server.

Examples

The following example, entered in aaa-server host configuration mode, configures the server type for the LDAP server ldapsvr1 at IP address 10.10.0.1. The first example configures a Sun Microsystems LDAP server.


ciscoasa(config)# aaa-server ldapsvr1 protocol ldap
ciscoasa(config-aaa-server-group)# aaa-server ldapsvr1 host 10.10.0.1
ciscoasa(config-aaa-server-host)# server-type sun
         

The following example specifies that the ASA use auto-detection to determine the server type:


ciscoasa(config)# aaa-server ldapsvr1 protocol LDAP
ciscoasa(config-aaa-server-group)# aaa-server ldapsvr1 host 10.10.0.1
ciscoasa(config-aaa-server-host)# server-type auto-detect
         

service (ctl-provider)

To specify the port to which the Certificate Trust List provider listens, use the service command in CTL provider configuration mode. To remove the configuration, use the no form of this command.

service port listening_port

no service port listening_port

Syntax Description

port listening_port

Specifies the certificate to be exported to the client.

Command Default

Default port is 2444.

Command Modes

The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl provider configuration