LDAP Account able to log into CUIC but not UCCX Admin

[paultrenter]

Hi all, hoping someone can point me in the right direction. I have a few accounts aside from the main appadmin user that need access to UCCX Admin GUI.

Local accounts on CUCM seem to work fine when added into the UCCX Admin Users. I'm trying LDAP accounts though and getting "Invalid User ID or Password". They can log into CUIC though with the same account.

Any ideas? Version 11.5

****I've also posted this in the IP Telephoney forum by mistake, if someone could remove that duplicate that would be great.****

[Mark Swanson]

Most likely, the users do not have permissions to UCCX Administration. Only admins and supervisors can login to the UCCX Administration webpage, however, supervisors have limited permissions compared to admins. Try this...

1. Login to the UCCX Administration webpage via https://uccx-fqdn/appadmin

2. Under Tools > User Management, select "Administrator Capability View"

3. Type the user's User ID into the search box and click 'Search'

NOTE: If the User ID displays under the 'Available Users' search window, then they do not have admin rights

4. Highlight the User ID and then, click on the left arrow to give them admin rights. That's assuming they need access to the UCCX Administration webpage

5. Ask them to login again

[paultrenter]

Sorry Mark I should have stated that I'd done that.  They are listed in Admin users.

Also when they fail to log into CCX Admin, that number of failed attempts shows when they next log into CUCM.

[Anthony Holloway]

Since the LDAP authentication process seems to be working, I would focus my attention on the Admin permission.

Can you post some screenshots confirming what you've configured and tested? There really isn't any additional "trick" to get this to work.

Can you turn up the AXL logging to debug level and attempt the login?

This is what I see on my system when I login to UCCX with an LDAP account:

2019-11-14 12:02:16,736 INFO  [http-bio-443-exec-85562] servletRouters.AXLAlpha - Executing api: doAuthenticateUser in axis
2019-11-14 12:02:16,736 DEBUG [http-bio-443-exec-85562] wrappers.RequestNamespaceWrapper - Inside Request Wrapper
2019-11-14 12:02:16,736 DEBUG [http-bio-443-exec-85562] servletRouters.AXLAlpha - AXL REQUEST :

 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.0"><SOAP-ENV:Header/><SOAP-ENV:Body><ns:doAuthenticateUser><userid>AHolloway</userid><password>***********</password></ns:doAuthenticateUser></SOAP-ENV:Body></SOAP-ENV:Envelope>

2019-11-14 12:02:16,737 DEBUG [http-bio-443-exec-85562] servletRouters.AXLAlpha - Request processed by AXIS
2019-11-14 12:02:16,738 DEBUG [http-bio-443-exec-85562] axlapiservice.Handler - dbConnector Initialization in handler.java
2019-11-14 12:02:16,739 DEBUG [http-bio-443-exec-85562] axlapiservice.Axl - Connection given to current thread
2019-11-14 12:02:16,851 DEBUG [http-bio-443-exec-85562] axlapiservice.DoHandler - DoAuthenticateUser completed
2019-11-14 12:02:16,851 DEBUG [http-bio-443-exec-85562] axlapiservice.Axl - Connection closed and hashmap entry removed in AXL.java closing connection
2019-11-14 12:02:16,854 DEBUG [http-bio-443-exec-85562] servletRouters.AXLAlpha - <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns:doAuthenticateUserResponse xmlns:ns="http://www.cisco.com/AXL/API/10.0"><return><userAuthenticated>true</userAuthenticated><code>0</code><daysToExpiry>0</daysToExpiry></return></ns:doAuthenticateUserResponse></soapenv:Body></soapenv:Envelope>
2019-11-14 12:02:16,854 DEBUG [http-bio-443-exec-85562] servletRouters.AXLAlpha - Finished processing request

[paultrenter]

Hi Anthony, my debug had a few more lines so I've attached as a file.  Hope it helps find the cause of the issue.

This might be a one off, as I've just added another LDAP user and they logged into CCX Admin ok.

[Mark Swanson]

Did you try to remove, save and then, re-add the user's permissions to UCCX Administration? 

[Anthony Holloway]

Oh I see, you pulled MADM logs off UCCX. I was pulling AXL logs off of CUCM.

But there is a line above where your logs start which would look like this:

