Let's start off by compartmentalizing end users versus application users, they're very distinct. End users manage their individual phones. Application users run things like an application within the environment, such as, maybe they are in a primary answering position so they are in the attendant console environment, or maybe they are managing the Contact Center Express or logging in to Contact Center Express or the Communications Manager Assistant tool. So all of these have a unique login capability because they're logging into these different applications and they need different credentials and options. And there's actually two distinct areas in the Communications Manager where we store these end users versus application unit users and how we get them. Application users we have to create in the Communications Manager database. And users we could tie into an external directory LDAP compliant and import these users. And there's different ways that we can manage them from that, we can even just synchronize, get all the users from active directory as an example and then we manage them. Or we could have active directory play a key role in maintaining their user credentials such as their logins and their passwords. So we'll look at those different options but I just wanted you to understand right off the bat we have two distinct end users – end users and application users.
A key piece that we manage are the credentials. We want to make sure that the end-user passwords, pins, and even the application user passwords are set up in such a way that we are somewhat in control. Now again we still could tie into active directory as a side note, but we have a credential policy default window, which gives us the options to change these default credential policies assigned to our users. We also have the ability to manage passwords and making sure they're not three letters long.
So we can go in and say what the number of allowed failed logon attempts are. We can say, hey after a couple of login attempts if it fails that's it you're locked out. We can set the minimum credential length, the duration between credential changes, so let's say we want to force everybody every 90 days to change their password. The number of previous credentials stored so they don't keep repeating that password, and then finally the number of days until credentials expire. In other words give them a warning and say hey, in 10 days your credentials are going to expire, you need to go in and change those.
Features Interacting with User Accounts
Now when we're looking at our user accounts we look at the Communications Manager and see what it is we are managing. So if we go in and we're just creating user web pages or we're gaining access to the administrative GUI environment such as the serviceability menu, the OS administration, your Disaster Recovery System, all of those have accounts that you're going to need to manage. We also have the applications, like extension mobility, the Communications Manager Assistant, we also have directories that we can manage and we have IP phone services. And with IP phone services if you think about the XML applications that you might be tying into within those XML applications, there may be login credentials, we're not managing those but the application might be managing those. So it may force a user to log in a couple of times and you might want to think about that. If I can gain access to the service but then that service as a stand-alone entity has credentials you may just want to use those credentials to force a log in instead of having somebody have to log in to the phone service to access it and then log in to whatever service it is that they're gaining access to.
Types of User Accounts
Here's a breakdown of the user accounts. Remember there is really two. There is the end users and there is the application users.
|End Users||Application Users|
|Associated with an individual person||Associated with an application|
|For personal use in interactive logins||For noninteractive logins|
|Used for user features and individual administrator logins||Used for application authorization|
|Included in user directory||Not included in user directory|
|Can be provisioned and authenticated using an external directory service (LDAP)||Cannot use LDAP|
Here is a list of all of end user options where we have a person, we have a person that's going to have an interactive log in, they're going to be able to manage their phone, it could be used within your directory, so when people pull up a directory they now can see the username and the extension associated with it. And again end users we could tie into an LDAP database that could be external and we could synchronize those end users and pull them into our environment so we don't have to create them necessarily. We may need to do some modifications but don't forget BAT, we could use BAT to get those users. Well first of all synchronize, get the users in, export the users make your modifications and then import them back into the system – much easier than typing in 1,000 individual users, that's what I'm thinking. But there is application users – you're not going to be able to use LDAP, but typically we aren't adding quite as many application users because they're specific to an application, such as the Contact Center Express or a Communications Manager Assistant, all of that is considered internal. So these are internal users that we're going to be creating and storing within the Communications Manager database, not reliant on LDAP or an external environment. With our end users we still could store them in the Communications Manager database but again we could import them or synchronize them with an external LDAP directory and that makes it much easier.
The user locale is the language that we're going to be selecting. Now there isn't translation that goes on here other than the fact that what is system displayed on devices or within the user web pages can now be displayed in the language that they've selected or that you've selected. If the phone load configuration locale needs to be updated or we need to download that it's going to come from our TFTP server. We also can see configuration files for the devices that are going to contain the locale information.
Any kind of language that you want displayed on that phone, because a lot of times we have topologies that may span into other countries so we don't want to force people in Germany to have to be able to read the English language that's going to display on their phones - we can select Germany for that locale and now their information will display in German. Like I said, it doesn't do any translation as far as that goes, but it does display the appropriate language on that phone.
When we associate users with devices, these devices can include of course phones, the IP communicator and any extension mobility profiles. So end users can be associated with devices, and within that we could have unique user attributes, things like the corporate directory that allows users to display a personal name. We can have that dial by name feature, so that can also utilize the user information. We also have the ability to manage computer telephony integration (CTI) route points. This is specifically used in the contact center solution. This could be the contact center extension number, so all the call routing scripts to your agents, all can be set up and the call routing numbers can be managed.
Then we also have presence. Presence is the one that collects information about your availability to take a call so your user communications device such as your IP phone or your Cisco Unified Presence Communicator can all be associated with your user account. That's how it all kind of ties together, all of your devices, all of your personal communicator information or any applications that you're working in, can all be managed through that user account.
User Access Levels in Cisco Unified Communications Manager Express
We can provide different user access level within our Communications Manager Express. We can set up a system administrator account, which can do everything. The customer administrator, which we could limit, like let's say that we want them to manage phones and we just want them to add, change, delete maybe telephone devices. We can set up that customer administrator level. Then the phone user themselves managing their speed dials, and all the pertinent information that an end user would manage.
Now in order to set this up, we as the administrator can define user level access and we can do it via the command line. We could do remote Authentication Authorization and Accounting (AAA), we could have a AAA server configured with our user accounts and we'll use the ip http authentication command to enable access to the remote authentication server. In other words to point to that AAA server and if authentication to the server fails the local router could also contain a database that can be configured with your users and their appropriate user level access.
User Locale in CME
In the Communications Manager Express we can manage user locales. We have about 12 that are built-in, we can have up to five user and network locales, we can associate different phones with different locales so that's helpful, and we can go in and manage these files either on the Communications Manager Express or we could offload them to an external TFTP server. The system now has one default config file for all your IP phones in the system, and then in the Flash or slot 0: this file can be applied per IP phone type or per individual IP phone. Of course if we make a change the phone has to be reset in order for it to grab that new locale.