Users and Authentication for Cisco UC

History

Cisco UC (Unified Communication) family has many members - CUCM (CallManager), Unity, UCCX (IPCC Express), CER, CUPS, etc.

Previously, Cisco UC products are running on Microsoft Windows platform as regular applications.  Since from CUCM 5.0, Cisco starts migrating UC products to RedHat Linux platform.  For security and supportability consideration, Cisco decided to lock down user access to Linux OS.  Users can only access the application via web interface or a Cisco tailored CLI (Command Line Interface).

For redundancy and load balancing, there might be multiple nodes (servers) in a cluster.  For example, there are usually Publisher and Subscribers in a CUCM cluster.  Different nodes will communicate with each other for database synchronization and "Change Notification".  For security, these communications needs to be encrypted and authenticated.

Because of historical reasons, there's no unified structure for user management and authentication across UC products.  Each product has its own way.  Cisco is working hard to unify it but not quite there yet (as of today).

Passwords during Installation

We'll use CUCM as example to explain passwords during installation.  There are three usernames/passwords you may need to enter during installation.  Please note that even though you may use same username/password for all of them, they are actually three different credentials.  Changing one of them will not change the others.  They are stored in different places for different purposes.

1. Platform Administrator

"Platform Administrator" is also known as "OS Administrator" or "CLI Administrator".  This is a Linux user stored in /etc/passwd file.

"Platform Administrator" is used for command line interface (CLI), OS Administration and Disaster Recovery web interface.

Platform Administrator's password will NOT be synchronized across nodes.  It can be changed from CLI using "set password user admin" commands. (ref: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cli_ref/8_6_1/cli_ref_861.html#wp156897)

2. Security Password

