CCNA Collaboration CICD 210-060 Official Cert Guide: Managing Endpoints and End Users in CUCM

Date: Nov 9, 2015

Return to the article

This chapter from CCNA Collaboration CICD 210-060 Official Cert Guide reviews the configuration of endpoints and users in Cisco Unified Communications Manager (CUCM), including setting up basic network services, registering phones, configuration, and bulk administration.

This chapter covers the following topics:

IP phones and end users are important parts of a Unified Communications deployment; after all, without phones or people to use them, what is the point of having the system? This chapter reviews the configuration of endpoints and users in Cisco Unified Communications Manager (CUCM), including setting up basic network services, registering phones, configuration, and bulk administration.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 9-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers Appendix.”

Table 9-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions Covered in This Section

Implementing IP Phones in CUCM

1-6

Describe End Users in CUCM

7

Implementing End Users in CUCM

8-10

  1. Which of the following protocols is critical for IP phone operation?

    1. DNS
    2. DHCP
    3. NTP
    4. TFTP

  2. What file does an IP phone first request from TFTP during its startup and registration process?

    1. SEP<mac_address>.cnf.xml
    2. None. The phone receives all information via SCCP signaling.
    3. SEP<mac_address>.xml
    4. XMLDefault.cnf.xml

  3. Which of the following statements is true?

    1. SCCP phone configuration files contain all settings, including date/time and softkey assignments.
    2. SIP phone configuration files are larger than SCCP phone configuration files.
    3. SCCP phone configuration files are exactly the same as SIP phone configuration files.
    4. SIP phone configuration files are much smaller than SCCP configurations files because of the limited feature set of SIP phones.

  4. Which of the following is true of DHCP in CUCM?

    1. The DHCP server capability is no longer available as of CUCM v8.x.
    2. The DHCP service is a basic capability intended for supporting up to 1000 IP phones.
    3. DHCP is mandatory for IP phones.
    4. CUCM supports a proprietary IP address assignment protocol called LLDP.

  5. Which of the following is not a device pool setting?

    1. Cisco Unified Communications Manager Group
    2. Local Route Group
    3. Region
    4. Common Phone Profile

  6. Bob asks you to provide a third DN button and a BLF speed dial for the Auto Parts desk’s 12 7965 IP phones. Which of the following is the best choice?

    1. Modify the standard user softkey template.
    2. Copy the standard user softkey template, name it PartsDesk, and add the requested features.
    3. Copy the standard 7965 SCCP Phone Button template, name it PartsDesk, and add the requested features.
    4. It is not possible to add a third DN and a BLF speed dial to a 7965 IP phone.

  7. Pete recently learned that he can add his own speed dials, subscribe to phone services, and do other useful things via his Self-Care Portal web page. He comes to you complaining that he cannot do any of these things. Why can’t Pete modify his own phone?

    1. The Active Directory GPO is limiting Pete’s permissions.
    2. Pete’s account needs to be associated with his phone in the Device Associations settings in his User Configuration page.
    3. Additional licensing is required to support User Web Page functionality.
    4. Pete must be part of the CCM super users group to make these changes.

  8. Angie changes her Windows domain login password but notices that her password for her Self-Care Portal in CUCM has not changed. Which of the following is true?

    1. LDAP synchronization has not been configured.
    2. Cisco Unified Services for Windows domains has not been configured.
    3. Angie must wait 24 hours for the password to synchronize.
    4. LDAP authentication has not been configured.

  9. Which of the following is not true of LDAP synchronization in CUCM v10.x?

    1. Application user accounts must be configured in LDAP before they can be replicated to CUCM.
    2. End-user accounts that exist in CUCM and which do not exist in LDAP are maintained as local accounts in CUCM.
    3. LDAP checks the user accounts in CUCM and syncs those that also exist in LDAP.
    4. End-user accounts that exist in LDAP are synced to CUCM unless the LDAP sn attribute is blank.

  10. Which is true of LDAP synchronization agreements?

    1. The User Search Base defines the point in the tree where CUCM begins searching. CUCM can search all branches below that point.
    2. The User Search Base defines the point in the tree where CUCM begins searching. CUCM can search all branches above and below that point.
    3. The User Search Base must specify the root of the domain; LDAP Custom Filters must be used to limit the search returns.
    4. All synchronization agreements must run on a regular scheduled basis.
    5. Only one synchronization agreement can be made with a single LDAP system.

Foundation Topics

Implementing IP Phones in CUCM

The implementation of IP phones is remarkably simple, considering the myriad of services, protocols, and processes going on in the background to make the system work well. This section reviews these “hidden” processes and details some of the administrative tasks required to easily and reliably run IP phones in CUCM.

