04-21-2015 06:20 AM - edited 03-17-2019 02:44 AM
We recently updated from 9.1.2.12901 to 9.1.2.13900. Once we finished updating, users are no longer to sign in to the CCMUser portal. Users who use the CM Attendant Console are also unable to sign in. We were able to sign-in appropriately prior to the upgrade. On the CCMUser portal, I am getting the following error:
'An LDAP Error has occurred. Retry the username and password. Contact your system administrator if the problem persists.'
I have made sure that the users who need it are assigned the Standard CCM User Role. I have also removed that role from my account, saved, then added it back and saved. No change.
Oddly enough, I can go into System-->LDAP-->LDAP Directory, perform a sync and it will pull in new users or remove users accordingly.
We use secure LDAP for Microsoft AD. All certificates are loaded to the system.
Any help would be much appreciated.
Kevin
Solved! Go to Solution.
04-22-2015 10:12 AM
Then we need to check the logs, please collected "Cisco Tomcat Security Logs" through RTMT covering the time of a login attempt.
04-21-2015 11:27 PM
Hello Kevin,
To isolate the issue, can you please create local user with Standard CCM User Role and test it?
Thank you,
Shadi
04-22-2015 06:22 AM
a local user works fine. Test user is able to sign in to the CCMUser portal with no issue.
04-22-2015 09:22 AM
Which means only active directory users affected.
We need to confirm if both LDAP sync and LDAP Authentication configured properly, can you please navigate into each one and hit click on save. And please confirm the configurations are correct.
1. system > LDAP > LDAP Directory: Click on save.
2. system > LDAP> LDAP Authentication: Click on save
04-22-2015 09:22 AM
Yes, these have been confirmed working.
04-22-2015 10:12 AM
Then we need to check the logs, please collected "Cisco Tomcat Security Logs" through RTMT covering the time of a login attempt.
04-22-2015 07:44 PM
In looking through the Tomcat Security Logs, it kept erroring out due to a FQDN/hostname mismatch in the certificate. I verified it as correct in the certificate. For the time being, after talking to TAC, we issued a 'utils ldap config ipaddr' to match on IP instead of FQDN. We'll revisit the security certificate issue at a later date when users won't be impacted by testing. Thanks for the nudge in the right direction.
04-22-2015 09:43 PM
Thanks for the update.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide