Table Of Contents

Understanding the Directory

Cisco CallManager Embedded LDAP Directory

Directory Access Versus Directory Integration

Directory Access for Cisco IP Telephony Endpoints

Directory Integration with Cisco CallManager

Cisco Customer Directory Configuration Plugin

Adding Cisco CallManager Servers to a Domain

Where to Find More Information

Understanding the Directory

---

Directories comprise specialized databases that are optimized for a high number of reads and searches and occasional writes and updates. Directories typically store data that does not change often, such as employee information, user privileges on the corporate network, and so on.

Because directories are extensible, you can modify and extend the type of information that is stored in them. The term directory schema refers to the type of stored information and the rules it obeys. Many directories provide methods for extending the directory schema to accommodate information types that different applications define. This capability enables enterprises to use the directory as a central repository for user information.

The Lightweight Directory Access Protocol (LDAP) provides applications with a standard method for accessing and potentially modifying the information that is stored in the directory. This capability enables companies to centralize all user information in a single repository, available to several applications, with a reduction in maintenance costs through the ease of adds, moves, and changes.

This chapter provides a brief overview of the Cisco CallManager embedded directory and covers the main principles for integrating Cisco CallManager with a corporate LDAP directory. It also summarizes considerations for providing Cisco IP Telephony endpoints, such as Cisco IP Phones and Cisco IP SoftPhone, with access to a corporate LDAP directory.

This chapter includes the following topics:

•Cisco CallManager Embedded LDAP Directory

•Directory Access Versus Directory Integration

•Directory Access for Cisco IP Telephony Endpoints

•Directory Integration with Cisco CallManager

•Where to Find More Information

The considerations that this chapter presents apply to Cisco CallManager as well as the following applications that are bundled with it: Cisco CallManager Extension Mobility, Cisco IP Manager Assistant, Cisco WebDialer, Bulk Administration Tool, Real-Time Monitoring Tool, and MultiLevel Administration (MLA).

For all other Cisco voice applications, refer to the respective product documentation that is available at

http://www.cisco.com

In particular, for Cisco Unity, refer to the Cisco Unity Design Guide and to the following white papers: Cisco Unity Data and the Directory, Active Directory Capacity Planning, and Cisco Unity Data Architecture and How Cisco Unity Works.

Cisco CallManager Embedded LDAP Directory

Cisco CallManager uses the Data Connection Directory (DC-Directory) as an embedded LDAP directory. This directory stores authentication and authorization information about users and comes standard with Cisco CallManager (that is, it does not require any special configuration or installation). Authentication establishes the user right to access the system, while authorization identifies the telephony resources that a user is permitted to use, such as a specific telephone extension.

After installation, the Cisco CallManager publisher server contains the read and write version of the LDAP directory and the database, while the subscriber servers contain read-only versions. The system uses LDAP to communicate to and from Cisco CallManager and all the supported applications and uses the TCP port 8404. When security is enabled, LDAPS (LDAP over SSL) uses TCP port 8405 (see the "LDAP and the Secured Sockets Layer" section for more information).

Administrators access the embedded LDAP directory from the Cisco CallManager Administration User Configuration window. Administrators use the User Configuration window to add, update, and delete user information such as userid, password, and device association.

---

Note DC Directory does not support password management features such as periodic password expiration or enforced password length and complexity rules. To enable password management features, you must integrate Cisco CallManager with an enterprise directory that can provide these features. For more information on password management features and the enterprise directories that support them, see the Installing the Cisco Customer Directory Configuration Plugin for Cisco CallManager Release 4.2 (1) publication.

---

---

Caution If you have an integrated enterprise directory (as opposed to the embedded DC-Directory), you may be able to configure password management features such as periodic password expiration. To prevent disruption of critical access to the system, never configure a password expiration time for the following system users: CCMAdministrator, CCMSysUser, IPMASysUser, and any other system user that any Cisco CallManager application creates and uses. You must set passwords for these users to never expire.

---

---

Caution Using Katakana, Cyrillic, or other double-byte character sets with DC Directory, Netscape Directory, or Active Directory can cause directory database errors. This release of Cisco CallManager does not support using any double-byte character set with any directory.

---

Applications and Services That Use the Embedded LDAP Directory

The following Cisco CallManager applications and services use the embedded LDAP directory for user and other types of information:

•Bulk Administration Tool (BAT)

•Tool for Auto-Registered Phone Support (TAPS)

