Note	All Jabber clients support the LDAPv3 standard for directory integration. Any directory server that supports this standard is compatible with these clients.

You can use the following contact source servers with Cisco Jabber:

• Active Directory Domain Services for Windows Server 2012 R2

• Active Directory Domain Services for Windows Server 2008 R2

• Cisco Unified Communications Manager User Data Server (UDS). Cisco Jabber supports UDS using Cisco Unified Communications Manager version 10.5 or higher.

• OpenLDAP

• Active Directory Lightweight Directory Service (AD LDS) or Active Directory Application Mode (ADAM)

CDI uses service discovery to determine the LDAP server.

The following are the default settings for on-premises deployments with CDI:

• Cisco Jabber integrates with Active Directory as the contact source.

• Cisco Jabber automatically discovers and connects to a Global Catalog.

We recommend that you use service discovery to automatically connect and authenticate with the Global Catalog (GC) server or the LDAP server. If you want to customize your deployment, review the options for providing the LDAP server information and the authentication options that are available. Jabber first sends DNS queries to the GC domain to discover the GC servers. If it doesn't discover the GC servers, Jabber then send DNS queries to the LDAP domain to discover the LDAP servers.

When there is a GC available, the client does the following:

1. Gets the DNS domain from the workstation and looks up the SRV record for the GC.

2. Retrieves the address of the GC from the SRV record.

3. Connects to the GC with the signed-in user's credentials.

Discovery Using the Global Catalog Domain

Jabber attempts to discover GC servers with a DNS SRV query. First, Jabber gets the GC domain:

1. If available, Jabber uses the DNSFORESTNAME environment variable as the GC domain.

2. If DNSFORESTNAME is not available, Jabber checks the following for the GC domain:

   • On Windows, Jabber calls the Windows DsGetDcName API to get DnsForestName.

   • On non-Windows platforms, Jabber reads LdapDNSForestDomain from jabber-config.xml.

After Jabber gets the GC domain, it sends a DNS SRV query to get the GC server address:

• On Windows, Jabber checks if SiteName is available through Windows DsGetSiteName API:

  • If SiteName exists, Jabber sends out the DNS SRV query, _gc._tcp.SiteName._sites.GCDomain, to get the GC server address.

  • If SiteName doesn't exist or no SRV record is returned for _gc._tcp.SiteName._sites.GCDomain, Jabber sends out the DNS SRV query, _gc._tcp.GCDomain, to get the GC server address.

• On a non-Windows platform, Jabber sends out the DNS SRV query, _gc._tcp.GCDomain, to get the GC server address.

Discovery Using the LDAP Domain

If Jabber cannot discover a GC server, it then attempts to discover the LDAP domain:

1. If available, Jabber uses the USERDNSDOMAIN environment variable as the LDAP domain.

2. If USERDNSDOMAIN is not available, Jabber reads LdapUserDomain from jabber-config.xml.

3. If LdapUserDomain is not available, Jabber uses the email domain with which the user signed in as the LDAP domain.

After Jabber gets the LDAP Domain, it sends a DNS SRV query to get the LDAP server address:

• On Windows, Jabber checks if SiteName is available through Windows DsGetSiteName API.

  • If SiteName exists, Jabber sends out the DNS SRV query, _ldap._tcp.SiteName.sites.LdapDomain, to get the LDAP server address.

  • If SiteName doesn't exist or no SRV record is returned for _ldap._tcp.SiteName.sites.LdapDomain, Jabber sends out the DNS SRV query, _ldap._tcp.LdapDomain, to get the LDAP server address.

• On a non-Windows platform, Jabber sends out the DNS SRV query, _ldap._tcp.LdapDomain, to get the LDAP server address.

Once Jabber connects to the LDAP server, it reads the LDAP server's SupportedSaslMechanisms attribute that specifies a list and order of authentication mechanisms to use.

Manual Configuration for the LDAP Service

1. You can configure the PrimaryServerName parameter to define a specific LDAP server for Jabber to connect to.

2. You can configure the LdapSupportedMechanisms parameter in the jabber-config.xml file to override the list from the supportedSaslMechanisms attribute.

   The Contact Service and the LDAP server must support each of these mechanisms. Use a space to separate multiple values.

   • GSSAPI – Kerberos v5

   • EXTERNAL – SASL external

   • PLAIN (default) – Simple LDAP bind, anonymous is a subset of simple bind.

   Example:

   <LdapSupportedMechanisms>GSSAPI EXTERNAL PLAIN</LdapSupportedMechanisms>

3. If necessary, configure the LdapUserDomain parameter to set the domain that Jabber uses to authenticate with the LDAP server. For example:

   CUCMUsername@LdapUserDomain

Cisco Directory Integration (CDI) parameters replace the Basic Directory Integration (BDI) and Enhanced Directory Integration (EDI) parameters. CDI parameters apply to all clients.