Special Functions and Services Used by IP Phones

A variety of standards-based and proprietary protocols and services support IP phones in CUCM. In no particular order, they include the following:

The next section describes each of these services, how IP phones use them, and how to configure them in CUCM (or other systems as appropriate).

NTP

NTP is an IP standard that provides network-based time synchronization. There are many good reasons to use NTP beyond the convenience and consistency of having the same time on all devices. Call detail records (CDRs) and call management records (CMRs) are time stamped, as are log files. Comparing sequential events across multiple platforms is much simpler and easier to understand if the relative time is exactly the same on all those devices. Some functions and features can also be time (calendar) based, so time synchronization is important for those functions to operate properly.

In a typical NTP implementation, a corporate router synchronizes its clock with an Internet time server (such as an atomic clock or a GPS clock). Other devices in the corporate network then sync to the router.

The CUCM Publisher is one such device; during installation, CUCM asks for the IP address of an NTP server. (Alternatively, it can use its internal clock, which is not recommended because of its inaccuracy compared to NTP.) The Subscriber servers then sync their clocks to the Publisher, and the IP phones get their time from their subscribers via Skinny Client Control Protocol (SCCP) messages. Session Initiation Protocol (SIP) phones need an NTP reference (detailed later), but in the absence of one, they can get the time from the time stamp in the SIP OK response from the Subscriber server.

CDP

CDP is a Cisco proprietary Layer 2 protocol that provides network mapping information to directly connected Cisco devices. (You learned about CDP in your CCNA studies, so we do not detail it here.) Cisco IP phones generate CDP messages and use CDP to learn the voice VLAN ID from the Cisco switch to which they are connected. The IP phone then tags the voice frames it is transmitting with that VLAN ID in the 802.1Q/P frame header.

DHCP

DHCP is a widely used IP standard that can provide the following information to IP phones:

Although it is possible to statically configure IP phones with all that information, it would be time-consuming and error-prone. DHCP is faster, easier, more scalable, and a widely accepted practice. DHCP can be provided by an existing DHCP server (because most deployments already have one), a local router, or even by CUCM itself (although this is not generally recommended for large deployments). Later sections review the configuration of DHCP services in CUCM and router IOS.

PoE

PoE is a standards-based feature that delivers DC power supply over Ethernet cabling. IP phones can use this feature, and doing so means less cabling to clutter the desk, no power supplies to buy for the phones, and potential cost savings. PoE is generally assumed to be provided by the switch that the phones connect to, but it may also be provided by a powered patch panel or inline power injector.

TFTP

TFTP is a critical service for IP phones. The phones use TFTP to download their config files, firmware, and other data. Without TFTP, the phones simply do not function properly. When you make a configuration change to a device, CUCM creates or modifies a config file for the device and uploads it to the TFTP servers. TFTP services must therefore be provided by one (or more in large deployments) of the CUCM servers in the cluster; a generic TFTP server will not have the integrated capability that a CUCM TFTP server does and will not correctly fulfill the role.

DNS

DNS provides hostname-to-IP address resolution. DNS services are not critical to IP phones. (In fact, in most deployments, it is recommended to eliminate DNS reliance from the IP phones [see Chapter 10, “Understanding CUCM Dial Plan Elements and Interactions”].) But in some circumstances, it is desirable. A DNS server must be external to the CUCM cluster; DNS is not a service that CUCM can offer.

IP Phone Registration Process

The steps that each phone goes through as it registers and becomes operational are more complex than you might think. The following section reviews these steps:

NOTE

What is in that SEP<mac_address.cnf.xml file?

The file contains a list of CUCM server, in order, that the phone should register with. It lists the TCP ports it should use for SCCP communication. It also lists the firmware version for each device model and the service URLs that each device should be using.

The CUCM server sends other configurations, such as DNs, softkeys, and speed dials, via SCCP messages in the last phase of the registration process. The configuration files for SIP phones are generally larger than the equivalent files for SCCP phones. This is because SIP phones have no equivalent mechanism for configuring items that are set by SCCP messages on SCCP phones; these items must be included in the configuration file downloaded from TFTP.

SIP Phone Registration Process

SIP phones use a different set of steps to achieve the same goal. Steps 1 to 4 are the same as SCCP phones. The following are the rest of the steps:

Preparing CUCM to Support Phones

Before we add phones, a certain amount of work should be done on the CUCM servers. Doing this setup work makes adding phones easier, more consistent, and more scalable, assuming that we follow our design plan.

The tasks we review in this section are as follows:

Service Activation

Many required services are deactivated by default on CUCM. Using the Unified Serviceability admin page, you must activate the one you need. For our purposes, we activate the Cisco CallManager, Cisco TFTP, and Cisco DHCP Monitor services. Figure 9-1 shows the Unified Serviceability Service Activation page with those services activated.

