In cloud-based deployments, the user's primary authentication is to the Cisco WebEx Messenger service. Cisco WebEx hosts all services. You manage and monitor cloud-based deployments with the Cisco WebEx Administration
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.
If you deploy the client in phone mode, it connects to Cisco Unified
Communications Manager to authenticate users and retrieve configuration from the TFTP service. The client can connect to Cisco Unified
Communications Manager in the following ways:
Users enter the TFTP server address in the Connection Settings window when they start Cisco Jabber for
You specify the TFTP server address during installation. Cisco Jabber for
Windows can then get the TFTP server address from a bootstrap file when it starts.
Users set the TFTP server address in the Connection Settings window. Cisco Jabber for
Windows can then connect to the TFTP server and retrieve the client configuration file and the device configuration file.
You can specify the TFTP server address during installation with the following argument: TFTP.
The installation program then saves the TFTP server address to a bootstrap file. Cisco Jabber for
Windows gets the TFTP server address from the bootstrap file when it starts. It can then connect to the TFTP server and retrieve the client configuration file and the device configuration file.
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
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
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
Cisco Jabber for
Windows searches the directory to add contacts and to resolve contacts and phone numbers. To successfully deploy Cisco Jabber for
Windows, 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
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.
LDAP-based directory servers
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
Default ports are as follows:
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
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:
Each time the client starts, it attempts to connect to the primary server. The client attempts to connect to the secondary server if:
The primary server is not available.
The primary server fails after the client connects to it.
If the connection to the secondary server is successful, the client keeps the connection to the secondary server until the next restart.
If the secondary server fails while the client is connected to it, the client attempts to connect to the primary server.
By default, the client uses Generic Security Service API (GSS-API) to authenticate with the directory server. GSS-API leverages the system authentication mechanism. In a Microsoft Windows environment, GSS-API lets you connect to the directory server using Integrated Windows Authentication.
The following XML snippet shows the default configuration for directory authentication:
By default, the client authenticates with the directory server with the user's Microsoft Windows credentials.
In certain scenarios, it is not possible to authenticate with the directory server with Microsoft Windows credentials. In this case, you can do one of the following:
Use an anonymous bind.
Manually specify a well-known or public set of credentials that are linked to an account with read-only permissions. You specify the credentials in the client configuration with the following parameters:
The client transmits and stores these credentials as plain text. You should use the ConnectionUsername and ConnectionPassword parameters only in deployments where you cannot authenticate with the directory server using Microsoft Windows credentials.
Use GSS-API or Simple Authentication
The UseSecureConnection parameter lets you do one of the following:
Use GSS-API, which is the default setting.
Use simple authentication.
Simple authentication lets you connect to the directory server using simple binds, as in the following example configuration:
As a result, the client uses SSL to encrypt the credentials in the client configuration.
You can use SSL with a Global
Catalog, Domain Controller, or other LDAP directory server.
The SSL connection certificate must be present:
In the Microsoft Windows certificate store.
On the directory server to which the client connects.
To establish an SSL connection, the server presents the client with the certificate. The client then validates the certificate from the server against the certificate in the store on the client computer.
Default protocols and ports for SSL connections are as follows:
Port number: 3269
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:
Additionally, ensure you index the following attributes for secondary number queries:
By default secondary number queries are enabled in Cisco Jabber for
Windows. You can disable secondary number queries with the DisableSecondaryNumberLookups parameter.
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.
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.
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.
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,
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,
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:
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
The optimum dimensions for contact photos are 128 pixels by 128 pixels with an aspect ratio of 1:1.
128 pixels by 128 pixels are the maximum dimensions for local contact photos in Microsoft Outlook.
The following table lists the different dimensions for contact photos in Cisco Jabber for
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:
32 pixels by 32 pixels
Contact Photo Adjustments
Cisco Jabber for
Windows adjusts contact photos as follows:
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.
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.
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.
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.
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.
Cisco Jabber for
Windows rounds the corners of contact photos after retrieving them from your directory.
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
Intradomain federation enables users within the same domain to share availability and send instant messages between Cisco Unified Presence and Microsoft Office
Communications Server, 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 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
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 configuration files.
To resolve contacts during contact search or retrieve contact information from your directory, Cisco Jabber 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
Set the value of the UseSIPURIToResolveContacts parameter to true.
Specify an attribute that contains the contact ID that Cisco Jabber uses to retrieve contact information as the value of the SipUri parameter. The default value is msRTCSIP-PrimaryUserAddress.
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:
You must specify the SSO_ORG_DOMAIN argument during installation to enable Cisco Jabber for
Windows for SSO in cloud-based deployments.
The client must detect Webex as the authentication source using one of the other deployment methods (Service Discovery, installer switches, or manual configuration) before cloud-based SSO can be successfully enabled with the SSO_ORG_DOMAIN argument.
Cisco AnyConnect Deployments
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
Provides a service to secure remote access.
Cisco AnyConnect Secure
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
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, or session persistence, lets Cisco AnyConnect Secure
Mobility Client recover from session disruptions and re-establish sessions.
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
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
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.
Import a root certificate from the CA to the ASA.
Generate an identity certificate for the ASA.
Use the ASA identity certificate for SSL authentication.
Configure a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP).
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 :