Cisco Jabber Deployment Scenarios

Scenario 1: If you are new to Jabber in 11.8

We recommend that you use service discovery to automatically connect and authenticate with the LDAP server. If you want to customize your deployment, review the options for providing the LDAP server information and the authentication options that are available.

Scenario 2: If you are upgrading to 11.8 from an EDI configuration

If your configuration only uses EDI parameters, then Jabber will read the EDI parameters and use those for your directory source integration. We still recommend that you upgrade your EDI parameters and replace them with the equivalent CDI parameters.

Scenario 3: If you are upgrading to 11.8 from a BDI configuration

If your configuration only uses BDI parameters, you must update the BDI parameters to the equivalent CDI parameters. For example, for the BDIPrimaryServerName you need to replace the parameter with PrimaryServerName. The BDIEnableTLS is replaced with the UseSSL parameter.

Scenario 4: If you are upgrading to 11.8 from a mixed EDI/BDI configuration

If your configuration uses both EDI and BDI, you must review your configuration for BDI as Jabber will use the EDI parameters when connecting to the LDAP server.

In Unified Communications Manager Release 12.5(1) SU2, Unified CM added support for securely passing encrypted LDAP credentials in the Service Profile. This update secures access to your directory by ensuring that the password is always stored and sent in an encrypted format. This change includes encryption during these processes:

• Directory access authentication

• Client configuration file downloads

• BAT imports/exports

• Upgrades

For more details, see the Release Notes for Cisco Unified Communications Manager and the IM and Presence Service, Release 12.5(1) SU2.

In Jabber 12.8 with this Unified CM release or later, we take advantage of this capability by downloading the LDAP credentials as part of User Profile after end-user authentication.

To connect Jabber to an LDAP server, define how LDAP authenticates Jabber users:

• The default option is that Jabber automatically connects to the contact source server using Kerberos or client certificates (SASL External). We recommend this option as it’s the most secure.

• If you define credentials in a service profile or in the jabber-config.xml file, they always take precedence over the default option.

• If you configure the LdapSupportedMechanisms parameter with the PLAIN value, but don't configure the directory profile username or password, then users can enter their directory credentials into the clients directly.

• Otherwise, if you connect to a secure port in the service profile, then you can define how Jabber connects to the contact source server. You define it by specifying the Cisco Unified Communications Manager credentials in the LDAP_UseCredentialsFrom parameter in the jabber-config.xml file.

• If the previous options aren’t available, then use a well-known set of credentials provided by the Service Profile or the jabber-config.xml file. This option is the least secure. Jabber uses an account to authenticate with the contact source server. We recommend that this account has read-only access to the directory and is a commonly known public set of credentials. In this case, all Jabber users use these credentials for searches.

Note

From Cisco Unified Communications Manager 12.0 version onwards, you can’t configure username and password in the service profile. Jabber users get an option to authenticate themselves for using directory services. Users get a notification when they sign in to Jabber for the first time. If they don't authenticate themselves that first time, then they get an alert when they are trying to access contact list.

Cisco Jabber uses the Jabber ID to search for contact information in the directory. There are a few options to optimize searching in the directory:

• Search base—By default the client starts a search at the root of a directory tree. You can use search bases to specify a different search start or to restrict searches to specific groups. For example, a subset of your users have instant messaging capabilities only. Include those users in an OU and then specify that as a search base.

• Base Filter—Specify a directory subkey name only to retrieve objects other than user objects when you query the directory.

• Predictive Search Filter—You can define multiple, comma-separated values to filter search queries. The default value is ANR(Ambiguous name resolution.)

For more information on these options, see the chapter on directory integration in the Parameters Reference Guide for Cisco Jabber.

For Cloud deployments, contact data is configured in Webex Messenger Administration Tool or by user updates. The contact information can be imported using the Webex Messenger Administration Tool. For more information see the User Management section of the Webex Messenger Administration Guide.

Cisco Jabber supports the following formats for contact photos in your directory:

• JPG

• PNG

• BMP

Important

Cisco Jabber 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, use PNG format for your contact photos.

Tip	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.

• Resizing—If contact photos in your directory are smaller or larger than 128 pixels by 128 pixels, the client automatically resizes the photos. For example, contact photos in your directory are 64 pixels by 64 pixels. When Cisco Jabber retrieves the contact photos from your directory, it resizes the photos to 128 pixels by 128 pixels.

  Tip	Resizing contact photos can result in less than optimal resolution. For this reason, use contact photos that are 128 pixels by 128 pixels so that the client does not automatically resize them.

• Cropping—Cisco Jabber automatically crops nonsquare 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, the client 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 needs to crop 100 pixels from the height to achieve an aspect ratio of 1:1. In this case, the client 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, the client 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 needs to crop 100 pixels from the width to achieve an aspect ratio of 1:1. In this case, the client crops 50 pixels from the right side of the photos and 50 pixels from the left side of the photos.