Figure 9-1 Activating Required Services

DHCP Server Configuration

CUCM includes a basic DHCP server capability. It is intended to support only IP phones, and not very many of them: only up to 1000 phones. (This is the maximum recommended due to heavy CPU load.) There is no native capability for DHCP server redundancy and only one DHCP server is supported per cluster. Multiple subnets (scopes) can be configured on the server.

If you decide that you want to use CUCM for DHCP, setting up the DHCP service is straightforward. We already activated the DHCP Monitor Service, so now we follow these basic steps:

The settings that can be configured on the Server page include the following (among others):

Any settings you configure on the server page are inherited by the subnet configuration (shown next); however, any setting you change on the subnet page overrides the Server setting. Figure 9-2 shows the DHCP Server Configuration page.

Figure 9-2 DHCP Server Configuration

Configuring DHCP subnets requires some understanding of IP subnetting and assumes that you have an IP addressing plan in place. Because these topics are covered in the CCNA prerequisite, we assume you have a grasp of these fundamentals. To configure DHCP subnets, navigate to System > DHCP > DHCP Subnet. Click Add New to create subnets; you can create multiple subnets as needed for your environment design. On the Subnet Configuration page, select the server from the DHCP Server drop-down list. You can then configure the following (some other settings are not listed):

Remember that settings in the subnet configuration override the same settings in the server configuration. Figure 9-3 shows the DHCP Subnet Configuration page.

Figure 9-3 DHCP Subnet Configuration

Configuring DHCP in Router IOS

Cisco routers support basic DHCP server functionality, and this capability is commonly used in small office environments where a dedicated DHCP server is not needed or available. Example 9-1 shows a typical DHCP configuration, with commands annotated for reference:

Example 9-1 DHCP Configuration

service dhcp
! Enables the DHCP service
!
ip dhcp excluded-address 10.1.1.1 10.1.1.10
! Specifies a start / end range of addresses that DHCP will NOT assign
ip dhcp pool name IP_PH0NES
! Creates a pool of addresses (case-sensitive name) and enters DHCP configuration mode
!
network 10.1.1.0 255.255.255.0
! Defines the subnet address for the pool
default-router address 10.1.1.1
! Defines the default gateway
dns-server address 192.168.1.10 192.168.1.11
! Identifies the DNS server IP address(es) - up to 8 IPs
!
option 150 ip 192.168.1.2
! Identifies the TFTP server IP. Multiple IPs may be included, separated by spaces.

Multiple DHCP pools can be created, so DHCP services can be provided for PCs in a small office by the same router. For some third-party SIP phones, it may be necessary to specify Option 66 (the TFTP server DNS name).

IP Phone Configuration Requirements in CUCM

CUCM has several configuration elements for IP phones. We briefly look at the following basic required elements:

Device Pool

Device pools provide a set of common configurations to a group of devices; think of a device pool as a template to apply several different settings all at once, quickly and accurately. You can create as many device pools as you need, typically one per location, but they can also be applied per function. (For example, all the phones in the call center may use a different device pool from the rest of the phones in the administration offices, although they are all at the same location.) There are several settings within the device pool; some of the ones relevant to us are as follows:

It is common to have groups of phones with similar configurations. Using a device pool for each group simplifies and speeds up administrative tasks, while making them less error-prone in the bargain. Figure 9-4 shows part of a Device Pool Configuration page.

Figure 9-4 Device Pool

Device Defaults

The Device Defaults page lists all the supported endpoints (with separate entries for SCCP and SIP as necessary), and the firmware load, device pool, and phone button template each endpoint uses by default. This allows an administrator to set useful system-wide defaults for any newly registered device of each type.

Softkey Template and Phone Button Template

The softkey template controls what softkey button functions are available to the user; these are typically used for feature access (conference, transfer, park, Extension Mobility, and so on). Seven softkey templates are available by default, and you can create as many more as your design requires.

The Phone Button template defines the behavior of the buttons to the right of the phone screen (for most models). Eighty (or more) are defined by default because there are unique templates for each supported phone type—and for most phones, a separate template for SCCP and SIP. The default templates typically provide two lines and as many speed dials as there are remaining buttons on a particular phone model; you can add and customize the templates to assign each button one of many different functions.

Profiles

Profiles allow for a one-time configuration of repetitive tasks; several types of profiles exist, and you can create many versions of each type to be applied to phones as needed.

Phone Security Profile

A default phone security profile exists for each type of phone/protocol. These default profiles have security disabled; you can choose to configure the device as secured, set encrypted TFTP configuration files, and modify Certificate Authority Proxy settings.