•AXL

•Cisco CallManager Extension Mobility

•MultiLevel Administration (MLA)

•Cisco CallManager User Options

•Cisco Conference Connection

•CTIManager

•CDR Analysis and Reporting (CAR)

•Cisco IP Manager Assistant (IPMA)

•Cisco Customer Response Solutions (CRS)

•Personal Assistant

•Cisco Emergency Responder (CER)

•Cisco IP Phone Services

•Personal Address Book (PAB)

•FastDials

•Cisco WebDialer

•Cisco IP SoftPhone

•Cisco IP Communicator

•Cisco CallManager Attendant Console

See the "LDAP and the Secured Sockets Layer" section for information about security over LDAP.

LDAP and the Secured Sockets Layer

When the directory gets installed (at Cisco CallManager installation), DC-Directory v3.0.02 with Secured Sockets Layer (SSL) enabled automatically gets installed. A self-signed certificate automatically gets created and installed on DC-Directory and gets configured to use port 8405 for LDAP over SSL.

LDAP directory (LDAPS) supports SSL. The Cisco CallManager embedded directory supports SSL by default. When using a corporate LDAP directory, such as Microsoft Active Directory, the administrator can configure SSL. LDAPS capability allows you to securely pass data, including passwords and userids, to and from the directory.

SSL support implies that the security certificate that is present in the LDAP server is either the DC-Directory or the corporate directory to which Cisco CallManager gets integrated. The client (for example, Cisco CallManager Administration or BAT) does not support Certificate Based Client Authentication. When a client requests a secure connection, the server presents its certificate, and the client verifies whether the certificate itself or the certificate authority (CA) that issued the certificate is trusted. If it is trusted, the client proceeds with establishing a secure connection. If it is not trusted, the connection gets refused.

Table 17-1 provides a list of the applications and services that support LDAPS.

Table 17-1 Cisco CallManager Applications That Support LDAPS 

Secure Directory Application (LDAPS)	Unsecure Directory Application
Cisco CallManager Administration	Cisco Customer Response Solutions (CRS)
Multilevel Administration	Personal Assistant
Cisco CallManager User Options	Cisco Emergency Responder
Cisco CallManager Extension Mobility	Cisco IP Phone Services
Cisco Conference Connection	Personal Address Book
CTIManager	FastDials
CDR Analysis and Reporting	Directory Integration API
Cisco IPMA	Cisco WebDialer
Bulk Administration Tool	Cisco IP SoftPhone
	Cisco CallManager Attendant Console
	Cisco IP Communicator

When Cisco CallManager must use the corporate LDAP directory, the administrator must configure this capability by using the customer directory plug-in. The Cisco Customer Directory Plugin allows you to integrate Cisco CallManager with one of the following enterprise directories:

•Microsoft Active Directory (AD), available with Microsoft Windows 2000

•Microsoft Active Directory (AD 2003), available with Microsoft Windows 2003

•Netscape Directory Server (Version 4.x), iPlanet Directory Server (Version 5.1), and Sun ONE Directory Server (Version 5.2)

For information about this capability, see the "Directory Access Versus Directory Integration" section and the "Directory Integration with Cisco CallManager" section.

Refer to the Installing the Cisco Customer Directory Configuration Plugin for Cisco CallManager publication for integration and installation procedures.

Directory Access Versus Directory Integration

The following definitions and distinctions apply throughout this chapter:

•Directory access refers to the ability of Cisco IP Telephony endpoints, such as Cisco IP Phones and Cisco IP SoftPhone, to access a corporate LDAP directory.

•Directory integration refers to the ability of an application, such as Cisco CallManager, to store its user-related information in a centralized corporate LDAP directory instead of using its own embedded database.

Figure 17-1 Directory Access for Cisco IP Telephony Endpoints

Figure 17-1 illustrates directory access as this chapter defines it. In this example, a Cisco IP Phone gets access. The client application performs a user search against an LDAP directory, such as the corporate directory of an enterprise, and receives several matching entries. You can then select one entry and use it to dial the corresponding person from the Cisco IP Phone.

Directory access, as defined here, involves only read operations on the directory and does not require that you make any directory schema extensions or other configuration changes. In contrast, directory integration of several applications with a corporate directory means that these applications actually store their user-related information in a centralized directory instead of using their own separate, embedded databases. Figure 17-2 shows an example of directory integration as this chapter defines it.

