Failed to Connect to ldap:<server name>:389

Unanswered Question
May 8th, 2012

Hello,

I wanted to know if anyone can help me resolve the issue I am having with connecting my Callmanager 7.1.5 with my AD LDAP.  No matter what I try, I get the meeage:

Failed to Connect to ldap:<server name>:389

I am able to ping the AD server from the callmanager and ping the callmanager IP from the AD server.

I have tried using SSL port : 636 as well.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Joe Martini Tue, 05/08/2012 - 10:00

The easist way to troubleshoot is to start a packet capture from the publisher and leave it running while you click save which initiates a connection to the LDAP server.  Once you see the error message on the screen you can stop the packet capture and take a look at it to see why it fails to connect.

Here's how to take a packet capture if you're not familiar with it:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080b36101.shtml

David Hailey Tue, 05/08/2012 - 12:17

389 and 636 are the well-known LDAP ports.  You might also try the Global Catalog ports of 3268 and 3269.  It would be worthwhile to find out of there is an ACL and/or firewall that might be restricting access as well.

Hailey

Please rate helpful posts!

Anthony Holloway Tue, 05/08/2012 - 12:18

Joe, any information on why LDAP errors are not logged in the DirSync log files, even when set to debug?  I was recently troubleshooting an LDAP issue and had to resort to a packet capture myself.  Thanks.

FYI, if you do a packet capture on a non-SSL enabled AD integration, be prepared to see usernames and passwords, in clear text,  in the ldap.bindReuest messages.

Jaime Valencia Tue, 05/08/2012 - 12:21

Are you 100% sure your AD admin and OU settings are correct????

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

vipankapur1 Tue, 05/08/2012 - 12:50

I have tried port 3268 and 3269.  I ran a packet trace and I got an XML file back, how do I see what could be causing the issue.  The AD and OU settings are correct.

David Hailey Tue, 05/08/2012 - 12:55

Is there a firewall and/or ACL in the path between CUCM and AD?

You could load an LDAP browser and attempt to bind using the same credentials from a machine in another subnet.

http://www.netcraftsmen.net/blogs/uc-toolkit-part-1-ldap-browsers.html

Hailey

Please rate helpful posts!

vipankapur1 Wed, 05/09/2012 - 10:17

There is no firewall or ACL between AD and CUCM.  I was able to bind  the ldap server using an ldap browser, but when I try to connect I am  still getting the same error on all ports.

Any other suggestions?

Thank you for the help.

Joe Martini Wed, 05/09/2012 - 10:33

If you downloaed the packet capture using RTMT, you should see an XML file as well as a directory with the server name.  Inside the directory with the server name you should find a platform/cli/.cap file that we can look at.

David Hailey Wed, 05/09/2012 - 10:38

Try entering the LDAP user account in the following format:

user@domain.com

Make sure that the user you are specifying (in your case, ccmadministrator) was created as an account in AD along with the password you are specifying as well.

See if that works for you.

vipankapur1 Thu, 05/10/2012 - 06:57

Joe:

I have a directory with the server name, but no .CAP file.  I even selected all services when I collected the files.

David,

The ccmadministrator account is created in AD and the password is correct, I have reset the password and tested again, with the same results.  I have also tried using the AD admin account to see if it connected, but I get the same error.

Actions

Login or Register to take actions

This Discussion

Posted May 8, 2012 at 9:34 AM
Stats:
Replies:10 Avg. Rating:
Views:3707 Votes:0
Shares:0
Tags: failed, connect
+

Related Content

Discussions Leaderboard