Remote LDAP query failing

[mjs]

I'm trying to perform an LDAP query against our Zimbra server from a workstation on the same LAN, but the connection is refused. I've tried telnet to port 389 and that fails as well. From the Zimbra server, connections to localhost on port 389 work, but to the local IP will fail. It seems this is just a simple config issue, but I can't find anywhere to tell it to allow queries from anywhere but localhost.
I've also checked IP tables, and it is wide open.

Thanks

[djve]

I'm going to assume you can ssh into the Zimbra machine and haven't been using a console, ergo networking is basically OK.

On the Zimbra server does 'ps -ef |grep slapd' return something like:
/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://zimbratest.xxx.com:389 -f /opt/zimbra/conf/slapd.conf

And have you checked the address with IP config? I normally find I have a typo on these sort of commands.

You may want to check out the man page for slapd.access and check the slapd.conf file for IP restrictions. If you have LDAP queries restricted by IP you should check your config. I don't know where the slapd.conf file gets updated by the admin commands but this should help find what's wrong as a first step.

[mjs]

Yes I can ssh. All other ports are responding as well. This server is in full production.

ps -ef returns:
zimbra 20467 1 0 08:25 ? 00:00:27 /opt/zimbra/openldap-2.3.21/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://localhost.localdomain -f /opt/zimbra/conf/slapd.conf

I've looked in slapd.conf, but I don't see anything regarding connection restrictions. The man page doesn't seem to have anything relevant either.

There isn't a slapd.access file. Quoting from the slapd.access man page "If no access controls are present, the default policy allows anyone and everyone to read anything but restricts updates to rootdn." So it doesn't seem thats the issue either.

Thanks

Originally Posted by djve

I'm going to assume you can ssh into the Zimbra machine and haven't been using a console, ergo networking is basically OK.

On the Zimbra server does 'ps -ef |grep slapd' return something like:
/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://zimbratest.xxx.com:389 -f /opt/zimbra/conf/slapd.conf

And have you checked the address with IP config? I normally find I have a typo on these sort of commands.

You may want to check out the man page for slapd.access and check the slapd.conf file for IP restrictions. If you have LDAP queries restricted by IP you should check your config. I don't know where the slapd.conf file gets updated by the admin commands but this should help find what's wrong as a first step.

[djve]

I just tried my test machine (we're still evaluating Zimbra).

I get the same issue:

telnet zimbratest.xxx.com 389
Trying 10.150.1.170...
telnet: connect to address 10.150.1.170: Connection refused

and I know my system is running. And my other replicas are talking.

I'm using the rPath appliance and ssh and apache/tomcat is fine.

So I'm going to dig into this today but it's obviously how Zimbra sets up it's LDAP services.

[djve]

Got it. It's in the slapd man page.

When slapd is started with "-h" it'll bind only to the addresses supplied. I use "ldap:///" on my replicas and that bind to all addresses. It's been months since I last looked at this so I'd forgotten it.

[djve]

And the startup is hardwired into the script .../zibra/bin/ldap. $my_url comes from $ldap_url. These variables come from a java call that I haven't got time to debug.

In consideration this makes sense from a security standpoint. Many people running Zimbra are running the stack in a DMZ or in a semi-open network. If people have access to the port then they can keep hammering on the LDAP daemon until they crack it and download the details of users and compromise the accounts.

So the Zimbra people have done the right thing, just unexpected for those of us used to running LDAP by itself.

[mjs]

Makes sense, but mine is behind a firewall so there is not much chance of ldap getting exposed. The reason I need to query it from an external source is that we use an IronPort spam filter front end server. It's only method of address validation is via ldap queries.

So there is no way to remove this -h parameter?

[djve]

Yes, you can remove the parameter. But the next upgrade would put it back. Look at the ldap script. So I wouldn't go that way.

I'd ask someone from Zimbra if there as recommended method. Check the wiki first to see if someone has solved this for you.

[mjs]

I'll take a look. Thanks