Common Phone Profile

The common phone profile includes settings that control the behavior of the phone, including the following:

Adding Phones in CUCM

Phones can be added to CUCM in several ways:

The following sections provide more detail on each of these operations.

Manual Configuration of IP Phones

The basic steps for manually adding an IP phone are as follows:

NOTE

There is a great deal of confusion about Restart, Reset, and Apply Config. The differences are explained in the following points:

It is common, especially if advanced features such as Extension Mobility or Cisco Unified Personal Communicator are in use, to associate a user with a particular device (IP phone). It is required to associate the user with the device if you want users to be able to use the user web pages to customize their phones. The end user is associated with the device (IP phone), and the device is associated with one or more DNs. This allows the user not only to access the user web pages to configure this phone, but for other applications and processes to interact with the user through the phone system.

So, what happens if you delete an end user who is associated with a device that is associated with a DN? Nothing. Although the association exists and is important and useful, the three database entities of user, device, and DN are independent of each other. The device and the DN do not go away if the user is deleted, and the same result applies if the device or DN are deleted (although a phone without a DN, or a DN without a phone, cannot make calls).

Auto-Registration of IP Phones

CUCM includes the auto-registration feature, which dynamically adds new phones to the database and allows them to register, including issuing each new phone a DN so that it can place and receive calls. Auto-registration is supported by all Cisco IP phones.

To enable auto-registration, perform the following steps:

A simple way to test auto-registration is to plug in a new phone; if it receives a DN in the range you specified (or a DN in the range of 1000 to 1999 if you left it at the defaults), auto-registration is working.

Some administrators see auto-registration as a security weakness because any IP phone will be dynamically added to the database and potentially begin making calls, perhaps even to the PSTN if it is not restricted. It is common to enable auto-registration only when it is needed to prevent the registration of “rogue phones.”

Figure 9-6 shows the Auto-Registration Information section of the Unified CM Configuration page.

Figure 9-6 Auto-Registration Configuration

NOTE

UDTs and ULTs were introduced in CUCM v9.0 as a way to simplify and accelerate the administrative process of adding new phones and users. In essence, they are simply ordinary templates that you create (as many as you need) and set up with common settings for each of the different groups of phones you identify. What makes universal templates interesting is that they utilize variables so that as you create a phone, the UDT/ULT can be set up to create a description as “User’s first name followed by user’s last name,” for example, and have the actual names inserted when the associated user is identified. The other cool part of the universal templates is the interface, which is modern and interactive.