Figure 17-2 Directory Integration for Cisco IP Telephony Applications

Directory integration involves read-and-write operations on the directory, so it requires that you make schema extensions and other configuration changes to your corporate LDAP directory. By default, Cisco CallManager stores user information (such as user controls, personal address book entries, and so on) in an embedded LDAP directory. However, Cisco CallManager can also be integrated with a corporate LDAP directory, which is normally used to store general employee information such as e-mail address, office address, and job title. In those cases, Cisco CallManager no longer uses its own embedded directory but stores its application-specific user information in the corporate directory.

---

Note Cisco CallManager Release 3.1 supports directory integration for Microsoft Active Directory (AD) 2000 and Netscape Directory Server (Version 4.x). Cisco CallManager Release 3.3(2) and subsequent releases add support for iPlanet Directory Server (Version 5.1) and Sun ONE Directory Server (Version 5.2).

---

Integrating applications such as Cisco CallManager with a corporate directory also has the following implications, which go beyond simply providing directory access to endpoints:

•Ensure the directory schema is extended to store the application-specific user attributes in the corporate directory. This not-trivial operation requires good knowledge of the directory structure.

•Ensure the applications can contact the directory at all times, and the directory can provide adequate response times. Availability of the directory service can affect application functionality.

•Additional load gets introduced on the directory in terms of both data storage and read/write queries. Cisco recommends careful planning and sizing to avoid oversubscription of the servers when any new service or application is introduced.

Although directory integration across applications provides numerous advantages, understand all its implications and verify the business needs of each specific deployment.

Directory Access for Cisco IP Telephony Endpoints

The guidelines that this section contains apply regardless of whether Cisco CallManager or other IP Telephony applications are integrated to a corporate directory. The end-user perception in both cases remains the same because the differences affect only how applications store their user information and how such information is kept consistent across the network.

The following sections summarize how to configure corporate directory access to any LDAPv3-compliant directory server for XML-capable phones such as Cisco IP Phone models 7940, 7960, and so on.

---

Note Cisco IP SoftPhone, Release 1.2 and later, includes a built-in mechanism to access and search LDAP directories, as does the Cisco IP Communicator. Refer to the product documentation for details on how to configure this feature.

---

Directory Access for Cisco IP Phones

XML-capable Cisco IP Phones (such as models 7940, 7960, and so on) can search a corporate LDAP directory when a user presses the Directories button on the phone. The IP phones use HyperText Transfer Protocol (HTTP) to send requests to a web server. The responses from the web server must contain some specific Extensible Markup Language (XML) objects that the phone can interpret and display. In the case of a corporate directory search, the web server operates as a proxy by receiving the request from the phone and translating it into an LDAP request, which is in turn sent to the corporate directory server. After being encapsulated in the appropriate XML objects, the response gets interpreted and sent back to the phone.

Figure 17-3 illustrates this mechanism in a deployment where Cisco CallManager has not been integrated with the corporate directory. In this scenario, the message exchange does not involve Cisco CallManager.

Figure 17-3 Message Exchange for Cisco IP Phone Corporate Directory Access Without Directory Integration

You can configure the proxy function that the web server provided by using the Cisco IP Phone Services Software Development Kit (SDK) version 2.0 or later, which includes the Cisco LDAP Search Component Object Model (COM) server.

In addition, directory access for Cisco IP Phones includes the following characteristics:

•The system supports all LDAPv3-compliant directories.

•Cisco CallManager user preferences (speed dials, call forward all, personal address book) do not get integrated with the corporate LDAP directory. Therefore, users must have a separate login and password to access the Cisco CallManager User Options window.

Directory Integration with Cisco CallManager

Cisco CallManager uses an embedded Microsoft SQL database to store system and device configuration data, such as dial plan information, phone and gateway configurations, and media resource utilization. It also uses an embedded LDAP directory to store user and application profiles, such as devices that a user controls, computer telephony integration (CTI) user parameters, and personal address book entries.

Both the SQL database and the LDAP directory run on every Cisco CallManager server within a cluster, and replication agreements automatically get set up between servers. The publisher server contains the master copy of both the SQL database and the LDAP directory, and it handles replication to all subscriber servers, which contain read-only copies of both repositories.

To store application-specific information in an LDAP directory, Cisco CallManager adopts an approach that is valid both when the embedded directory is used and when integration with a corporate directory occurs.

