Upgrade from 10.22 to 10.33 login takes over 15 mins using ldap user
I have opened a support ticket on this but just wanted to see if anyone else has experienced this issue. After upgrade from 10.22 to 10.33 login to the UI is taking over 15 mins to login. I can see where contacting the ldap server is 42 secs but it is not happening all the time. I tested ldap credentials in JMX console and it's taking about a minute and a half. Sometimes I go right in but that is few and far between. Once in the ucmdb it takes forever to go from module to module or even look at communication logs.
I have also opened a ticket with our local ldap admin.
We suggest to continue the ticket process to resolve the issue.
Customer Support Engineer
If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation. “
We had the same problem after upgrading from 10.22 to 10.33.
In the logs, we've found that the CMDB LDAP was trying to reach some sub-domains (as if the LDAP database contained hard-links, I'm not an LDAP guru ;)).
So we started the LDAP search from a deeper level, specifying additionnal OUs in LDAP URL.
In example :
- before : ldap://ldaphost:389/OU=ORG,DC=OurDC,DC=fr??sub
- after : ldap://ldaphost:389/OU=SubSubOU,OU=SubOU,OU=ORG,DC=OurDC,DC=fr??sub
This may not cover all your search scopes, but remember that 10.33 can have multiple LDAP sources !
Hope this helps !
The LDAP behavior in 10.22 is very different compared to 10.33.
Issues to consider:
- LDAP referrals - fixed only in CMS 11 but problematic for 10.33
- LDAP integration user, try to make the search more granular
- connection lost due to LDAP behind an LB and the active server is changed during the initial communication
- LDAP priority
- the wrong configuration of multiple LDAP servers which are in a failover cluster
- wrong user repository priority
- password complexity constraints
- invalid headers sent/received
Our suggestion is to handle this in a Support case as it's never an easy troubleshooting.
EMEA Technical Success
Thanks everyone for your input. I worked with the ldap team and we changed the port from the default 389 port to another port and it is working just fine now.