For all deployments, the user's primary authentication is to a presence server. You must provision users with instant messaging and presence capabilities as the base for your deployment. You can then provision users with additional services, depending on your requirements.
Full UC
To deploy full UC, you enable instant messaging and presence capabilities. You then provision users with devices for audio and video in addition to voicemail and conferencing capabilities.
Cisco Jabber for Everyone (IM Only)
To deploy Cisco Jabber for Everyone, you enable instant messaging and presence capabilities. You can optionally provision users with desk phone devices that they can control with the client.
Diagram with Cisco Unified Presence
The following diagram illustrates the architecture of an on-premises deployment that includes Cisco Unified Presence:
Figure 1. On-Premises architecture
The following are the services available in an on-premises deployment:
Presence
Users can publish their availability and subscribe to other users' availability through Cisco Unified Presence.
Instant Messaging
Users send and receive instant messages through Cisco Unified Presence.
Audio Calls
Users place audio calls through desk phone devices or on their computers through Cisco Unified Communications Manager.
Video
Users share their screens and place video calls through Cisco Unified Communications Manager.
Voicemail
Users send and receive voice messages through Cisco Unity Connection.
Conferencing
Integrate with one of the following:
Cisco WebEx Meeting Center
Provides hosted meeting capabilities.
Cisco WebEx Meetings Server
Provides on-premises meeting capabilities.
For information about contact sources in on-premises deployments, see Directory Service in On-Premises Deployments.
A cloud-based deployment is one in which Cisco WebEx hosts services. You manage and monitor your cloud-based deployment with the Cisco WebEx Administration Tool.
Users set the presence server address in the Connection Settings window. Cisco Jabber for Windows can then connect to the presence server to authenticate users and retrieve service profiles.
You can specify the presence server address during installation with the following argument: ADDRESS.
The installation program then saves the presence server address to a bootstrap file. Cisco Jabber for Windows gets the presence server address from the bootstrap file when it starts. It can then connect to the presence server to authenticate users and retrieve service profiles.
Cisco Jabber for Windows can automatically discover either Cisco Unified Presence or Cisco Unified Communications IM and Presence if you do not specify the presence server address during installation.
When the client launches for the first time, it retrieves the presence server type from the bootstrap file.
The bootstrap file contains the settings you specify during installation.
You set the presence server type as the value of the TYPE argument during installation. In on-premises deployments, the value must be CUP.
To discover the presence server, the client must first determine the domain. It attempts to retrieve the domain from the following locations, in order of priority:
After it finds the domain, the client gets the presence server address from the Domain Name Server (DNS).
When the client gets the presence server address, it connects to the presence server and then caches the address of the presence server.
If a redirect occurs to another server in the cluster, the client caches the address of the presence server to which it connects, not the address of the server before the redirect.
Cisco Jabber for Windows retrieves the _cuplogin._tcp SRV record from the Domain Name Server (DNS) to lookup either Cisco Unified Presence or Cisco Unified Communications IM and Presence.
Notes:
You must add this SRV record to the DNS server on the presence server domain.
Cisco Jabber for Windows uses port 8443 to connect to Cisco Unified Presence.
Cisco Jabber for Windows supports weight and priority in SRV records.
Users set Cisco WebEx as the value of the Server type property in the Connection Settings window. Cisco Jabber for Windows can then connect to the Cisco WebEx Messenger service to authenticate users and retrieve configuration and services.
You specify WebEx as value of the TYPE argument during installation.
The installation program then saves that value to a bootstrap file. Cisco Jabber for Windows gets the value from the bootstrap file when it starts. It can then connect to the Cisco WebEx Messenger service to authenticate users and retrieve configuration and services.
After the client connects to the Cisco WebEx Messenger service, users get instant messaging and presence capabilities and contact resolution. Users can also get conferencing capabilities if you enable hosted conferencing with Cisco WebEx Meeting Center.
In hybrid cloud-based deployments, the client gets the connection details for on-premises services. You specify the connection details with the Cisco WebEx Administration Tool.
If the deployment includes Cisco Unity Connection, the client connects to the voicemail service.
If the deployment includes Cisco Unified Communications Manager, the client does the following:
Retrieves the device list for the user.
Retrieves the device configuration from the TFTP server.
Registers with Cisco Unified Communications Manager.
Cisco Jabber for Windows searches the directory to add contacts and to resolve contacts and phone numbers. To successfully deploy Cisco Jabber for Windows in an on-premises deployment, you should understand the directory infrastructure of the environment into which you plan to install the client. You can then choose a contact source that is most suited to that environment.
This section explains the different contact sources you can choose and what, if any, configuration you must perform to deploy Cisco Jabber for Windows with each contact source.
Configure Directory Integration with On-Premises Servers
When you set up an on-premises deployment, you should configure Cisco Unified Communications Manager to do both of the following:
Synchronize with the directory server.
Authenticate with the directory server.
Synchronizing with the directory server replicates contact data from your directory to Cisco Unified Communications Manager.
Enabling authentication with the directory server lets Cisco Unified Communications Manager proxy authentication from the client to the directory server. In this way, users authenticate with the directory server, not with Cisco Unified Communications Manager or a presence server.
See Configuring Cisco Unified Communications Manager Directory Integration for more information about configuring directory integration.
See the Server Setup Guide for instructions on configuring directory integration for on-premises deployments.
Cisco Jabber for Windows retrieves the fully qualified DNS domain from the USERDNSDOMAIN environment variable on the client workstation.
After Cisco Jabber for Windows gets the DNS domain, it can locate the Domain Name Server and retrieve SRV records.
In some instances, the value of the USERDNSDOMAIN environment variable does not resolve to the DNS domain that corresponds to the domain of the entire forest. For example, when an organization uses a sub-domain or resource domain. In this case, the USERDNSDOMAIN environment variable resolves to a child domain, not the parent domain. As a result, Cisco Jabber for Windows cannot access information for all users in the organization.
If the USERDNSDOMAIN environment variable resolves to a child domain, you can use one of the following options to enable Cisco Jabber for Windows to connect to a service in the parent domain:
Ensure that the Global Catalog or LDAP server can access all users in the organization.
Configure your DNS server to direct Cisco Jabber for Windows to a server that can access all users in the organization when Cisco Jabber for Windows requests a Global Catalog or LDAP server.
Configure Cisco Jabber for Windows to use the FQDN of the parent domain.
Specify the FQDN of the parent domain as the value of the PrimaryServerName parameter in your Cisco Jabber for Windows configuration as follows:
Cisco Jabber for Windows can automatically discover and connect to the directory server if:
The workstation on which you install Cisco Jabber for Windows is on the Windows domain.
Cisco Jabber for Windows can retrieve the address of the directory server from a DNS SRV record.
Directory Server
SRV Record
Global Catalog
_gc._msdcs._tcp.domain.com
Domain Controller
LDAP-based directory servers
_ldap._msdcs._tcp.domain.com
Default Server Connection
The client connects to a Global Catalog by default. The Global Catalog holds primary directory attributes for all users in your Microsoft Windows domain forest.
If required, you can use the ConnectionType parameter to configure the client to connect to a Domain Controller instead of a Global Catalog.
Note
Default ports are as follows:
Global Catalog: 3268
Domain Controller: 389
LDAP Directory Servers
Cisco Jabber for Windows supports LDAP directory servers such as OpenLDAP. See the list of supported directory servers in the Directory Servers topic.
You must use specific configurations to integrate with OpenLDAP and Active Directory Lightweight Directory Service (AD LDS) or Active Directory Application Mode (ADAM). See the Directory Server Configuration Examples section for more information and configuration examples.
You can specify server names and port numbers of directory servers for manual access.
Configure the client to connect to a primary and secondary server with the following parameters:
PrimaryServerName
ServerPort1
SecondaryServerName
ServerPort2
Each time the client starts, it attempts to connect to the primary server. If the primary server is not available, the client attempts to connect to the secondary server. If the connection to the secondary server is successful, the client keeps the connection to the secondary server until the next restart.
Connection Credentials
By default, the client uses Microsoft Windows usernames and passwords to connect to the directory service. You can specify a connection username and password to access a directory service other than EDI or to use a set of common credentials for all users.
The UseWindowsCredentials parameter specifies if you use Microsoft Windows credentials to connect to your directory.
Set credentials with the following parameters:
ConnectionUsername
ConnectionPassword
Simple Authentication and SSL
By default, the client uses simple authentication to connect to the directory service. The UseSecureConnection parameter lets you enable or disable simple authentication.
You can use SSL for connections to your directory with the UseSSL parameter. You can use SSL with a Global Catalog, Domain Controller, or other LDAP directory server. However, the SSL connection certificate must exist in the Microsoft Windows certificate store. In a Microsoft Windows domain, the SSL connection certificate is typically present in the certificate store on the client computer.
Note
Default protocols and ports for SSL connections are as follows:
Global Catalog
Protocol: TCP
Port number: 3269
Domain Controller
Protocol: TCP
Port number: 636
Attributes on the Directory Server
You must index attributes on your directory server so that Cisco Jabber for Windows can resolve contacts.
If you use the default attribute mappings, ensure the following attributes are indexed:
sAMAccountName
telephoneNumber
Additionally, ensure you index the following attributes for secondary number queries:
otherTelephone
mobile
homePhone
Note
By default secondary number queries are enabled in Cisco Jabber for Windows. You can disable secondary number queries with the DisableSecondaryNumberLookups parameter.
msRTCSIP-PrimaryUserAddress
You should index msRTCSIP-PrimaryUserAddress for intradomain federation only.
Because the client connects to a Global Catalog server by default, you must ensure that all attributes reside on your Global Catalog server. You can replicate attributes to a Global Catalog server using an appropriate tool such as the Microsoft Active Directory Schema snap-in.
Replicating attributes to your Global Catalog server generates traffic between Active Directory servers in the domain. For this reason, you should replicate attributes to your Global Catalog server at a time when network traffic can handle extra load.
If you do not want to replicate attributes to a Global Catalog server, you can configure Cisco Jabber for Windows to connect to a Domain Controller. However, the client queries single domains only when it connects to a Domain Controller.
Predictive Search
When Cisco Jabber for Windows performs a predictive search, it issues a query using Ambiguous Name Resolution (ANR). This query disambiguates the search string and returns results that match the attributes that are set for ANR on your directory server.
Important:
You must configure your directory server to set attributes for ANR if you want the client to search for those attributes.
See the following Microsoft documentation for more information on ANR:
Ambiguous Name Resolution for LDAP in Windows 2000
LDAP Referrals, see the Ambiguous Name Resolution section
Common Default Attributes Set for Active Directory and Global Catalog
With the example values in the preceding steps, the sAMAccountName attribute might resolve to msmith in your directory. Cisco Jabber for Windows then takes this value and replaces the token to build the following URL: http://staffphoto.example.com/msmith.jpg.
Binary objects
Cisco Jabber for Windows retrieves the binary data for the photo from your database.
To use this method to retrieve contact photos, specify the attribute that contains the binary data as the value of the PhotoSource parameter in the configuration; for example,
<PhotoSource>jpegPhoto</PhotoSource>
PhotoURL attribute
Cisco Jabber for Windows retrieves a URL from a directory attribute.
To use this method to retrieve contact photos, specify the attribute that contains the photo URL as the value of the PhotoSource parameter in the configuration; for example,
<PhotoSource>photoUri</PhotoSource>
Refreshing Contact Photos
This section describes a limitation that currently exists if you use the URI substitution method or binary object method to retrieve contact photos from your directory.
When Cisco Jabber for Windows retrieves contact photos from the directory, it caches those photos in the following location on the users' file systems: %USER_PROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Photos
After Cisco Jabber for Windows caches a contact photo, it does not retrieve that photo again from the directory. If you update contact photos in your directory, users do not automatically get those updated contact photos. Users must exit Cisco Jabber for Windows and then manually delete the folder that contains the cached photos on their file systems.
Cisco Unified Communications Manager User Data Service
UDS is a REST interface on Cisco Unified Communications Manager that provides contact resolution. You synchronize contact data into Cisco Unified Communications Manager from a directory server. Cisco Jabber for Windows then automatically retrieves that contact data directly from UDS.
Important:
A known issue in UDS exists on versions of Cisco Unified Communications Manager lower than 8.6.2. This known issue prevents successful contact resolution. As a result, Cisco Jabber for Windows supports UDS on Cisco Unified Communications Manager version 8.6.2 or later.
To enable integration with UDS, perform the following steps:
Procedure
Step 1
Create your directory source in Cisco Unified Communications Manager.
Step 2
Synchronize the contact data to Cisco Unified Communications Manager.
After the synchronization occurs, your contact data resides in Cisco Unified Communications Manager.
Step 3
Provision users with CCMCIP profiles on Cisco Unified Presence or Cisco Unified Communications IM and Presence.
The client requires a CCMCIP profile that contains the primary Cisco Unified Communications Manager server address. The client uses the CCMCIP profile to locate Cisco Unified Communications Manager and resolve contacts with UDS.
Step 4
Specify UDS as the value of the DirectoryServerType parameter in your configuration file.
The following is an example configuration where UDS is the directory server type:
UDS dynamically builds a URL to contact photos with a directory attribute and a URL template.
To resolve contact photos with UDS, you specify the format of the contact photo URL as the value of the PhotoUriWithToken parameter. You also include a %%uid%% token to replace the contact username in the URL, for example,
UDS substitutes the %%uid%% token with the value of the userName attribute in UDS. For example, a user named Mary Smith exists in your directory. The value of the userName attribute for Mary Smith is msmith. To resolve the contact photo for Mary Smith, Cisco Jabber for Windows takes the value of the userName attribute and replaces the %%uid%% token to build the following URL: http://staffphoto.example.com/msmith.jpg
Restriction:
All contact photos must follow the format of the URL you specify as the value of PhotoUriWithToken.
You can set service parameters for UDS on Cisco Unified Communications Manager.
Procedure
Step 1
Open the Cisco Unified CM Administration interface.
Step 2
Select System > Enterprise Parameters.
The Enterprise Parameters Configuration window opens.
Step 3
Locate the User Data Service Parameters section.
UDS Service Parameters
Set values for the following service parameters to configure UDS:
Parameter
Description
Enable All User Search
Allows searches for all users in the directory.
User Search Limit
Limits the number of users returned in a query.
Number of Digits to Match
Specifies the number of digits to match when users search for phone numbers.
Tip
To resolve PSTN numbers, you should set the value as equal to the number of digits in the PSTN numbers. For example, if the PSTN numbers have 10 digits, set the value to 10.
Contact Resolution with Multiple Clusters
For contact resolution with multiple Cisco Unified Communications Manager clusters, you should synchronize all users on the corporate directory to each Cisco Unified Communications Manager cluster. You should then provision a subset of those users on the appropriate Cisco Unified Communications Manager cluster.
For example, your organization has 40,000 users. 20,000 users reside in North America. 20,000 users reside in Europe. Your organization has the following Cisco Unified Communications Manager clusters for each location:
cucm-cluster-na for North America
cucm-cluster-eu for Europe
In this example, you should synchronize all 40,000 users to both clusters. You then provision the 20,000 users in North America on cucu-cluster-na and the 20,000 users in Europe on cucm-cluster-eu.
When users in Europe call users in North America, Cisco Jabber for Windows retrieves the contact details for the user in Europe from cucu-cluster-na.
When users in North America call users in Europe, Cisco Jabber for Windows retrieves the contact details for the user in North America from cucu-cluster-eu.
Directory Configuration Parameters
By default, you do not need to configure Cisco Jabber for Windows to connect to the directory service. If you install Cisco Jabber for Windows on a workstation that is registered to an Active Directory domain, Cisco Jabber for Windows automatically discovers the directory service and connects to a Global Catalog in the domain.
You can create custom configurations for LDAP services that include the following:
To achieve the best result with Cisco Jabber for Windows, your contact photos should have specific formats and dimensions. Review supported formats and optimal dimensions. Learn about adjustments Cisco Jabber for Windows makes to contact photos.
Cisco Jabber for Windows supports the following formats for contact photos in your directory:
JPG
PNG
BMP
GIF
Important:
Cisco Jabber for Windows does not apply any modifications to enhance rendering for contact photos in GIF format. As a result, contact photos in GIF format might render incorrectly or with less than optimal quality. To obtain the best quality, you should use PNG format for your contact photos.
Contact Photo Dimensions
Tip
The optimum dimensions for contact photos are 128 pixels by 128 pixels with an aspect ratio of 1:1.
The following table lists the different dimensions for contact photos in Cisco Jabber for Windows:
Location
Dimensions
Audio call window
128 pixels by 128 pixels
Invitations and reminders, for example:
Incoming call windows
Meeting reminder windows
64 pixels by 64 pixels
Lists of contacts, for example:
Contact lists
Participant rosters
Call history
Voicemail messages
32 pixels by 32 pixels
Contact Photo Adjustments
Cisco Jabber for Windows adjusts contact photos as follows:
Resizing
If contact photos in your directory are smaller or larger than 128 pixels by 128 pixels, Cisco Jabber for Windows automatically resizes the photos. For example, contact photos in your directory are 64 pixels by 64 pixels. When Cisco Jabber for Windows retrieves the contact photos from your directory, it resizes the photos upwards to 128 pixels by 128 pixels.
Tip
Resizing contact photos can result in less than optimal resolution. For this reason, you should use contact photos that are 128 pixels by 128 pixels so that Cisco Jabber for Windows does not automatically resize them.
Cropping
Cisco Jabber for Windows automatically crops non-square contact photos to a square aspect ratio, or an aspect ratio of 1:1 where the width is the same as the height.
Portrait orientation
If contact photos in your directory have portrait orientation, Cisco Jabber for Windows crops 30 percent from the top and 70 percent from the bottom.
For example, if contact photos in your directory have a width of 100 pixels and a height of 200 pixels, Cisco Jabber for Windows needs to crop 100 pixels from the height to achieve an aspect ratio of 1:1. In this case, Cisco Jabber for Windows crops 30 pixels from the top of the photos and 70 pixels from the bottom of the photos.
Landscape orientation
If contact photos in your directory have landscape orientation, Cisco Jabber for Windows crops 50 percent from each side.
For example, if contact photos in your directory have a width of 200 pixels and a height of 100 pixels, Cisco Jabber for Windows needs to crop 100 pixels from the width to achieve an aspect ratio of 1:1. In this case, Cisco Jabber for Windows crops 50 pixels from the right side of the photos and 50 pixels from the left side of the photos.
Rounding
Cisco Jabber for Windows rounds the corners of contact photos after retrieving them from your directory.
Domain Federation
Domain federation lets Cisco Jabber for Windows users communicate with users in other domains or with users in the same domain who use client applications other than Cisco Jabber for Windows.
Interdomain federation enables Cisco Jabber for Windows users in an enterprise domain to share availability and send instant messages with users in another domain.
Cisco Jabber for Windows users must manually enter contacts from another domain.
Cisco Jabber for Windows supports federation with the following servers:
Microsoft Office Communications Server
Microsoft Lync
IBM Sametime
XMPP standard-based environments such as Google Talk
AOL Instant Messenger
You configure interdomain federation for Cisco Jabber for Windows on Cisco Unified Presence or Cisco Unified Communications IM and Presence. See the following documentation for more information:
Cisco Unified Presence: Integration Guide for Configuring Cisco Unified Presence Release 8.6 for Interdomain Federation
Cisco Unified Communications IM and Presence: Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager
Intradomain federation enables users within the same domain to share availability and send instant messages between Cisco Unified Presence and Microsoft Office Communications Server, or Microsoft Live Communications Server, or other presence server.
Intradomain federation allows you to migrate users to Cisco Unified Presence or Cisco Unified Communications IM and Presence from a different presence server. For this reason, you configure intradomain federation for Cisco Jabber for Windows on the presence server. See the following documents for more information:
Cisco Unified Presence: Integration Guide for Configuring Partitioned Intradomain
Federation for Cisco Unified Presence Release 8.6 and Microsoft
LCS/OCS
Cisco Unified Communications IM and Presence: Partitioned Intradomain Federation for IM and Presence Service on Cisco Unified Communications Manager
In addition to configuring intradomain federation on the presence server, you might need to specify some configuration settings in the Cisco Jabber for Windows configuration files.
To resolve contacts during contact search or retrieve contact information from your directory, Cisco Jabber for Windows requires the contact ID for each user. Cisco Unified Presence uses a specific format for resolving contact information that does not always match the format on other presence servers such as Microsoft Office Communications Server or Microsoft Live Communications Server.
Procedure
Step 1
Set the value of the UseSIPURIToResolveContacts parameter to true.
Step 2
Specify an attribute that contains the contact ID that Cisco Jabber for Windows uses to retrieve contact information as the value of the SipUri parameter. The default value is msRTCSIP-PrimaryUserAddress.
Step 3
Specify any text that prefixes each contact ID as the value of the UriPrefix parameter.
The prefix is any text that exists before the username in the contact ID.
For example, you specify msRTCSIP-PrimaryUserAddress as the value of SipUri. In your directory the value of msRTCSIP-PrimaryUserAddress for each user has the following format: sip:username@domain.
The following XML snippet provides an example of the resulting configuration:
In cloud-based deployments, Cisco Jabber for Windows supports SSO with the Cisco WebEx Messenger service.
The following steps describe the login flow for cloud-based SSO after users start Cisco Jabber for Windows:
Cisco Jabber for Windows sends a login request to the Cisco WebEx Messenger service.
The Cisco WebEx Messenger service redirects Cisco Jabber for Windows to the domain where your identity provider resides.
Cisco Jabber for Windows follows the redirect and requests a login token from the identity provider.
The identity provider gives a login token to Cisco Jabber for Windows.
Cisco Jabber for Windows passes that login token to the Cisco WebEx Messenger service.
As a result, Cisco Jabber for Windows authenticates with the Cisco WebEx Messenger service.
The following diagram illustrates the login flow for cloud-based SSO:
Figure 5. Cloud-Based SSO Login Flow
Note
The identity provider must be Security Assertion Markup Language (SAML) compliant. Cisco Jabber for Windows has been tested with, and supports, the following products as identity providers:
PingFederate
Microsoft Active Directory Federation Services (ADFS)
Cisco AnyConnect refers to a server-client infrastructure that enables Cisco Jabber for Windows to connect securely to your corporate network from remote locations such as Wi-Fi networks or mobile data networks.
The Cisco AnyConnect environment includes the following components:
Cisco Adaptive Security Appliance (ASA)
Provides a service to secure remote access.
Cisco AnyConnect Secure Mobility Client
Establishes an secure connection to Cisco Adaptive Security Appliance from the user's computer.
Cisco Jabber for Windows supports secure remote access with the following:
Cisco Adaptive Security Appliance provides a flexible architecture that can meet the needs of many different deployments. It is beyond the scope of this document to provide end-to-end deployment procedures. Rather, the purpose of this section is to provide information that you should consider when deploying Cisco Adaptive Security Appliance and Cisco AnyConnect Secure Mobility Client for Cisco Jabber for Windows.
You should refer to the configuration guides for Cisco Adaptive Security Appliance to obtain task-based information on installing and configuring ASA.
As part of the configuration process for ASA, you should also configure Network Address Translation (NAT) rules to support Cisco AnyConnect Secure Mobility Client. If you do not configure NAT rules, Cisco AnyConnect Secure Mobility Client cannot communicate with ASA.
The Configuring Network Object NAT topic provides detailed instructions for configuring NAT rules.
You can configure ASA session parameters to improve performance for secure connections. For the best user experience, you should configure the following ASA session parameters:
Datagram Transport Layer Security (DTLS)
DTLS is an SSL protocol that provides a data path that prevents latency and data loss.
Auto Reconnect
Auto reconnect, or session persistence, lets Cisco AnyConnect Secure Mobility Client recover from session disruptions and re-establish sessions.
Idle Timeout
Idle timeout defines a period of time after which ASA terminates secure connections, if no communication activity occurs.
Dead-Peer Detection (DTD)
DTD ensures that ASA and Cisco AnyConnect Secure Mobility Client can quickly detect failed connections.
Group Policies and Profiles
You should use the ASA Device Manager (ASDM) to create group policies, client profiles, and connection profiles. Create your group policies first and then apply those policies to the profiles. Using the ASDM to create profiles ensures that Cisco AnyConnect Secure Mobility Client downloads the profiles after it establishes a connection to ASA for the first time. The ASDM also lets you manage and maintain your policies and profiles in a central location.
See the Cisco AnyConnect Secure Mobility Client Administrator Guide for instructions on creating policies and profiles with the ASDM.
Trusted Network Detection is a feature that automates secure connections based on user location. When users leave the corporate network, Cisco AnyConnect Secure Mobility Client automatically detects that it is outside the trusted network and then initiates secure access.
You configure Trusted Network Detection on ASA as part of the client profile. See the Trusted Network Detection topic for more information.
Tunnel policies configure how Cisco AnyConnect Secure Mobility Client directs traffic over a secure connection and include the following:
Full Tunnel Policy
Lets you send all traffic over the secure connection to the ASA gateway.
Split Tunnel Policy
Enables you divide traffic based on destination subnets to send some traffic over the secure connection and other traffic over the non-secure connection.
Split Include Policy with Network ACL
Enables you to restrict secure connections based on destination IP addresses. For example, in an on-premises deployment, you can specify the IP addresses for Cisco Unified Communications Manager, Cisco Unified Presence, your TFTP server, and other servers to restrict the secure connection only to Cisco Jabber for Windows traffic.
Split Exclude Policy
Allows you to exclude certain traffic from the secure connection. You can allow Cisco Jabber for Windows traffic over the secure connection and then exclude traffic from specific destination subnets.
Cisco recommends that you use certificate-based authentication for negotiating a secure connection to ASA from Cisco AnyConnect Secure Mobility Client.
ASA supports certificates issued by standard Certificate Authority (CA) servers such as Cisco IOS CA, Microsoft Windows 2003, Windows 2008R2, Entrust, VeriSign, and RSA Keon. This topic gives you a high-level procedure for setting up ASA for certificate-based authentication. See the Configuring Digital Certificates topic in the appropriate ASA configuration guide for step-by-step instructions.
Procedure
Step 1
Import a root certificate from the CA to the ASA.
Step 2
Generate an identity certificate for the ASA.
Step 3
Use the ASA identity certificate for SSL authentication.
Step 4
Configure a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP).
Step 5
Configure the ASA to request client certificates for authentication.
What to Do Next
After you set up certificate-based authentication on ASA, you must distribute client certificates to your users. You can use one of the following methods with :
You can use Simple Certificate Enrollment Protocol (SCEP) on Microsoft Windows Server to securely issue and renew certificates for client authentication.
To distribute certificates with SCEP, you must install the SCEP module on Microsoft Windows Server. See the following topics for more information:
ASA 8.X: AnyConnect SCEP Enrollment Configuration Example
Simple Certificate Enrollment Protocol (SCEP) Add-on for Certificate Services