Default setting: True

The connection to the LDAP server uses SSL by default using the LDAPS protocol.

Setting this to False uses the plaintext LDAP protocol. The plaintext LDAP protocol will also be chosen if the LDAP port is either 389 or 3268 and the UseSSL configuration key is not set.

Note	The configuration key when set overrides any automatic determination of the protocol.

Default setting (all clients): True

Enable/disable the use of Ambiguous Name Resolution (ANR) when performing predictive search queries.

When set to True, Jabber constructs LDAP queries using ANR for predictive search.

If set to False, Jabber constructs a complex query for use in predictive search.

ANR is disabled if Jabber is connecting to an OpenLDAP server. It is enabled only when connecting to an Active Directory server.

The format of the query used for non-ANR servers is set using the “PredictiveSearchFilter” parameter.

Example: <UseANR>false</UseANR>

Applies to all clients.

Specifies the order for authenticating with the LDAP server.

Each of the mechanisms specified below must be supported by the Contact Service and the LDAP server.

Use a space to separate multiple authentication mechanisms.

• GSSAPI (default) —Kerberos v5. Supported by desktop clients only.

• EXTERNAL—SASL external.

• PLAIN—Simple LDAP bind (anonymous bind is a subset of simple bind). Used by default if ConnectionUsername and ConnectionPassword parameters or LDAP_UseCredentialsFrom parameter are present

Example 1: <LdapSupportedMechanisms>GSSAPI EXTERNAL PLAIN</ LdapSupportedMechanisms>

In this example, Jabber checks first if GSSAPI is supported, then attempts to authenticate. If GSSAPI is not supported, then Jabber checks if EXTERNAL is supported, then attempts to authenticate. If neither are supported, then Jabber attempts PLAIN authentication.

Example 2: <LdapSupportedMechanisms>PLAIN</LdapSupportedMechanisms>

In this example, Jabber uses PLAIN authentication only.

Applies to Cisco Jabber for Windows.

Fetches the employee number from the LDAP server when a user searches for it using Jabber.

Example: <EnableEmployeeNumber>0</EnableEmployeeNumber>

Applies to Cisco Jabber for Windows and Cisco Jabber for Android.

Specifies if the client uses LDAP referrals when attempting to resolve contacts.

Example: <UseLdapReferral>1</UseLdapReferral>

Applies to all Cisco Jabber clients for on-premises deployments.

Specifies which credentials are used by Cisco Jabber when connecting to the directory server.

• Voicemail—use voicemail credentials when connecting to the directory server.

• Exchange—use the credentials that Cisco Jabber uses to connect to Microsoft Exchange when connecting to the directory server.

• CUCM—use Cisco Unified Communications Manager credentials when connecting to the directory server.

Example: <LDAP_UseCredentialsFrom>CUCM</LDAP_UseCredentialsFrom>

When this parameter is set, users are not given the option to enter their directory credentials manually in the Options window. You can also set directory credentials using the Cisco Unified Communications Manager service profile or using the CDI directory integration parameters you defined in the jabber-config.xml file. It is not recommended to use both synchronized credentials and administrator-defined credentials.

Keep in mind that you may need to use the LdapUserDomain parameter to define the domain to authenticate against the LDAP server (where applicable). For example, the authentication ID would be <CUCM Username>@<LdapUserDomain>.

Note	Do not use the LDAP_UseCredentialsFrom parameter with any of the following parameters because they can cause conflicting configuration: LdapAnonymousBinding ConnectionUsername and ConnectionPassword UseWindowsCredentials

Applies to all Cisco Jabber clients for on-premises deployments.

Specifies the domain to be appended to the username when connecting to the LDAP server. This is useful when the LDAP server requires a UPN or email-based account to authenticate with. This parameter is used with the LDAP_UseCredentialsFrom parameter.

The username is appended with the @ symbol followed by the value specified by LdapUserDomain. This value is then used to connect to the LDAP server. For example, a user named Adam McKenzie has the user ID amckenzie and the LdapUserDomain is example.com, then the username that authenticates with the LDAP server is amckenzie@example.com.

