Bug 518204 - Cannot connect from 389-console to directory server via loopback device (localhost)
Summary: Cannot connect from 389-console to directory server via loopback device (loca...
Alias: None
Product: 389
Classification: Retired
Component: Directory Console
Version: 1.2.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 434915 389_1.2.3
TreeView+ depends on / blocked
Reported: 2009-08-19 13:38 UTC by Dirk Husung
Modified: 2015-01-04 23:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-11 20:46:36 UTC

Attachments (Terms of Use)

Description Dirk Husung 2009-08-19 13:38:41 UTC
Description of problem:

After upgrading from fedora-ds to 389-ds via "yum upgrade" and running "setup-ds-admin.pl -u" I _can_ access the Administration Server but I _cannot_ access the Directory Server on the same machine from within 389-console.

The directory server has configured:
  nsslapd-listenhost:: OjpmZmZmOjEyNy4wLjAuMQ==
i.e. ::ffff:
As soon as I remove this restriction, everything works fine.

wireshark shows, that accessing the Administration Server uses localhost, while accessing the Directory Server uses the machines ip address which is blocked by the line above. (I want to restrict unencrypted ldap access to localhost only.)

Everything worked fine with the previous fedora-ds release.

Version-Release number of selected component (if applicable):

  389-admin i386 1.1.8-3.fc10  replacing  fedora-ds-admin.i386 1.1.7-3.fc10
  389-admin-console noarch 1.1.4-1.fc10 replacing  fedora-ds-admin-console.noarch 1.1.3-1.fc10
  389-console noarch 1.1.3-3.fc10 replacing  fedora-idm-console.i386 1.1.3-1.fc10
  389-ds noarch 1.1.3-4.fc10 replacing  fedora-ds.noarch 1.1.3-1.fc10
  389-ds-base i386 1.2.1-1.fc10 replacing  fedora-ds-base.i386 1.2.0-4.fc10
  389-ds-base-devel i386 1.2.1-1.fc10 replacing  fedora-ds-base-devel.i386 1.2.0-4.fc10
  389-ds-console noarch 1.2.0-4.fc10 replacing  fedora-ds-console.noarch 1.2.0-1.fc10
  389-dsgw i386 1.1.4-1.fc10 replacing  fedora-ds-dsgw.i386 1.1.2-1.fc10

 389-adminutil i386 1.1.8-3.fc10 (was 389-adminutil-1.1.8-2.fc10.i386)
Installing for dependencies:
 389-admin-console-doc noarch 1.1.4-1.fc10 
 389-ds-console-doc noarch         

How reproducible:

Steps to Reproduce:
1. upgrade from fedora-ds to 389-ds via yum upgrade, run setup-ds-admin.pl -u
2. configure in /etc/dirsrv/slapd-<instance>/dse.ldif: 
     nsslapd-listenhost:: OjpmZmZmOjEyNy4wLjAuMQ== 
3. run 389-console and try to access "Directory Server (<instance>)"
Actual results:

The directory server status is reported as "stopped", which isn't true (access via OpenLDAP's ldapsearch works fine). 
The Diretory Server console does not open.
wireshark shows ldap access to the machine's ip address, not to localhost.

Expected results:

LDAP access from 389-console to localhost when trying to open the Directory Server console from within 389-console, as before the upgrade

Additional info:

In the Admin Server Console under Configure Admin Server UserDS 
"Use Default User Directory" is selected, which is reported as:
ldap://localhost:389//dc=... (that looks correct to me)

Comment 1 Dirk Husung 2009-08-19 14:19:10 UTC
Sorry, for my typo, it is
ldap://localhost:389/dc=... (not ...//dc=...)

Comment 2 Rich Megginson 2009-09-30 15:21:01 UTC
I don't think the console is IPv6 aware.  Is this an IPv6 problem?

Comment 3 Dirk Husung 2009-10-01 13:13:32 UTC
We do not yet use IPv6.

To me it looked like this: When trying to open the Directory Server console (at least some) network traffic went to the machine's ip address, not to localhost as I tried to configure (may be I didn't configure it right, however it worked before the update).

My current workaround is to connect to the Directory Server console via ldaps
(which caused problems some time in the past, but works fine now).

This way only localhost is open for unencrypted access by an ldap proxy running on the same machine.

Comment 4 Rich Megginson 2009-10-01 16:56:45 UTC
If you do a netstat -an, what interfaces/ports does it show the directory server listening to?

Comment 5 Dirk Husung 2009-10-02 09:01:28 UTC
netstat -an | grep 389 | grep LISTEN:
tcp    0  0 xxx.xxx.xxx.yyy:389*                   LISTEN      
tcp    0  0 ::ffff:        :::*                        LISTEN      

