Several CUCM features require user accounts for authentication purposes. These features include an administrative web page, user web pages, and the following applications:
■ Cisco Unified Attendant Console
■ Cisco Unified Extension Mobility
■ Cisco Unified Manager Assistant (CUMA)
Cisco IP Phones can browse corporate and personal directories to find the directory number of a user. CUCM is provisioned with a user's first and last name to provide this directory-browsing functionality.
CUCM IP phone services can be configured to require a user login before providing access to the service. Users can authenticate with their username and password (alphanumeric) or PIN (numeric), depending on the needs of the application. CUCM sends authentication requests to an internal library called the Identity Management System (IMS) library, which is responsible for authenticating the user login credentials against the user database.
User Account Types
There are two types of user accounts in CUCM:
■ End users: End users are associated with an individual and have an interactive login. End users can have administrative roles based on the user group role configuration.
■ Application users: Application users are associated with applications such as Cisco Unified Attendant Console, Cisco Unified Contact Center Express (UCCX), or Cisco Unified Manager Assistant. The mentioned applications need to authenticate with CUCM, but application users do not have the ability to interactively log in. Application users are leveraged for internal process-level communications between applications.
Table 6-1 summarizes the differences between end users and application users.
Associated with an individual
Associated with an application
Provide interactive logins
Provide noninteractive logins
User feature and system administration authorization
Included in phone directory
Not included in phone directory
Can be provisioned and authenticated using an external LDAPv3 directory server
Cannot use LDAPv3
The attributes associated with end users are separated into three categories, as follows:
The attributes associated with end users are separated into three categories, as follows:
■ Personal and organizational settings:
— User ID, first, middle, and last name —Manager user ID, department —Phone number, mail ID
■ CUCM administration settings:
—PIN, SIP digest credentials —User privileges (user groups and roles) —Associated PCs, controlled devices, and directory numbers —Application and feature parameters
CUCM allows for the assignment of user privileges to application users and end users. Privileges that can be assigned to users include the following:
■ Access to administration and user web pages
■ Access to specific administrative functions
■ Access to application interfaces such as Computer Telephony Integration (CTI) and Simple Object Access Protocol (SOAP)
User privileges are configured using two configuration entities:
■ User groups: A collection of application users and end users with similar privilege levels
■ Roles: Resources for an application
Each role refers to exactly one application, and each application has one or more resources. Access privileges are configured per application resource in the role configuration. Roles are assigned to user groups.
Figure 6-1 illustrates the access that four users have to two different applications. The needs of the four users are achieved through the assignment of two user groups.
User1 and User2 are assigned to Group1, which has two roles assigned to it for Application1. The privilege levels of Role1 and Role2 refer to the same application but provide different levels of access (privileges) to the resource. The overlapping configuration can be configured to give the highest or lowest overlapping privilege level.
User3 is assigned to both Groupl and Group2. Groupl and Group2 have role assignments of 1, 2, and 3. Rolel and Role2 both control different privilege levels to Applicationl and Application2. It is best to avoid overlapping role privileges (Rolel and Role2) when possible.
User4 is assigned to Group2, which has privilege levels to Applicationl and Application2, controlled through Role2 and Role3. User4 does not have overlapping privilege challenges.
Figure 6-1 User Privilege Component Interaction Users n : n Users Groups n : n Roles 1 : 1
Applications 1 : 1 Privileges
The goal of the configuration illustrated in Figure 6-2 is to create administrative groups that have read, write, and update access to the Communications Manager configuration web pages (CCMAdmin), and junior-level administrators who have read-only privileges to the CCMAdmin configuration web pages. The following text relates to the example illustrated in Figure 6-2.
CUCM has various Administration web pages associated with functions, such as the Call Park web pages (used to the configure call park feature), the AAR Group web pages (used to configure automated alternate routing), the CallManager group web pages (for CUCM configuration), and the DRF Show Status page (used to check the status of Disaster Recovery System backup or restore jobs).
CUCM has many default roles, called standard roles. Some of the standard roles are associated with CUCM Administration applications (CCMAdmin). There are many predefined roles in CUCM by default, but we explore two in this example. Two standard roles for CUCM Administration exist: Standard CCMAdmin Administration and Standard CCMAdmin Read-Only. Standard CCMAdmin Administration has all privileges of the CCMAdmin application set to Update, whereas Standard CCMAdmin Read-Only has CCMAdmin privileges set to Read-Only Access. Standard roles can be copied, renamed, and reconfigured to achieve the needs of the organization deploying CUCM.
CUCM has many default user groups, called standard user groups. Two examples of standard user groups are Standard CCM Super Users and Standard CCM Read-Only. User group Standard CCM Super Users is associated with role Standard CCMAdmin Administration, and user group Standard CCM Read-Only is associated with role Standard CCMAdmin Read-Only. This is illustrated in Figure 6-2.
To assign an end user full access to all configuration pages of CUCM Administration, you have to assign the end user just to the Standard CCM Super Users group. End users who should have read-only access to all configuration pages of CUCM Administration just have to be assigned to the Standard CCMAdmin Read-Only user group. The appropriate application privileges are configured in the default roles, and the default roles are assigned to the corresponding user groups.
The final step required to achieve the objective of Figure 6-2 is to assign the users John and Jane to the Standard CCM Super Users group and to assign Kim and Tom to the Standard CCM Read-Only user group.
Figure 6-2 Roles and User Groups
Standard CCM Super Users
Standard CCM ReadOnly
Standard CCMADMIN Administration
Standard CCMADMIN Read-Only
Cisco CallManager Administration
Cisco CallManager Administration
• Call Park Web Pages
• AAR Group Web Pages
• CallManager Group Web Pages
• DRF Show Status Page
NOTE CUCM has numerous default user groups that cover the needs of most requirements. Examples of default user groups include the following:
■ CCM Super Users
■ Standard CCMAdmin Read-Only
■ Standard CAR Admin Users
■ Standard CCM Server Maintenance
■ Standard CCM Server Monitoring
■ Standard CCM Phone Administration
■ Standard CCM End User
■ Standard CCM Gateway Administration
User management options in CUCM include the following:
■ CUCM Administration: Suitable for configuring a small number of users or doing single updates to the configuration of a user. CUCM administration of users is not scalable for large deployments of CUCM.
■ Bulk Administration tool (BAT): BAT is a tool that allows large insertions, updates, and deletions of users when LDAPv3 synchronization is not leveraged. Many learning institutions have frequent changes to the user database. BAT is an excellent tool for initial deployment or large updates to many configuration options, including the user database.
■ LDAPv3 integration: LDAPv3 integration allows end users to be synchronized from a centralized database to CUCM. This option proves useful when all the end users already exist in an LDAPv3 database. LDAPv3 user synchronization is available only to end users. LDAPv3 authentication is another LDAPv3 feature that can be leveraged. LDAPv3 authentication passes any authentication requests through the CUCM server to the LDAPv3 server where the user login is authenticated. LDAPv3 authentication has the benefit of maintaining one central password database. CUCM does not replicate the passwords that are configured in the central LDAPv3 database.
LDAPv3 synchronization replicates data to the CUCM database. User data cannot be modified from CUCM administration tools when LDAPv3 synchronization is enabled.
User data is modified on the LDAPv3 server by the LDAPv3 administrator, and resynchronization will occur at the next resynchronization interval. Depending on the resynchronization schedule, the resynchronization event might not occur for days or weeks. Manual synchronization can be performed at any time.
Passwords are not replicated to the CUCM database when LDAPv3 authentication is turned on. User passwords may exist in both CUCM and the LDAPv3 server if the user exists in both servers. It is recommended to combine LDAPv3 authentication with LDAPv3 synchronization to avoid inconsistencies in usernames and to eliminate the need for maintaining multiple usernames.
Table 6-2 summarizes the differences between the local CUCM database, LDAPv3 synchronization, and LDAPv3 authentication.
User ID, First Name, Middle Name, Last Name, Manager User ID, Department, Phone Number, Mail ID