Example: <LdapUserDomain>example.com</LdapUserDomain>

Applies to all the Cisco Jabber clients.

Restriction

Use this parameter only in jabber-config files for non-Windows environments.

Jabber uses a DNS SRV query to discover the Global Catalog by first reading the DNSFORESTNAME environment variable. If the environment variable is not present, Jabber next uses a Windows API to retrieve the DNS forest name. If you want Jabber to behave similarly on non-Windows environments, place the DNS forest name in LdapDNSForestDomain in the jabber-config file.

Specifies masks to use when users search for phone numbers.

For example, a user receives a call from +14085550100. In the directory, this number is +(1) 408 555 0100. The following mask resolves the number: +1408|+(#) ### ### ####. The length of mask strings cannot exceed the size restriction for registry subkey names.

Phone masks apply to phone numbers before the client searches your directory. If you configure phone masks correctly, directory searches succeed as exact query matches and prevents any impact on the performance of your directory server.

The following table describes the elements you can include in a phone mask:

The only value for this parameter is mask string.

Example: <PhoneNumberMasks>+1408|+(#) ### ### ####</PhoneNumberMasks>

Applies to all clients.

Prerequisites: Jabber team messaging mode is enabled.

Specifies what sources should be used for Jabber searches for environments running Jabber team messaging mode. With the search results, you'll see the person's profile picture, and be able to call them.

This parameter is ignored if you configure the ContactProfileSearch parameter with CI as the value.

• CI (default)—Jabber users can search for contacts that are in the Common Identity (CI) in the Teams directory.

• CI-UDS-LDAP—Jabber users can search for contacts from the company directory (on UDS/LDAP), as well as the CI.

  Note	If you use this value, you might need to also use DirectoryServerType.

Example: <ContactSearchSource>CI-UDS-LDAP</ContactSearchSource>

Applies to all clients.

Prerequisites: Jabber team messaging mode is enabled.

Define the source for the profiles of your users' contacts for environments running Jabber team messaging mode. With the search results, you'll see the person's profile picture, and be able to call them.

• CI —Profile information from the Common Identity (CI) in the Teams directory. If you set this value, then the ContactSearchSource parameter is ignored, and predictive search is only on CI.

• CI-UDS-LDAP (default)—Jabber will get the profile information from UDS or LDAP. The profile information from CI has higher priority over the one from UDS/LDAP if any user details have conflicts, such as their photo or display name.

  Note	If you use this value, you might need to also use DirectoryServerType.

Example: <ContactProfileSource>CI-UDS-LDAP</ContactProfileSource>

Applies to all clients.

Specifies the type of directory server you want to use for contact resolution. Jabber consults this parameter when you set ContactSearchSource or ContactProfileSource to CI-UDS-LDAP.

If you use Expressway for MRA, Jabber ignores this parameter and uses UDS.

The values used for this parameter are:

• LDAP—Connect to an LDAP server.

• UDS—Connect to UDS (Cisco Unified Communications Manager server). This value is used for all Cisco Jabber clients and is applicable for Expressway Mobile and Remote Access.

Example: <DirectoryServerType>LDAP</DirectoryServerType>

You must index attributes on your LDAP directory server for the clients. This lets clients resolve contacts.

To use the default attribute mappings, you must index the following attributes:

• sAMAccountName

• displayName

• sn

• name

• proxyAddresses

• mail

• department

• givenName

• telephoneNumber

  Additionally, you must 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

Since Cisco Jabber for Windows 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. You can choose either to replicate or not to replicate attributes to your Global Catalog server:

• If you replicate attributes to your Global Catalog server, it generates traffic between Active Directory servers in the domain. For this reason, you should replicate attributes to your Global Catalog server only if the network traffic can handle extra load.

• If you do not want to replicate attributes to a Global Catalog server, configure Cisco Jabber to connect to a Domain Controller. In this case, the client queries single domains only when it connects to a Domain Controller.

Applies to all the Cisco Jabber clients.

Specifies which attribute in User Data Service (UDS) is the email address. Configure this parameter with the value mail.

Example:

<EmailAddress>mail</EmailAddress>

Note	This parameter supports both LDAP and UDS queries in the latest Jabber versions.

Applies to all Cisco Jabber clients.

Specifies a prefix to remove from the DirectoryUri value only if the data comes from LDAP.

For example, if your directory URI is sip:amckenzie@example.com, set the following:

<DirectoryUriPrefix>sip:</DirectoryUriPrefix>

Applies to all the Cisco Jabber clients.

This parameter applies to UDS directory integrations and specifies the maximum number of words that a user’s first name can have in the predictive search. The default value for a user's first name is 2 words and there is no limit for the maximum words.

Example: <MaxWordsOfFirstName>2</MaxWordsOfFirstName>

Applies to all the Cisco Jabber clients.

This parameter applies to UDS directory integrations and specifies the maximum number of words that a user’s last name can have in the predictive search. The default value for a user's last name is 2 words and there is no limit for the maximum words.

Example: <MaxWordsOfLastName>2</MaxWordsOfLastName>

To connect to a Domain Controller, set the following parameters:

<Directory>
<ConnectionType>1</ConnectionType></Directory>

Applies to Cisco Jabber for desktop

You can add the KerberosConfiguration parameter in the jabber-config.xml file. The parameter value is written to the disk as the MIT-Kerberos configuration file.

If you don't configure this parameter, Jabber can only connect to the Active Directory domain joined by the client machine to perform a directory search. To connect to other Active Directory domains to which the client machine doesn't belong, configure domain_realm mapping.

For example, in a Multi-Forest environment, suppose you have two forests deployed in your AD infrastructure. The user accounts are in forest 1 and the resource is in forest 2. In this case, configure domain1.com as the user domain and configure domain2.com and child.domain2.com as the resource domain. You establish a trust relationship between forest 1 and forest 2.

If users sign in from domain1.com and want to access the resource domain, configure KerberosConfiguration with the appropriate values in jabber-config.xml.

Note	If the Kerberos configuration doesn’t work when typed in a single line, try typing it in multiple lines as in this example.

Example:

<Directory> 
  <KerberosConfiguration> 
    [domain_realm] 
      .domain1.com = DOMAIN1.COM 
      .child.domain1.com = CHILD.DOMAIN1.COM 
  </KerberosConfiguration> 
</Directory>

To manually connect to a directory server, set the following parameters:

<Directory>

<PrimaryServerName>primary-server-name.domain.com</PrimaryServerName>
<ServerPort1>1234</ServerPort1>
<SecondaryServerName>secondary-server-name.domain.com</SecondaryServerName>
<ServerPort2>5678</ServerPort2>
</Directory>

To integrate with UDS, set the following parameters.

Note	Configure the DirectoryServerType parameter to UDS only if you want to use UDS for all contact resolution (that is, from inside and outside the corporate firewall).

The following is an example configuration:

<Directory>
		<DirectoryServerType>UDS</DirectoryServerType>
  <UdsServer>11.22.33.444</UdsServer>
		<UdsPhotoUriWithToken>http://server-name/%%uid%%.jpg</UdsPhotoUriWithToken>
</Directory>

When you deploy Expressway for Mobile and Remote Access with an LDAP directory integration, the client uses:

• LDAP when inside the corporate firewall

• UDS when outside the corporate firewall

Note	LDAP is the default configuration, so it is not necessary to include the DirectoryServerType parameter in your client configuration file.

To ensure that the client can resolve contact photos from both inside and outside your corporate firewall, set the following parameters.

The following is an example configuration:

<Directory>
  <PhotoUriWithToken>http://photo.example.com/sAMAccountName.jpg</PhotoUriWithToken>
  <UdsPhotoUriWithToken>http://server-name/%%uid%%.jpg</UdsPhotoUriWithToken>
</Directory>

Simple authentication lets you connect to a directory server using simple binds, as in the following example configuration:

<ConnectionUsername>username</ConnectionUsername>
<ConnectionPassword> password</ConnectionPassword>