When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
> Maybe I am understanding this wrong but could you not just check in
> the config what the search base is set to on the client side? What is
> the problem you are trying to solve?
yes, you're right. i can just take a look at ldap.conf but there's several places to look:
- debian/ubuntu uses /etc/ldap/ldap.conf
- RHEL/CentOS uses /etc/openldap/ldap.conf
- custom compilations can use any path. ex: /usr/local/ldap/ldap.conf
- windows openldap uses... i don't really know :P
so what im trying to do is resolving configured base without knowing anything about the client.
for example, this command gives me the server even if i dont know anything about the conf:
ldapsearch -d1 -x -LLL "(uid=example)" uid 2>&1 | grep ldap_connect_to_host
im just a little bit surprised that i can't find any debuglevel that gives me the BASE
I'm having problems trying to get a clean install of 220.127.116.11 working. We're running RHEL5 and I have the EPEL5.4 repositories configured on it. Yum installed the following when I installed 389-ds:
389-admin.x86_64 1.1.13-1.el5 installed
389-admin-console.noarch 1.1.5-1.el5 installed
389-admin-console-doc.noarch 1.1.5-1.el5 installed
389-adminutil.x86_64 1.1.8-4.el5 installed
389-console.noarch 1.1.4-1.el5 installed
389-ds.noarch 1.2.1-1.el5 installed
389-ds-base.x86_64 18.104.22.168-1.el5 installed
389-ds-base-devel.x86_64 22.214.171.124-1.el5 installed
389-ds-console.noarch 1.2.3-1.el5 installed
389-ds-console-doc.noarch 1.2.3-1.el5 installed
389-dsgw.x86_64 1.1.5-1.el5 installed
idm-console-framework.noarch 1.1.5-4.el5 installed
After installation, I ran /usr/sbin/setup-ds-admin.pl to set up the initial configuration. Immediately after that, if I run 389-console, login as "cn=Directory Manager", navigate to "Directory Server" window and then try to open the "Configuration" tab, I get a dialog box that says: "Insufficient Permissions / The user cn=Directory Manager does not have permission to perform this operation.". Clicking the OK button gets me a new login window, but re-entering the Directory Manager credentials doesn't do anything. All I get is a blank page instead of what's supposed to be under the Configuration tab.
I've done the install a few times already to make sure I wasn't messing things up. There's nothing out of the ordinary in either the admin server error log or the directory server error log. The directory server access log shows only a few err=32, all under "ou=Global Preferences", which is probably expected on a completely new install.
The terminal window I ran 389-console shows a java stack trace, but only after I click past the error dialog box:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at com.netscape.admin.dirserv.panel.ServerSettingsPanel$ReferralText.show(Unknown Source)
at com.netscape.admin.dirserv.panel.DSEntrySet.getAttributes(Unknown Source)
at com.netscape.admin.dirserv.panel.DSEntrySet.show(Unknown Source)
at com.netscape.admin.dirserv.panel.BlankPanel.refresh(Unknown Source)
at com.netscape.admin.dirserv.panel.BlankPanel.select(Unknown Source)
at com.netscape.admin.dirserv.panel.ContainerPanel.stateChanged(Unknown Source)
at com.netscape.admin.dirserv.panel.DSTabbedPanel.addTab(Unknown Source)
at com.netscape.admin.dirserv.panel.RootPanel.<init>(Unknown Source)
at com.netscape.admin.dirserv.node.RootResourceObject.getCustomPanel(Unknown Source)
at com.netscape.management.client.ResourceModel.getCustomPanel(Unknown Source)
at com.netscape.management.client.ResourcePage.valueChanged(Unknown Source)
at com.netscape.management.client.ResourcePage.pageSelected(Unknown Source)
at com.netscape.admin.dirserv.DSResourcePage.pageSelected(Unknown Source)
at com.netscape.management.client.Framework$TabChangeListener.stateChanged(Unknown Source)
If i am reading the code correctly (and looking at the logging below), the
line that has a severity of 'crit' should dump info for the ldap server we
are connecting to.
In my case (and Eric's too) only 'ldap://:389' is printed; sometimes even
with an odd number like 23395496 (see Eric's first post).
[Tue Nov 30 22:01:43 2010] [crit] openLDAPConnection(): util_ldap_init
failed for ldap://:389
[Tue Nov 30 22:01:43 2010] [warn] Unable to open initial LDAPConnection to
populate LocalAdmin tasks into cache.
[Tue Nov 30 22:01:44 2010] [notice] Apache/2.2.17 (Unix) configured --
resuming normal operations
[Tue Nov 30 22:01:44 2010] [crit] openLDAPConnection(): util_ldap_init
failed for ldap://:389
[Tue Nov 30 22:01:44 2010] [warn] Unable to open initial LDAPConnection to
populate LocalAdmin tasks into cache.
The code that logs this error looks like this [mod_admserv/mod_admserv.c:517]
ap_log_error(APLOG_MARK, APLOG_CRIT, 0 /* status */, NULL,
"openLDAPConnection(): util_ldap_init failed for
data->secure ? "s" : "",
It seems that the struct 'data' is not filled with the correct values.
BTW. this code was taken from 389-admin-1.1.12.a2
I hope this helps,
I am trying to setup a test environment where each database should
contain multiple suffixes. I have 6 organizations:
a1 and a2, should belong to userRoot, which is "mastered" in server1,
b1 and b2 should belog to database px02, which is mastered in server2,
and so with c1 and c2. Is this possible to do? I am trying to do it,
creating a new sub-suffix b1, allowing the console to autocreate
database px02. Then I create a new sub-suffix b2, without creating any
database. Then, i try to assing the database px02 previously created,
but i get an error in the console, and in the logs: "ERROR: backend
px_02 is already pointed to by a mapping tree node. Only one mapping
tree node can point to a backend", so I think this is not possible.
CentOS 5.5 + 389-ds-base-126.96.36.199-2.el5
I have a simple question i guess... How do i find out wich character encoding
it's been in my DS(utf-8,latin1, etc..)?
Francisco José Pérez González
CCNA Exploration Netacad V 4.0 Pass
I setup 389-ds from scratch today on a CentOS box - simple "yum -y install
389-ds", then ran the setup script with default options. I then restarted
the server and connected with the 389 console. I'm running
The console loads fine. I'm able to do most things. However, when I
click the + sign next to "Server Group" on the initial screen, I get the
following in my terminal:
at com.netscape.admin.dirserv.DSUtil.<clinit>(Unknown Source)
at com.netscape.admin.dirserv.DSAdmin.initialize(Unknown Source)
Furthermore, when I double click on directory server and hit the
"Configuration" tab, I get a permission denied (logged in as admin...) and
I'm asked to re-authenticate. If I hit cancel, things continue to work as
normal, so that isn't a huge deal. However, if I hit "Manage
Certificates", nothing happens. This is not the case when hitting
"Manange Certificates" inside the Admin Server window.
I'm experiencing the exact same problem that was experienced in the second
part of this thread:
http://www.spinics.net/lists/fedora-directory/msg12552.html (scroll down
to the bottom and look for the text "When i enter the correct credentials,
it seems that everything is"). There was never a resolution posted to
Please let me know if anyone has any ideas. Re-authenticating isn't a big
deal once I open up the Directory Server window, but this is stopping me
from setting up SSL on the directory through the console.
Recently i have setup 389 DS on my CentOS machine.Now yesterday i m able to
reset user's password. Now i m not able to reset it....
I have checked my directory server's setting and found that i have
mistakenly set "disallow_pw_change_aci" ACL. Now i have deleted this one.
But whenever i restart my dirsrv and dirsrv-admin services i see
"disallow_pw_change_aci" ACL again in my directory server.
Que.1 Now how to remove parmanently ?
And secondly when i remove this from directory server and then try to change
password i am getting below error:-
LDAP password information update failed: Server is unwilling to perform
user is not allowed to change password
passwd: Permission denied
Que.2 Now how to sort out this one... ?
Que.3 And one more question is, where i will find all these logs...if
someone file these command at client as well as server machine(i.e.
ldapsearch, ldapadd, ldapdelete, passwd, passwd lock etc...)
I have two DS. Replication configured and working (userRoot only,
NetscapeRoot comming soon). I don't understand how to register the DS
against the Admin server of each other. I want to manage the
configuration of both servers on both Admin servers. The
documentations talks about register-ds-admin.pl but doesn't work. It
looks like the server is trying to register against the local Admin.
What am I missing?
Occasionally I see the following messages when I start the 389DS.
<timestamp> attrcrypt_unwrap_key: failed to unwrap key for cipher AES
<timestamp> Failed to retrieve key for cipher AES in attrcrypt_cipher_init
<timestamp> Failed to initialize cipher AES in attrcrypt_init
<timestamp> attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES
<timestamp> Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init
<timestamp> Failed to initialize cipher 3DES in attrcrypt_init
Can someone tell me what went wrong there? It looks like these messages are
harmless because 389DS still started up successfully and able to process all