If  you're installing subscribers, you'll see a different screen as below.  You should enter "First Node" (Publisher's) security password instead of an arbitrary password.

Security Password is stored in /usr/local/platform/conf/PlatformConfig.xml file.

Security Password is used by the system to secure communication between nodes.  Once it's set, you rarely "use" (type) it.  The only occasion you use (type) it is when you adding a new node (e.g. add a new CUCM server to the cluster, add a CUPS server to the clusters, etc.)

Since security password is used for inter-node communication, it needs to be identical on all nodes.  i.e. if you should change the security password, you should change it manually on all nodes.  Security password will NOT be synchronized across nodes.

To change security password, use "set password user security" command (ref: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cli_ref/8_6_1/cli_ref_861.html#wp156897)

 3. Application Administrator

Application Administrator is the most frequently used credential.  You use it for daily administration (through "CM Administration" web page).

Application Administrator is stored in database (in "applicationuser" table).

Database will be synchronized across different nodes.  Thus application administrator password will be synchronized as well.  To change application administrator password, go to CM Administration > User Management > Application User.

Application User vs. End User

If you ever noticed that on CM Administration > User Management, there is a "Application User" menu and a "End User" menu.  What's the difference?

"Application Users" and "End Users" are two different sets of user stored in separate database tables - "applicationuser" and "enduser".

Why two sets of user?  Why not just one set?  Good questions.

Linux and Windows only have one user repository.  For Linux, it's /etc/passwd file.  For Windows, it's C:\Windows\System32\config\sam file.  Why Cisco UC has two user tables?

It's really a choice of the Cisco developers'.  Yes, it's possible to use one table for all users.  But in Cisco developers' opinion, it complicates the design of the system.

As the name indicates, "Application User" credentials are supposed to be used by application instead of a human being.  For example, an AXL credential could be used by UCCX, CUPS or other application to access the CUCM database.  This AXL credential is used by application only, not by a human being.

Some of the credential policies might not apply to "Application Users".  For example, we might want end users change their password every month for security concerns.  However, we don't want the same policy apply to application users because those passwords are less likely to be leaked.

CUCM has the option to synchronize LDAP (e.g. Active Directory) users into "enduser" table.  If there should be conflicts in LDAP and the database table, things would be complicated.  For simplicity and safety, Cisco decided to have a separate database table called "applicationuser".  "applicationuser" table will not synchronize with LDAP.  Nor will it use LDAP authentication.

Shall I use "Application User" or "End User"?

Generally speaking, if the credential is used by human being, it should be in the "End User" table (either created manually or synchronized from LDAP.  For example, system administrators, call center agents, phone users, UC application users, etc.

In contrast, if the credential is used by software for internal communication purpose, it should be created in the "Application User" table.  For example, AXL, CTI, JTAPI credentials.

One exception is the "System Administrator" account.  You should always have a backup account in "Application User" on top of the accounts in "End User".  This is especially critical when you're using LDAP authentication.  If for some reason, CUCM was not able to communicate with LDAP server, none of the "End User" accounts would be able to authenticate.  In this situation, you need an "Application User" account to get into the system.  Remember "Application User" is exempt from LDAP authentication.

Can I have identical user ID in "Application User" and "End User"?

No.  Even though "Application User" and "End User" are two separate tables, they are treated as one big pool of users.  User ID needs to be unique across "End User" and "Application User".

For example, if you already have a user named "John Doe" in "Application User", you cannot have "John Doe" in "End User".  This is a commonly seen problem in CUCM LDAP synchronization.

Will "Application User" and "End User" be synchronized across different nodes?

Yes.  "Application User" and "End User" are part of CUCM database.  They will be synchronized to all CUCM nodes within the same cluster.  But database will not be synchronized to different types of nodes.  i.e. CUCM database will not be synchronized to UCCX, CUPS, etc.

Password Recovery

To recover "Application Administrator" password, use CLI command "utils reset_application_ui_administrator_password" (ref: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cli_ref/8_6_1/cli_ref_861.html#wp222750)

To recover "Platform Administrator" or "Security Password", follow procedure on http://www.cisco.com/en/US/partner/docs/voice_ip_comm/connection/9x/os_administration/guide/9xcucosag020.html#wp1053218

User Authentication

User authentication is probably the most confusing part in Cisco UC world:

• End User vs. Application User
• Local Authentication vs. LDAP Authentication
• Different applications (Web Page, RTMT, Extension Mobility, Voicemail, Agent Desktop, CUPC/Jabber Client)

Authentication Target

Depending on what you're trying to access, the system (e.g. CUCM) will authenticate against different user repositories (file, database table, LDAP).

CLI, "OS Administration" or "Disaster Recovery" web page

• CLI (Command Line Interface)
• "Cisco Unified OS Administration" web page
• "Disaster Recovery System" web page

When you're trying to access the above, the system will authenticate against file /etc/passwd, which holds your "Platform Administrator" account.  This does NOT involve any "Application User", "End User", or LDAP.

RTMT, "CM Administration", "Unified Serviceability", "Unified Report", "User Options" web page

• RTMT (RealTime Monitoring Tool
• "Cisco Unified CM Administration" web page
• "Cisco Unified Serviceability" web page
• "Cisco Unified Reporting" web page
• "Cisco Unified CM User Options" web page

When you're trying to access the above, the system will authenticate against CUCM database ("applicationuser" table and "enduser" table).  The system may also authenticate external LDAP server (e.g. Active Directory) if "LDAP Authentication" was enabled on CUCM.

Diagram below shows the authentication flow chart.

Please note that having the right username/password does NOT guarantee your access.  Appropriate permissions also need to be configured inside the system to grant you access.  For example, you need to put a user into "Standard CCM End Users" group before he can access the "User Options" page.

Complications and Confusions of different Applications

As mentioned before, different applications (CUCM, UCCX, CUPS, etc.) are developed by different groups.  Unfortunately, at the time when the applications were first developed, there's no unified architecture.  Now Cisco labels them as "Unified Communication Applications".  However, lots of work still needs to be done before they are really "unified".

UCCX

UCCX (Unified Contact Center Express) is also known as IPCC Express or CRS (Customer Response System).

Since from version 8.5, UCCX was migrated to Linux platform (just like CUCM).  The installation process is very similar to CUCM.  However, the use of "Application Administrator" is quite different.

To explain the reason behind the design, we need to travel back to the Windows time.

When CallManager was based on Windows, there's only one user database - end users.  UCCX relies heavily on CallManager.  Instead of managing a duplicated set of users, it makes sense for UCCX to "import" users from CallManager and make them call center agents, supervisors, administrators, etc.  All UCCX authentication was referred from UCCX server to CallManager server via AXL protocol.

Now here comes the "chick-and-egg" question.  How do we get into UCCX to configure the AXL parameters?  In order configure AXL parameters, we need to log into UCCX administration web page.  However without AXL being set up, how do we authenticate the administrator credential?

UCCX developer found a "creative" way (which was not a good idea in my opinion) - The first time you log into UCCX Administration web page, you use a temporary credential "Administrator" with password "ciscocisco".  After you logged in, you do all kinds of "initialization" such as upload license, configure AXL parameters, etc.

After AXL parameters were configured, UCCX server is able to see the end users on CUCM.  Then you specify one of the end users as "UCCX Administrator".  After this initialization, the temporary "Administrator" account is disabled.  You need to log in with the specified CUCM end user account thereafter.

This model has quite a few drawbacks:

1. Many customers are not aware that the first-time account "Administrator" is a temporary/one-time account.  I've seen cases that after years customer still thought they could use the "Administrator" account to log into UCCX Administration.

2. UCCX Administration solely relies on CUCM end user database.  In UCCX, there's no way to specify an "Application User" as "UCCX Administrator".  If the end user was deleted/disabled from CUCM or LDAP, there's no way to get into UCCX Administration.

3. The "Application Administrator" credential created during UCCX installation is practically useless.   You can't use it for UCCX Administration.  You can't use it for UCCX Serviceability.  (The only place you use it is "Cisco Unified Serviceability" which is almost useless for a UCCX server.)  This is VERY different from CUCM.

* It was said that from UCCX 9.0, "Application Administrator" credential can be used as UCCX Administrator.  If that's true, it would be a BIG improvement.

4. Agent authentication (such as Agent Desktop login) was referred from UCCX server to CUCM server (via AXL).  i.e. if something wrong with AXL, UCCX agent won't be able to log in.

Agent Desktop login flow chart as below:

CUPS

For CUPS, the "Application Administrator" credential created during installation works the same as CUCM.  i.e. You may use that credential to log into CUPS Administration.

Like UCCX, CUPS also import users from CUCM "end user" table.

Unlike UCCX, CUPS also import end user passwords.  The advantage is - CUPC/Jabber client authentication is NOT referred to CUCM server.  It's done either locally on CUPS server or LDAP server (if LDAP Authentication was enabled).

CUPC/Jabber login flow chart as below:

JTAPI/CTI

JTAPI and CTI are two different protocols.  But from end user perspective, they do similar things - allows software control telephones.

UCCX uses JTAPI to control phone calls.  CUPC/Jabber client uses CTI.  Besides protocol difference, the authentication models are quite different as well.

When CAD (Cisco Agent Desktop) is trying to control the call, it does not talk to JTAPI server (CUCM) directly.  It talks to UCCX server.  The request was proxied by UCCX server to JTAPI server.  A single 'JTAPI' credential is used for UCCX server to authenticate with JTAPI server (CTIManager service on CUCM).

Below is the Call Control flow chart of Agent Desktop:

When CUPC/Jabber is trying to control the call (DeskPhone Control), it talks to CTI server (CUCM) directly.  The individual end user accounts are used to authenticate with CTI server (CTIManager service on CUCM).

Below is the Call Control flow chart of CUPC/Jabber:

What does this mean as far as "authentication" is concerned?

Proxied Authentication (UCCX/JTAPI)

Proxied Authentication happens between UCCX server and CUCM server.  Most likely, those servers are in the same server farm (same subnet/location).  It's unlikely to have firewall/access-lists between those servers.  Thus communication is considered more reliable.

JTAPI credential can be created as "Application User" in CUCM.  So it's less dependent on external entities (such as LDAP).

However, any change to the JTAPI credential will affect all agents, because they rely on the same JTAPI account.

Direct Authentication (CUPC-Jabber/CTI)

Direct Authentication happens between CUPC-Jabber client and CUCM server.  Communication issues would be the major part of troubleshooting.  Clients and servers are usually in different subnets across different networks (possible Wide Area Networks).  Not to mention numerous firewalls (standalone network-based firewalls, software-based PC firewalls, etc.).

If LDAP authentication was enabled, things would be more complicated.  In order to do call control, clients need to authenticate with CTIManager, which in turn, needs to authenticate with LDAP.  More than 90% of the phone control issue was caused by LDAP authentication referral.

It takes another book to explain why LDAP referral would cause problem.  But as a rule of thumb, go to CUCM > System > LDAP > LDAP Authentication.  Make sure you're using Global Catalog port (3268 by default.  3269 if you're using LDAP over SSL).  Don't forget to restart Cisco Tomcat service after making changes.