Because different directory vendors typically use different User object models with several additional, nonstandard attributes, Cisco CallManager uses only the standard LDAPv3 core attributes from the User object. The User object then gets augmented with an auxiliary class, ciscoocUser, which contains the following attributes:

•ciscoatGUID

This attribute uniquely identifies a user within the directory.

•ciscoatUserProfile

Earlier versions of Cisco CallManager and other applications use this attribute. It remains for backward compatibility.

•ciscoatUserProfileString

This attribute represents a distinguished name pointer to another object in the directory, which contains the user application-specific profile. This approach minimizes the impact on the core User object, and all the application-specific information can be stored in a separate organizational unit (OU) within the directory, usually called the Cisco subtree, CISCOBASE, or Cisco Directory Information Tree (DIT). Figure 17-4 illustrates this process.

Figure 17-4 Cisco CallManager Approach to Storing Application-Specific User Information in the Directory

The object that is pointed to by the ciscoatUserProfileString attribute belongs to a structural object class that is called ciscoocUserProfile. This object stores some specific details for the user, including the user locale, any Cisco IP Manager Assistant (IPMA) assistants for the user, and pointers to various specific profile objects for all Cisco applications that integrate with the directory. The application profile that Cisco CallManager uses belongs to the auxiliary class called ciscoCCNocAppProfile, and it is where Cisco CallManager stores the user extension mobility PIN, the list of devices that this user controls, information on whether this user is permitted to use CTI applications, and so on. Cisco CallManager creates both of these profile objects under the "Cisco" subtree.

---

Note Cisco CallManager Release 4.2 provides the basis for the examples and recommendations in this chapter. Some behaviors may differ, and some features may not be available if you are running an earlier version of Cisco CallManager.

---

Cisco Customer Directory Configuration Plugin

To integrate Cisco CallManager with an external LDAP directory, run the Cisco Customer Directory Configuration Plugin, which is bundled with Cisco CallManager (Applications > Install Plugins). This plug-in serves the following purposes:

•It extends the corporate directory schema to accommodate the application-specific objects and attributes.

•It populates the "Cisco" subtree with the configuration objects that Cisco CallManager needs.

•It configures Cisco CallManager to use the corporate directory and disables its embedded directory.

•It allows the administrator to configure LDAP over the secure sockets layer (SSL). If configured, the SSL port number and the path to the server certificate gets requested each time that data is passed to and from the directory.

Usually, running the plug-in locally on Cisco CallManager performs the schema update. However, starting with Cisco CallManager Release 4.0, an option exists to create the LDAP Data Interchange Format (LDIF) files separately, so the schema update can be performed directly on the corporate directory Schema Master server by using the LDIF files. This option allows different groups of people to perform the relevant parts of the work and reduces the need to update over the network when Cisco CallManager is not local to the Schema Master server.

After the plug-in has been run, Cisco CallManager effectively uses the corporate directory to store user preferences. If the Cisco IP telephony endpoints have also been enabled to access the corporate directory, as described in the preceding section, Figure 17-5 shows the scenario that results.

Figure 17-5 Message Exchange for Cisco IP Phone Corporate Directory Access When Cisco CallManager Is Integrated with the Corporate Directory

Adding Cisco CallManager Servers to a Domain

Adding the Cisco CallManager servers to a Microsoft Windows domain differs substantially from integrating Cisco CallManager with an external directory. Although these operations do not exclude each other, they represent completely independent operations with different implications:

•Adding Cisco CallManager servers to a Microsoft Windows Active Directory (AD) domain could cause domain policies to be applied to the Windows 2000 Server operating system, and the addition affects only the management of the Cisco CallManager server itself.

•Integrating Cisco CallManager with an external directory (such as Microsoft Active Directory or Netscape Directory Server) causes Cisco CallManager to store all its user information and preferences in that directory, but it does not affect management of the Cisco CallManager server itself.

Cisco recommends that you keep Cisco CallManager servers as workgroup servers; however, if you want to add the servers to a domain, avoid applying domain policies to the server that could interfere with its normal operation.

Where to Find More Information

Related Topics

•Cisco CallManager Groups

•System Configuration Checklist

Additional Cisco Documentation

•Installing the Cisco Customer Directory Configuration Plugin for Cisco CallManager Release 4.2 (1)

•Installing Cisco CallManager Release 4.2 (1)

•Cisco IP Telephony Reference Design Guide