Figure 9-7 shows a UDT under construction. In the UDT configuration screen, clicking the little pencil icon next to the Device Description field opens the Build Input for Device Description dialog box shown in the callout bubble. In this dialog, clicking the various icons labeled with First Name, Last Name, and so forth builds a string of variables (for example, #FirstName##LastName#) as shown in the Device Description field. Those variables are replaced by the actual first and last names of the user when the phone is associated to the user during self-provisioning. You can do this any time the pencil icon is available next to a field. It is not always applicable, of course. Most of the fields do not use data for which variables are necessary; for those, simply enter or select the appropriate data.

Figure 9-7 Building a Universal Device Template

UDTs and ULTs are a cool and useful tool in the day-to-day move/add/change routine of CM administration.

Bulk Administration Tool

The Bulk Administration Tool (BAT) enables administrators to perform database inserts, modifications, or deletions in bulk. This makes it feasible to add a great many phones, users, or other elements more quickly and with fewer errors; it also allows the administrator to schedule the operation to happen automatically and unattended.

The BAT Export feature enables the administrator to pull selected records from the database and export them. The administrator can then modify the records and re-import them into the database, making bulk changes faster and more accurate.

BAT can be used to add, modify, or delete almost any component in CUCM, including phones, users, forced authorization codes and client matter codes, user device profiles, the region matrix, gateway devices, and many others.

The components of BAT include an Excel template that provides the required fields and formatting for the new unique data server-side templates that configure the common data and a set of web page interfaces for preparing and executing the many operations that BAT supports.

The Excel template is downloaded from the CUCM server. The administrator then customizes the templates for the needs of this BAT operation, populates the required fields with the correct data, and uploads the resulting CSV file to the server.

Using the BAT interface appropriate for the operation (insert phones, insert users, create call routing components, and so on), the administrator may need to create a server-side BAT Template for adding new devices, or in some cases simply select the uploaded CSV file for processing. If templates are required (as they would be if adding phones, for example), the template specifies all the settings that all the phones have in common, whereas the CSV file specifies all of the unique settings for each phone, such as DN, line text label, and so forth.

The only trick to adding phones with the BAT tool is that the MAC address of each phone must be specified. Using a barcode scanner to scan the MAC barcode label on the phone into the CSV file makes things faster and more accurate, but there is another challenge waiting for you: You create a detailed config for the phone, including DNs and other user-specific settings, and you specify the MAC address of the new phone. Now you must make sure that the physical phone with that MAC gets to the user it was built for; this is no easy task if several hundred phones are being deployed at once.

A couple of alternative strategies are available to make BAT deployments easier. One is to use auto-registration to get all the phones working and then use the BAT tool to modify the phones’ configurations after the fact. This approach still has some weaknesses, notably that you must still be positive of the MAC address of the physical phone that sits on the desk and match it to the database entry that BAT changes.

Auto Register Phone Tool

A more sophisticated (but much more complex) strategy involves the use of the Auto Register Phone Tool (formerly known as the Tool for Auto Registered Phone Support, but which is still known as TAPS because it is a better acronym than ARPT). TAPS goes one step further in the automation of new IP phone deployments, as summarized in the following steps:

This is a powerful way to deploy thousands of IP phones. With some minor tweaks and some training of the users, it requires minimal administrator involvement in the phone deployment. The downside is that it requires the IP-IVR hardware and software and a capable administrator to configure it and still involves either training users to set up their own phones or using administrators to perform repetitive simple tasks, which are not cost-effective uses of their time.

Self-Provisioning

Self-provisioning is conceptually almost exactly the same as TAPS, with the very significant difference being that all of the IVR capability has been integrated into the CUCM application. This means that we no longer need to go to the trouble and expense of building and configuring an external IVR; we just configure CM to do it for us. Self-provisioning utilizes UDTs and ULTs, giving us even better customization with much less effort because we can leverage the variables definitions in the UDT and ULT.

Describe End Users in CUCM

It is technically true that a phone system does not need end users. If a person sits in front of a phone and starts using it, it does not really matter who the person is as long as the phone does what that person needs it to do. But a Unified Communications system provides much more than just phone functionality; it has a massive array of features that can be provided to and customized by individual users. Converged networks are increasingly complex, and end users expect an increasing simplicity of use. The configuration of end users is an integral part of a full-featured system, or as one of my friends put it: “All the fun stuff needs user accounts.”

End Users Versus Application Users

CUCM makes a clear distinction between end users and application users. The distinction is simple: End Users are typically people who type a username and password into a login screen (usually a web page) to access features or controls. An application user is typically an application that sends authentication information inline with a request to read or write information to a system (perhaps a third-party billing application accessing the CDR/CAR database, for example). Table 9-2 lists some of the characteristics and limitations of end users versus application users.

Table 9-2 End Users Versus Application Users

End Users

Application Users

Associated with an actual person

Associated with an application

For individual use in interactive logins

For noninteractive logins

Used to assign user features and administrative rights

Used for application authorization

Included in the user directory

Not included in the user directory

Can be provisioned and authenticated using Lightweight Directory Access Protocol (LDAP)

Must be provisioned locally (no LDAP)

Credential Policy

The credential policy defines preset passwords, end-user PINs, and application-user passwords. The default credential policy applies the application password specified at install to all application users.

Administrators can define additional policies that can specify the allowed number of failed login attempts, minimum password length, minimum time between password changes, number of previous passwords stored, and the lifetime of the password. The policy can also check for weak passwords. A strong password

Similar rules exist for phone PINs:

Features Interacting with User Accounts

The following features use the end-user account login process, with either the username/password or PIN as the authentication:

User account information is divided into three categories, with fields for specific data in each category:

  1. Personal and Organizational Settings:

    • UserID
    • First, Middle, Last Name
    • Manager UserID
    • Department
    • Phone Number, Mail ID
  2. Password Information: Password

  3. CUCM Configuration Settings:

    • PIN
    • SIP Digest Credentials
    • User Groups and Roles
    • Associated PCs, controlled devices, and DNs
    • Application and feature parameters (Extension Mobility, Presence Group, CAPF)

Application user accounts use a subset of the previous attributes.

User Locale

User locales allow different languages to be displayed on the IP phone and the user web pages. Additional locales are installed on the CUCM server; then specific locale files are downloaded to the phone via TFTP. This allows for the customization of the primary interfaces for users in a wide range of available locales/languages.

Device Association

For users to be able to control their own devices (using the Self-Care Portal to up their own speed dials, services, and ring preferences, for example), the end-user account must be associated with the device. In CUCM, end users can be associated with IP phones, Cisco IP Communicator (CIPC), and Cisco Extension Mobility profiles.

Because the end-user account must have a unique user attribute name in the CUCM database, it is possible to dial a user by name. Cisco Unified Presence Server (CUPS) tracks the availability status of a user and his communication capabilities (such as voice, video, and chat).

Implementing End Users in CUCM

End users can be added to the CUCM database via three main methods:

This section reviews each of these methods.

Manual Entry

The CUCM database includes fields for comprehensive user information. Only some of these fields are required, including the following:

Given that the last two required fields are populated by default, it is clear that CUCM does not require much information to create a new user. The user ID must be unique, which implies that you should have a naming convention that accommodates many users with similar names.

There are many optional fields on the End User Configuration page, including Password, PIN, First Name, Telephone Number, and Device Association. The more users you have, the more likely it is that these optional fields will be populated to implement features, improve searching and reporting, or improve security. Figure 9-8 shows part of the End User Configuration page.

Figure 9-8 End User Configuration Page

Bulk Import Using BAT

Instead of adding potentially hundreds or thousands of users one at a time, the administrator can add users in bulk using the Bulk Administration Tool. BAT allows the administrator to create and upload a CSV file with all the users’ information populated and insert the data into the database in an automated way. BAT is a fast way to add, remove, or modify database entries for many fields in the CUCM database.

LDAP Integration

CUCM supports integration with Lightweight Directory Access Protocol (LDAP). LDAP is a standards-based system that allows an organization to create a single, centralized directory information store. LDAP holds information about user accounts, passwords, and user privileges. The information centralized in LDAP is available to other applications, so that separate directories do not need to be maintained for each application. Using LDAP simplifies user administration, and makes using systems slightly easier for users because they only need to maintain their information and passwords in one place.

NOTE

Only end users are replicated by LDAP sync. Application users are always and only maintained as local entries in the CUCM database.

CUCM supports LDAP integration with several widely used LDAP systems, including the following:

CUCM can interact with LDAP in two ways: LDAP Synchronization populates the CUCM database with user attributes from LDAP, and (as an optional additional configuration) LDAP authentication redirects password authentication to the LDAP system. Typically, synchronization and authentication are enabled together. In either case, some information that now comes from LDAP is no longer configurable in CUCM; the fields actually become read-only in CUCM, because the information can only be edited in LDAP. The following sections review LDAP synchronization and authentication in more detail.

LDAP Synchronization

Implementing LDAP synchronization (LDAP sync) means that some user data (but not all) for LDAP-sourced end user accounts is maintained in LDAP and replicated to the CUCM database. When LDAP sync is enabled, LDAP-sourced user accounts must be created and maintained in LDAP and cannot be created or deleted in CUCM; the user attributes that LDAP holds become read-only in CUCM. However, some user attributes are not held in LDAP and are still configured in CUCM because those attributes exist only in the CUCM database. As of CUCM v9.x, local CUCM user accounts can coexist with LDAP-sourced accounts; in this case, CUCM maintains read-write access to all the attributes of local accounts, but LDAP-sourced accounts still have attributes that are read-only in CUCM and which must be managed in the LDAP system.

It is important to understand that when using LDAP sync without LDAP authentication, the user passwords are still managed in the CUCM database. This means that, although a user account in LDAP is replicated to the CUCM database, the user password must be maintained separately in both the LDAP system and in CUCM.

CUCM uses the DirSync service to perform LDAP sync. The synchronization can be configured to run just once, on demand, or on a regular schedule. The choice depends on the system environment and the frequency of changes to LDAP content; the need for up-to-date information must be balanced against the load on the servers and network if the sync is frequent or takes place during busy times.

NOTE

If LDAP authentication is enabled and LDAP fails or is inaccessible, only local end-user accounts will be able to log in to the CUCM (in addition to any application user accounts including the primary Administrator account defined at install). This may cause drastic unified communications service interruption, depending on how users normally interact with the system. Of course, if LDAP has failed, it is likely to be a serious issue already, causing many applications to cease functioning.

LDAP Authentication

LDAP authentication redirects password authentication requests from CUCM to the LDAP system. End-user account passwords are maintained in the LDAP system and are not configured, stored, or replicated to CUCM. Because one of the benefits (particularly to the end user) of LDAP is a centralized password system (making single sign-on possible), it is typical and desirable to implement LDAP authentication with LDAP sync.

LDAP Integration Considerations

A common misconception regarding CUCM LDAP integration is that all user data resides in LDAP. This is absolutely false. With LDAP sync, certain LDAP user attributes are held in the LDAP directory and are replicated to the CUCM database as read-only attributes. The balance of the user attributes in the CUCM database (fields such as associated devices, PINs, Extension Mobility profile, and so on) are still held and managed only in the CUCM database.

There is a similar misconception with LDAP authentication: Remember that the LDAP password is not replicated to the CUCM database; rather, the authentication process is redirected to the LDAP system. When an LDAP authentication-enabled user logs in to CUCM, the username and password are sent to the LDAP system (the password in sent as an MD5 hash). The LDAP system compares the submitted hash with its own hash of the correct password, and if they match, then the LDAP system indicates to the CUCM that the user is successfully authenticated (and, obviously, if the hashes do not match, the authentication fails).

The interaction of CUCM with LDAP varies with the type of LDAP implementation. The primary concern is how much data is replicated with each synchronization event. For example, Microsoft Active Directory performs a full sync of all records contained in the configuration every time; this can mean a very large amount of data is being synchronized, potentially causing network congestion and server performance issues. For this reason, sync intervals and scheduling should be carefully considered to minimize the performance impact.

Synchronization with all other supported LDAP systems is incremental (for example, only the new or changed information is replicated), which typically greatly reduces the amount of data being replicated, thereby reducing the impact on the network and servers.

LDAP Attribute Mapping

The user attribute field names that LDAP uses are most likely different from the equivalent attribute field names in the CUCM database. Therefore, the various LDAP attributes must be mapped to the appropriate CUCM database attribute. Creating an LDAP sync agreement involves identifying the one LDAP user attribute that will map to the CUCM user ID attribute. In a Microsoft Active Directory integration, for example, the LDAP attribute that will become the CUCM user ID can be any one of the following:

It does not matter which one is chosen, but for consistency and ease of use, the attribute that the users are already using to log in to other applications should be used.

After the initial user ID mapping is selected, some other LDAP attributes should be manually mapped to CUCM database fields. Table 9-3 lists the fields in the CUCM database that map to the possible equivalent attribute in each type of supported LDAP database.

Table 9-3 LDAP User Attribute Mapping

CUCM

Microsoft AD

Other Supported LDAP

User ID

sAMAccountName

uld

mail

mail

employeeNumber

employeeNumber

telephoneNumber

telephonePhone

UserPrincipalName

First Name

givenName

Givenname

Middle Name

middleName

initials

Initials

Last Name

sn

sn

Manager ID

manager

manager

Department

department

department

Phone Number

telephoneNumber

telephonenumber

ipPhone

Mail ID

mail

mail

sAMAccountName

uld

LDAP Sync Requirements and Behavior

Keep these points in mind when planning and implementing an LDAP sync:

LDAP Sync Agreements

An LDAP sync agreement defines what part of the LDAP directory will be searched for user accounts. Many LDAP systems have a highly organized structure, with different containers for different functions, departments, locations, or privileges. The synchronization agreement specifies at which point in the tree the search for user accounts will begin. CUCM has access to the container specified in the agreement, and all levels below that in the tree; it cannot search higher up the tree than the start point, nor can it search across to other branches in the tree that must be accessed by going higher than the starting point then back down.

The agreement can specify the root of the domain, but although this is a simple agreement to create, it causes the entire LDAP structure to be searched, which may return unwanted accounts or simply too many accounts.

CUCM can integrate with only one LDAP system, but within that system version 10.x can support up to 20 synchronization agreements. The total number of LDAP-sourced user accounts should not exceed 160,000. To be more precise

LDAP Sync Mechanism

The LDAP sync agreement specifies when to begin synchronizing and when to repeat the synchronization (a schedule). It is possible to have a synchronization run only once, although this is somewhat unusual.

LDAP Custom Filters

The default behavior of LDAP sync is to import all user accounts from the start point in the tree on down. This may cause accounts to be imported that are not wanted. Using a custom filter allows an administrator to limit which accounts are imported; for example, a filter could specify that only user accounts in a particular organizational unit (OU) are imported. If the filter is changed, a full LDAP sync must be performed for the change to take effect.

Configure LDAP Sync

Setting up LDAP sync is surprisingly simple. The main difficulty is typically gaining a full understanding of the target LDAP structure, knowing what containers hold the users to be imported, and knowing where to start the LDAP search.

The basics steps to set up LDAP sync are as follows:

For CUCM to be able to access and search LDAP, an account must be created in LDAP for CUCM. Configurations may vary between LDAP systems, but the account must essentially have read permissions on everything in the search base.

Activate DirSync

Using the Unified Serviceability application, navigate to Tools > Service Activation. From the Server drop-down list, choose the Publisher. Find the Cisco DirSync service, check the box next to it, and click Save.

Configure the LDAP System

Follow these steps to enable LDAP sync in CUCM:

Figure 9-9 shows the LDAP System Configuration page.

Figure 9-9 LDAP System Configuration

Configure the LDAP Directory

To configure the LDAP directory, follow these steps:

NOTE

There are several new and interesting capabilities in the LDAP integration system that are beyond the scope for CICD. Things such as the ability to add users to specified groups as you import them and to associate or even create directory numbers based on the LDAP information or specified settings, are good news for ease of user administration, but not CICD exam material.

Figure 9-10 shows the LDAP Directory configuration page.

Figure 9-10 LDAP Directory Configuration Page

Verify LDAP Sync

The simplest way to verify that LDAP sync is working is to do a quick search of the end users on the CUCM. In the column under LDAP Sync Status, the LDAP-sourced users’ status will be listed as Active LDAP Synchronized User. Users that are locally maintained in the CUCM database will be listed as Enabled Local User.

When you open the configuration page for an LDAP-synced user, you see that the User ID, Last Name, Middle Name, First Name, Telephone Number, Mail ID, Manager User ID, Department and a few other fields are not editable; this is because they are synced with LDAP and can only be edited in the LDAP system.

Configuring LDAP Authentication

Configuring CUCM to redirect authentication to the LDAP system is normally done as part of an LDAP integration. It is not typical to sync all the users but still make them maintain a separate password in CUCM.

To set up LDAP authentication, follow these steps:

Verify LDAP Authentication

Verifying LDAP authentication can be achieved by opening a user configuration page and observing that the Password field is gone; this is because the password is maintained in LDAP, not locally in the CUCM database. A user can test the LDAP authentication by changing her password in LDAP and observing that CUCM requires the new password to log in.

Note that the user PIN is always locally maintained in the CUCM database, as are all the other CUCM-specific attributes.

Create LDAP Custom Filters

Create LDAP custom filters by navigating to System > LDAP > LDAP Custom Filter. Click Add New. In the Filter Configuration page, specify a name for the filter.

In the Filter field, type the filter statement. The statement must be in parentheses: ( ). Some sample filter statements follow; for more detail, see RFC 4515, LDAP: String Representation of Search Filters:

Exam Preparation Tasks

Review All the Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 9-4 describes these key topics and identifies the page number on which each is found.

Table 9-4 Key Topics for Chapter 9

Key Topic Element

Description

Page Number

Section

IP phone registration process

236

Section

IP phone configuration requirements in CUCM

240

Section

End users versus application users

252

Section

LDAP integration

256

Definitions of Key Terms

Define the following key terms from this chapter, and check your answers in the Glossary:

© 2024 Pearson Education, Pearson IT Certification. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240

sale-70-410-exam    | Exam-200-125-pdf    | we-sale-70-410-exam    | hot-sale-70-410-exam    | Latest-exam-700-603-Dumps    | Dumps-98-363-exams-date    | Certs-200-125-date    | Dumps-300-075-exams-date    | hot-sale-book-C8010-726-book    | Hot-Sale-200-310-Exam    | Exam-Description-200-310-dumps?    | hot-sale-book-200-125-book    | Latest-Updated-300-209-Exam    | Dumps-210-260-exams-date    | Download-200-125-Exam-PDF    | Exam-Description-300-101-dumps    | Certs-300-101-date    | Hot-Sale-300-075-Exam    | Latest-exam-200-125-Dumps    | Exam-Description-200-125-dumps    | Latest-Updated-300-075-Exam    | hot-sale-book-210-260-book    | Dumps-200-901-exams-date    | Certs-200-901-date    | Latest-exam-1Z0-062-Dumps    | Hot-Sale-1Z0-062-Exam    | Certs-CSSLP-date    | 100%-Pass-70-383-Exams    | Latest-JN0-360-real-exam-questions    | 100%-Pass-4A0-100-Real-Exam-Questions    | Dumps-300-135-exams-date    | Passed-200-105-Tech-Exams    | Latest-Updated-200-310-Exam    | Download-300-070-Exam-PDF    | Hot-Sale-JN0-360-Exam    | 100%-Pass-JN0-360-Exams    | 100%-Pass-JN0-360-Real-Exam-Questions    | Dumps-JN0-360-exams-date    | Exam-Description-1Z0-876-dumps    | Latest-exam-1Z0-876-Dumps    | Dumps-HPE0-Y53-exams-date    | 2017-Latest-HPE0-Y53-Exam    | 100%-Pass-HPE0-Y53-Real-Exam-Questions    | Pass-4A0-100-Exam    | Latest-4A0-100-Questions    | Dumps-98-365-exams-date    | 2017-Latest-98-365-Exam    | 100%-Pass-VCS-254-Exams    | 2017-Latest-VCS-273-Exam    | Dumps-200-355-exams-date    | 2017-Latest-300-320-Exam    | Pass-300-101-Exam    | 100%-Pass-300-115-Exams    |
http://www.portvapes.co.uk/    | http://www.portvapes.co.uk/    |