Background
In the 10.x train of Cisco UC, Cisco applied default credential policies to all accounts, including local application administrator accounts. These policies can be changed via the GUI for CUCM. However, with UCCX there is no access to modify these settings via the GUI nor are there any CLI commands that are helpful in permanently resolving instances where the appadmin account gets locked out due to login attempts, etc.
Occasionally, you may find that your appadmin account gets locked out. The UCCX admin and servicability pages indicate the username and/or password you entered is incorrect. However, if you attempt to log in with this account on the Cisco Unified Servicability page, it will clearly state that the account is locked. If the Unified Servicability page does not say "Account is locked" after you enter the credentials, this is almost certainly not the reason you cannot log in.
Solution 1: Unlock the account each time it becomes locked.
In order to unlock the account after a few invalid login attempts by an admin user who simply mistypes the password one too many times, log into the UCCX CLI and enter the following commands:
- utils reset_application_ui_administrator_name
- enter the existing account name. the command output will tell you it already found that account and will not continue
- utils reset_application_ui_administrator_password
- Type the existing password, don't actually change it. This command will complete unsuccessfully
In my experience, you have to enter them both. Even though they fail, they will unlock the account. If, however, something else is causing the account to go into violation of its credential policy, you may want to try solution 2.
Solution 2: Update the Credential Policy via SQL from the CLI
WARNING: If you don't feel comfortable executing SQL against the informix database, don't do this without TAC assistance.
The Cisco Telephony OS CLI includes commands to execute SQL against the Informix Database. The commands to find the right rows and update them are below:
First, confirm that the user account you are trying to use is the appadmin created at install. If it is, it will show up in this SQL Query:
admin:run sql select * from mmca_oampuser
oampuserid oampusername ouid lastupdated changestamp sysdefined
========== ============= ==== =========== =========== ==========
254 Readonly User 5 0 0 T
263 mmca_oamp 5 0 0 T
1 ccxadmin 5 0 0 T
Next, get a list of the application users defined on the system and their "pkid" value:
admin:run sql select name,pkid from applicationuser
name pkid
=================== ====================================
ccxadmin 06bae444-79f0-34bc-0b73-042e90ad941b
CCMSysUser ffd322cd-a1c9-48ce-b23f-6d9475e3547e
WDSysUser a3d8edb3-8dcd-4e70-a662-dc9afa7f81d3
CCMQRTSysUser a024f7be-4f36-4373-80dc-a45cb4b891b9
IPMASysUser d0b9ceb0-d752-46df-96b6-68d37aed70eb
WDSecureSysUser aaecf22c-ba36-4afd-a8b1-85fb4f02c04f
CCMQRTSecureSysUser 3f2bd34b-c7a1-4b04-a6d4-f75c24c05782
IPMASecureSysUser bd18e867-2c47-4a60-8740-83c36f178e99
TabSyncSysUser 826888c4-ef7b-48ea-99ba-a86de6c3b369
CUCService c06dd551-7d3a-4d85-bae9-c450ff03b151
presencevieweradmin 9001d8dc-392b-45b9-97d7-43a663acb50e
Now that you have the PKID associated with the application user, you can find the offending credential assigned to that user by executing the commands below:
admin:run sql select tkcredential,cantchange,credmustchange,fkcredentialpolicy,doesntexpire,timechanged,timeadminlockout,credentials from credential where fkapplicationuser='<PKID from ccxadmin account you found in previous step>'
tkcredential cantchange credmustchange fkcredentialpolicy doesntexpire timechanged timeadminlockout credentials
============ ========== ============== ==================================== ============ =========== ================ ================================================================
3 f f 4278c1c8-7160-438e-87db-3cc488223a21 f 1436302928 0 <REDACTED PASSWORD HASH>
You will notice that this row has options for "doesntexpire" which is defaulted to False. This field controls if the password expires. This will eventually cause an issue depending on if you leave the credential policy alone but is not likely to be the cause of your lockout issue. There is also timeadminlockout (timestamp for when the account was locked by an administrator), credmustchange (password must be changed at next login), and the credential policy associated with the credential. The blue text is the PKID for the credential policy where all of the evil is being done.
Now that we have the PKID of the credential policy we can pull the important fields for it.
admin:run sql select * from credentialpolicy where pkid='4278c1c8-7160-438e-87db-3cc488223a21'
pkid displayname hackresettime lockoutduration maxdays maxhacks minduration minlength prevcredcount trivialcredchecking expirywarningdays isstandard maxinactivedays
==================================== ====================== ============= =============== ======= ======== =========== ========= ============= =================== ================= ========== ===============
4278c1c8-7160-438e-87db-3cc488223a21 CUIC Credential Policy 1 1 0 0 0 1 0 f 0 f 0
What you see above is my already-modified CUIC Credential Policy, which is the culprit.
Defaults are:
- lockoutduration = 30 (minutes)
- maxdays 1440 (days before the password expires)
- maxhacks = 5 (bad password attempts before account is locked)
- hackresettime = 30 (minutes - timeframe in which the hack count is measured against maxhacks)
- minduration = minimum password age
- minlength = 6 if i recall correctly
- prevcredcount = 5 (number of passwords the system remembers and won't let you reuse)
- trivialcredchecking = trivial password checking...
- expirywarningdays = number of days before password expires that it would start warning you your password is about to expire.
- maxinactivedays = max number of days without logging in before this account is deactivated.
to change any one of these values you simply have to issue the command:
run sql update credentialpolicy set <field>=<value> [additional field/value pairs, comma separated] where pkid=<pkid from previous step>
This drove me insane for the better part of 2 months before I finally resorted to figuring out Solution 2. Hope it saves somebody else the insanity.