netstat -na | grep 636 | grep LISTEN:
tcp    0  0 xxx.xxx.xxx.yyy:636*                   LISTEN      
tcp    0  0 ::ffff:xxx.xxx.xxx.xxx:636  :::*                        LISTEN   

xxx.xxx.xxx.xxx is the ip address of the 389-directory server
xxx.xxx.xxx.yyy is the ip address of the ldap proxy (OpenLDAP)

/etc/sysconfig/network-scripts/ifcfg-eth0 contains

/etc/dirsrv/slapd-<name>/dse.ldif contains:
nsslapd-listenhost:: OjpmZmZmOjEyNy4wLjAuMQ==
nsslapd-securelistenhost:: OjpmZmZmxxxxxxxxxxxxxxxx

OjpmZmZmOjEyNy4wLjAuMQ==  is ::ffff:
OjpmZmZmxxxxxxxxxxxxxxxx  is ::ffff:xxx.xxx.xxx.xxx

In https://bugzilla.redhat.com/show_bug.cgi?id=213626 I was told to try
the "nsslapd-listenhost: ::ffff:N.N.N.N" notation which worked fine for me in the past.

the ldap proxy is configured to listen on xxx.xxx.xxx.yyy (the ip address of <fqdn>) by:
exec /usr/sbin/slapd -d 256 -f /etc/openldap/slapd.conf -h "ldap://<fqdn>/ ldaps://<fqdn>/" -u ldap

(xxx.xxx.xxx.yyy is bound to eth0:0 by heartbeat)

Comment 6 Rich Megginson 2009-10-02 21:11:41 UTC
So nothing really contacts the 389 directory server directly, everything goes through the openldap proxy?

Comment 7 Dirk Husung 2009-10-05 10:32:40 UTC
Most of our applications go through the ldap proxy, but not everything:

Our e-learning platform e.g. allows to configure more than one ldap server, but it takes at least 180 seconds (network protocol timeout) until the second one is tried if the first one is unreachable - inacceptable. So we've configured the e-learning platform to use the proxy; several other applications as well.

On the other hand we have a web application to look up contact information of employees and to allow an employee to change certain data of his/her own in the ldap. This is a self written application that can test which of our 389 directory servers is up and running. 
Because we need some business logic, we restrict write access to the machines hosting the web application. As access writes are enforced on the 389 directory server, not the OpenLDAP proxy, we cannot go through the proxy in this case
(the 389 directory server would see the proxy as the connecting client).

So we offer direct access to the 389 directory server and access via a proxy, but in any case we want to make shure (per firewall) that simple bind operations are possible only via encrypted connections to port 636 (and may be to localhost:389).

Comment 8 Rich Megginson 2009-10-06 17:03:06 UTC
I'm just trying to figure out if this is IPv6 related - the directory server listen address is the IPv6 one:
tcp    0  0 ::ffff:        :::*                        LISTEN      
tcp    0  0 ::ffff:xxx.xxx.xxx.xxx:636  :::*                        LISTEN   

Note that the directory server is only listening to so won't be available for connection from other machines on port 389 - looks like it is listening on a "real" IP address for port 636, so you can access that port from other machines.

Comment 9 Dirk Husung 2009-10-07 12:33:29 UTC
As I wrote in the very beginning of ths thread I would like to
access the "Directory Server" on the same machine from within 389-console.
I would like to do that via localhost.

In the Admin Server Console under Configure Admin Server UserDS 
"Use Default User Directory" is selected, which is reported as:

Nevertheless wireshark shows, that accessing the Administration Server uses localhost, while accessing the Directory Server uses the machines ip address.

May be my configuration isn't correct (though it worked under fedora-ds).
How do I have to configure that "Directory Server" is connected via localhost from within 389-console?

Thanks in advance.

Comment 11 Nathan Kinder 2011-03-08 17:43:49 UTC
I am unable to reproduce this issue using the current 389 package versions.  I am able to set nsslapd-listenhost to "::ffff:" and connect using Console just fine.

I think the initial problem may have had something to do with the hostname provided to setup-ds-admin.pl when the instances were created, or possibly something with the hosts file.  The Console determines how to contact the Directory Server instance that you open from data in "o=NetscapeRoot" in the configuration DS.  Perhaps this data has a hostname that resolves to the IP address, or has the IP address itself.

Do you still have the system available that has this problem?  I would like to know what the "serverhostname" attribute is for your host entry in "o=NetscapeRoot".  This entry will be named something like "cn=<host>,"ou=<config domain>,o=NetscapeRoot".  I would also like to know if that hostname resolves to your actual IP address instead of the loopback address.  I believe that this is where the problem is on your system, but I'd like to verify that before closing this bug report.

Comment 12 Nathan Kinder 2011-03-11 20:46:36 UTC
Closing this as WORKSFORME.  If there is still an issue, please reopen this bug report.

Note You need to log in before you can comment on or make changes to this bug.