-
Cisco CallManager System Guide, Release 4.1(2)
-
Index
-
Preface
-
Introduction
-
Cisco IP Telephony Overview
-
System Configuration Overview
-
Multilevel Administration Access
-
System-Level Configuration Settings
-
Clustering
-
Redundancy
-
Call Admission Control
-
Cisco TFTP
-
Device Support
-
Services
-
Auto-Registration
-
Partitions and Calling Search Spaces
-
Time-of-Day Routing
-
Understanding Route Plans
-
Application Dial Rules Overview
-
Understanding the Directory
-
Managing User Directory Information
-
Media Resource Management
-
Annunciator
-
Conference Bridges
-
Transcoders
-
Music On Hold
-
Media Termination Points
-
Cisco DSP Resources for Transcoding, Conferencing, and MTP
-
Voice Mail Connectivity to Cisco CallManager
-
SMDI Voice Mail Integration
-
Cisco Unity Messaging Integration
-
Cisco DPA Integration
-
Call Park
-
Call Pickup and Group Call Pickup
-
Cisco IP Phone Services
-
Cisco CallManager Extension Mobility and Phone Login Features
-
Cisco CallManager Attendant Console
-
Cisco IP Manager Assistant
-
Understanding Cisco CallManager Voice Gateways
-
Understanding IP Telephony Protocols
-
Understanding Session Initiation Protocol (SIP)
-
Understanding Cisco CallManager Trunk Types
-
Cisco IP Phones
-
Understanding Video Telephony
-
Computer Telephony Integration
-
Cisco ATA 186 and Cisco ATA 188
-
Administrative Tools Overview
-
Administrative Accounts and Passwords
-
Feedback
Table Of Contents
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, the type of information that is stored in them can be modified and extended. 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
•
•
•
•
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 Multi-Level Administration.
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 (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 of 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.
Caution
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:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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 has the option to configure SSL. LDAPS capability allows data, including passwords and userids, to be securely passed to and from the directory.
SSL support implies that the security certificate 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.
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:
•
•
•
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 for integration and installation procedures.
Directory Access Versus Directory Integration
The following definitions and distinctions apply throughout this chapter:
•
•
Figure 17-1 Directory Access for Cisco IP Telephony Endpoints
Figure 17-1 illustrates directory access as it is defined in this chapter. 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.
Note that 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 in 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 that the 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
Integrating applications such as Cisco CallManager with a corporate directory also has the following implications, which go beyond simply providing directory access to endpoints:
•
•
•
Although directory integration across applications has 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 have been 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 Cisco IP Phone models 7940, 7960, and so on.
Note
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:
•
•
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 are controlled by a user, 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:
•
This attribute uniquely identifies a user within the directory.
•
Earlier versions of Cisco CallManager and other applications use this attribute. It remains for backward compatibility.
•
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 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:
•
•
•
•
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:
•
•
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
•
Additional Cisco Documentation
•
•
•
