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.
We have been using 389-ds as part of FreeIPA. In one of our environments,
we have 2 389-ds installations with replication.
Randomly, the 389-ds on either of them completely freezes and there are
high number of CLOSE_WAITs on tcp/389 port.
Only way to recover from this situation is to either reboot or "kill -9"
the ns-slapd process. Graceful restarts get stuck indefinitely.
One curious thing when this happens, a search using "ldapsearch" command
seems to work but a search using a python-ldap client does not. FreeIPA
does not work either.
Any pointers on troubleshooting this would be appreciated.
The scenario is simple: we have a subtree in the DIT with a few thousand
children node. The parent node of the subtree has a few acis including a
couple of macro acis that apply to each of the child nodes. We've
observed a significant performance degradation when trying to list all
the children in the presence of the macro acis.
Profiling on the client code show that although the first few child
nodes were fetched quite fast there is a clear delay buildup as the
retrieval progresses. The buildup is not present when the macro acis are
removed. Also, it is faster to split the list in chunks and retrieve
Is it possible that as the macro acis are resolved they are added to the
list of acis of the parent node so that the last nodes are evaluated
against many more acis than the first ones and hence the observed delay
in their retrieval? Is there a workaround for this?
I have a curious situation with our LDAP ecosystem at work. I have 2 LDAP
hosts in one data center (one is a replication supplier, one is a consumer)
and 1 consumer host in a separate data center(DC-B).
The issue is expired users can still successfully authenticate against the
consumer host DC-B, even though LDAP shows that the password is expired.
I've compiled outputs from each host into the following paste:
We are using an old version of 389-ds (as you can see from the paste),
version 188.8.131.52, and as far as I can tell (i'm a relative LDAP neophyte)
our configuration and replication properties are as expected, but I'm not
sure if there might be a permissions issue, some other issue, or a bug in
the old version we're using.
What else should I check next?
On a large 389 implementation - where downtime is not an option - are there
pros/cons to having the KDC on same server as 389 (sharing the database) -
or having the KDC on separate, redundant, servers?
I deleted my root suffix, and now, in the admin console, I can't recreate
the suffix, tells me it already exists.
Any ideas what file I can go edit to clean up any orphaned references to it
I have recycled the server, I have done a restore from backup.
I have multiple domain in my scenario, for that i have configure virtual
I require open-source web-console for creation user. 389-console is not
According to requirement, if i create any user for one domain, for other
domain same should be create as i press submit button.
Have their any solution..
*Keen & Able Comp. Pvt. ltd.*
we are trying to understand are performance issues and start
investigating the ACI's and indexes , I need to know if all "default
indexes" showing in 389-console admin are necessary beside the one which
we create for our application requirement :
- there are a 1/2 dozen of default indexes which are were there with DS
mailalternateAddress, ntUserDomain, ntUserDomainid,
seeAlso,numsubordinates etc... Can we just go an remove this indexes
from DS ( using admin console?) , are they been used internally by
-Is there a way to export all indexes in ldif file same we are doing
with ACI's , how?
We are seeing running a ldapsearc cmd line for count of groups ( 7000
entries with memberOf plugin enabled) takes aprox 17-18 sec with server
cfg fro multimaster replication and this is not acceptable by our users.
we are running 389DS version with OS :Linux proc5-02
2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 x86_64 x86_64
What is the recommended way to remove a database with the following
Would it be simply stopping slapd, remove the path and start slapd?