Cisco Unified CallManager System Guide, Release 4.2(3)
Understanding the Directory
Downloads: This chapterpdf (PDF - 270.0KB) The complete bookPDF (PDF - 5.08MB) | Feedback

Understanding the Directory

Table Of Contents

Understanding the Directory

Cisco Unified CallManager Embedded LDAP Directory

Directory Access Versus Directory Integration

Directory Access for Cisco Unified Communications Endpoints

Directory Integration with Cisco Unified CallManager

Cisco Customer Directory Configuration Plugin

Adding Cisco Unified 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 Unified CallManager embedded directory and covers the main principles for integrating Cisco Unified CallManager with a corporate LDAP directory. It also summarizes considerations for providing Cisco Unified Communications endpoints, such as Cisco Unified IP Phones and Cisco IP SoftPhone, with access to a corporate LDAP directory.

This chapter includes the following topics:

Cisco Unified CallManager Embedded LDAP Directory

Directory Access Versus Directory Integration

Directory Access for Cisco Unified Communications Endpoints

Directory Integration with Cisco Unified CallManager

Where to Find More Information

The considerations that this chapter presents apply to Cisco Unified CallManager as well as the following applications that are bundled with it: Cisco Extension Mobility, Cisco Unified CallManager 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 Unified CallManager Embedded LDAP Directory

Cisco Unified 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 Unified 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 Unified 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 Unified 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 Unified 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 Unified 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 Unified CallManager Customer Directory Plugin 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 Unified 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 Unified 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 Unified 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 Extension Mobility

Multilevel Administration (MLA)

Cisco Unified CallManager User Options

Cisco Conference Connection

CTIManager

CDR Analysis and Reporting (CAR)

Cisco Unified CallManager Assistant

Cisco Customer Response Solutions (CRS)

Personal Assistant

Cisco Emergency Responder (CER)

Cisco Unified IP Phone Services

Personal Address Book (PAB)

FastDials

Cisco WebDialer

Cisco IP SoftPhone

Cisco IP Communicator

Cisco Unified 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 Unified 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 Unified 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 Unified CallManager gets integrated. The client (for example, Cisco Unified 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 Unified CallManager Applications That Support LDAPS 

Secure Directory Application (LDAPS)
Unsecure Directory Application

Cisco Unified CallManager Administration

Cisco Customer Response Solutions (CRS)

Multilevel Administration

Personal Assistant

Cisco Unified CallManager User Options

Cisco Emergency Responder

Cisco Extension Mobility

Cisco Unified IP Phone Services

Cisco Conference Connection

Personal Address Book

CTIManager

FastDials

CDR Analysis and Reporting

Directory Integration API

Cisco Unified CallManager Assistant

Cisco WebDialer

Bulk Administration Tool

Cisco IP SoftPhone

 

Cisco Unified CallManager Attendant Console

 

Cisco IP Communicator


When Cisco Unified 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 Unified 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 Unified CallManager" section.

Refer to the Installing the Cisco Unified CallManager Customer Directory Plugin 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 Unified Communications endpoints, such as Cisco Unified IP Phones and Cisco IP SoftPhone, to access a corporate LDAP directory.

Directory integration refers to the ability of an application, such as Cisco Unified 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 Unified Communications Endpoints

Figure 17-1 illustrates directory access as this chapter defines it. In this example, a Cisco Unified 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 Unified 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 Unified Communications 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 Unified CallManager stores user information (such as user controls, personal address book entries, and so on) in an embedded LDAP directory. However, Cisco Unified 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 Unified 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 Unified 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 Unified Communications Endpoints

The guidelines that this section contains apply regardless of whether Cisco Unified CallManager or other Cisco Unified Communications 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 Unified 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 Unified IP Phones

XML-capable Cisco Unified 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 Unified CallManager has not been integrated with the corporate directory. In this scenario, the message exchange does not involve Cisco Unified CallManager.

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

You can configure the proxy function that the web server provided by using the Cisco Unified 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 Unified IP Phones includes the following characteristics:

The system supports all LDAPv3-compliant directories.

Cisco Unified 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 Unified CallManager User Options window.

Directory Integration with Cisco Unified CallManager

Cisco Unified 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 Unified 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 Unified 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 Unified 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 Unified 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 Unified 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 Unified CallManager Assistant 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 Unified CallManager uses belongs to the auxiliary class called ciscoCCNocAppProfile, and it is where Cisco Unified 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 Unified CallManager creates both of these profile objects under the "Cisco" subtree.


Note Cisco Unified 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 Unified CallManager.


Cisco Customer Directory Configuration Plugin

To integrate Cisco Unified CallManager with an external LDAP directory, run the Cisco Customer Directory Configuration Plugin, which is bundled with Cisco Unified 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 Unified CallManager needs.

It configures Cisco Unified 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 Unified CallManager performs the schema update. However, starting with Cisco Unified 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 Unified CallManager is not local to the Schema Master server.

After the plug-in has been run, Cisco Unified CallManager effectively uses the corporate directory to store user preferences. If the Cisco Unified Communications 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 Unified IP Phone Corporate Directory Access When Cisco Unified CallManager Is Integrated with the Corporate Directory

Adding Cisco Unified CallManager Servers to a Domain

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

Adding Cisco Unified 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 Unified CallManager server itself.

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

Cisco recommends that you keep Cisco Unified 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 Unified CallManager Groups

System Configuration Checklist

Additional Cisco Documentation

Installing the Cisco Unified CallManager Customer Directory Plugin

Installing Cisco Unified CallManager Release 4.2(3)

Cisco Unified Communications Solution Reference Network Design