6172671: Nov 14 13:29:25.420 CDT %MADM-LIB_AXL-7-UNK:[MADM_LIB_AXL_CMD_EXECUTOR-20-834-com.cisco.config.axl.CCMUserAuthenticationSOAPAdmin] ExecutionCmd: AXL-ExecutionCmd-6074.CCMUserAuthenticationSOAPAdmin: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns:doAuthenticateUserResponse xmlns:ns="http://www.cisco.com/AXL/API/10.0"><return><userAuthenticated>false</userAuthenticated><code>1</code><daysToExpiry>0</daysToExpiry></return></ns:doAuthenticateUserResponse></soapenv:Body></soapenv:Envelope>

In that above example log line, I intentionally typed my password wrong.

[paultrenter]

Hi Anthony yes, a few lines above I see:

1402461: Nov 14 18:50:28.579 GMT %MADM-LIB_AXL-7-UNK:[MADM_LIB_AXL_CMD_EXECUTIOR-21-3134-com.cisco.config.axl.CCMUserAuthenticationSOAPAdmin] ExecutionCmd: AXL-ExecutionCmd-19250.CCMUserAuthenticationSOAPAdmin: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns:doAuthenticateUserResponse xmlns:ns="http://www.cisco.com/AXL/API/10.0"><return><userAuthenticated>false</userAuthenticated><code>1</code><daysToExpiry>0</daysToExpiry></return></ns:doAuthenticateUserResponse></soapenv:Body></soapenv:Envelope>

Is this a credentials issue then?  Wouldn't that effect CUCM as well though?  I have tried removing/readding to the CCX Admin User group too.

[Anthony Holloway · Accepted solution]

Correct, that is CUCM telling UCCX the username/password submitted is invalid. Make sure the user can login to CUCM (/ccmadmin if they are admin, and /ucmuser if not).

I would also double check that their password doesn't contain any weird characters. I cannot find the article at the moment, but I recall Cisco posted a notice that said to stay away from certain characters in passwords.

In fact, you said you have another LDAP account which can authenticate, which would mean your issues is account specific and not integration nor technology specific. Could you make the Webby password the same as the user who can login, just to prove a point?

[Mark Swanson]

Cisco docs say you cannot use a space character at the beginning or end of your User ID and Passwords cannot contain spaces. As noted by Anthony, there's a handful of extended ASCII characters not supported as well. What exactly? I don't recall. Also, each system or application might have a slightly different policy (i.e. character limitations or restrictions) for usernames and passwords... not to mention case sensitivity. Login to CUCM, UCCX and Cisco Finesse but change your User ID by using upper or lower case characters. I believe, Cisco Finesse is case sensitive whereas CUCM, UCCX and CUIC is not case sensitive.

Have you made any changes to the existing LDAP Directory and/or LDAP Authentication settings within CUCM? Do you have multiple LDAP Directories? If so, do they belong to the same Directory? Try this...

Convert the End User to a local account and delete the account from CUCM. Navigate to System > LDAP > LDAP Directory and click on "Perform Full Sync Now". This process might take a few minutes. After you reconfigure the user's profile, login to UCCX and reassign the admin role. What happens?

[paultrenter]

Just a quick update to say a big thanks, this has resovled the issue.  I never realised CCX Admin was so fussy on password characters, especially when CUCM/CUC, even CUIC etc are fine with it. 

This user in question had the £ and $ characters in his password.  He changed pw to alphanumeric and logged in fine.

[Anthony Holloway]

Thanks for replying with the solution.

I'm surprised too, that CUIC was able to pass the passed fine, since I would think it offloads authentication to UCCX, but maybe it steals the AXL info from UCCX and then performs it's been authentication.

I suspect the problem is with XML encoding of characters, since AXL is XML. Eg XML uses < and > for element names, and as such, text elements with those symbols in them need to be escaped.

Just a thought. Anyway, thanks again for closing the loop.

[Mark Swanson]

All of the special characters under the number keys should be okay, such as; ! @ # $ and so on. The problem was caused by the £ character. Cisco doesn't support most of these extended ASCII characters in the username and/or password.

[paultrenter]

The £ is on the number 3 this side of the water :)

Thanks for the info though.

[Mark Swanson]

Ahh okay. Then it makes sense why $ wouldn't be supported. Good luck.