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.
How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
CentOS release 6.3 (Final)
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
06/04/2013 12:39 PM, Denise Cosso wrote:
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
389 users mailing list
I got 389 running on a remote linux box,and I would like to get use of
the Console without the need of exporting the X-Windows whenever I want
to make a change as I also would prefer not to keep tweaking the
configuration files all the time.
is there anyway of doing this through any remote client?
Any advise on this matter?
Thanks very much
Need to configure sasl mecanism so that i can use DIGEST-MD5 mechanism with
my autofs configuration. With PLAIN it is working fine but need to use
DIGEST-MD5. Where i can specify.
[root@ibm001 ~]# cat /etc/autofs_ldap_auth.conf
<?xml version="1.0" ?>
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
Thanks & Regards
Dhiraj S. Deshpande
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
We are pleased to announce the launch of our new wiki
The site has been significantly revised, and moved to a more stable
environment. The layout, content, and organization has all been
improved. Please note, you will need to revise any old bookmarks you
may have, as the old ones will probably not work anymore.
Also, if you would like to add/edit content on the site you just need to
file a ticket <https://fedorahosted.org/389/newticket> (use "wiki" as
the component), add your content(preferably in MarkDown format, but not
required), and we will post it.
389 Project Team
Cannot find the 389-ds-base-22.214.171.124-1 for RHEL5 in any repos, am I missing it or is it not being supported or built for 5? Most recent seems to be 389-ds-base-126.96.36.199-1 on Epel for EL5 (5.10)? Thanks.
This electronic message transmission contains information from Black Hills Corporation, its affiliate or subsidiary, which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware the disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic transmission in error, please reply to sender immediately; then delete this message without copying it or further reading.
389 Directory Server 188.8.131.52
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available from the Fedora 20 and Rawhide repositories.
The new packages and versions are:
A source tarball is available for download at Download Source
Highlights in 184.108.40.206
* Various bugs were fixed.
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* to update your directory server/admin
server/console information. setup-ds-admin.pl -u
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
If you find a bug, or would like to see a new feature, file it in our
Trac instance: https://fedorahosted.org/389
Detailed Changelog since 220.127.116.11
* Ticket 346 - Fixing memory leaks
* Ticket 47446 - logconv.pl memory continually grows
* Ticket 47692 - single valued attribute replicated ADD does not work
* Ticket 47753 - Add switch to disable pre-hashed password checking
* Ticket 47781 - Server deadlock if online import started while server
is under load
* Ticket 47797 - DB deadlock when two threads (on separated backend)
try to record changes in retroCL
* Ticket 47797 - fix the indentation
* Ticket 47816 - v2- internal syncrepl searches are flagged as unindexed
* Ticket 47824 - paged results control is not working in some cases
when we have a subsuffix.
* Ticket 47834 - Tombstone_to_glue: if parents are also converted to
glue, the target entry’s DN must be adjusted.
* Ticket 47858 - Internal searches using
OP_FLAG_REVERSE_CANDIDATE_ORDER can crash the server
* Ticket 47861 - Certain schema files are not replaced during upgrade
* Ticket 47862 - Repl-monitor.pl ignores the provided connection
* Ticket 47862 - repl-monitor fails to convert “*” to default values
* Ticket 47866 - Errors after upgrading related to attribute
* Ticket 47869 - unauthenticated information disclosure (Bug 1123477)
* Ticket 47871 - 389-ds-base-18.104.22.168-1.fc20 crashed over the weekend
* Ticket 47872 - Filter AND with only one clause should be optimized
* Ticket 47874 - Performance degradation with scope ONE after some load
* Ticket 47875 - dirsrv not running with old openldap
* Ticket 47877 - check_and_add_entry fails for changetype: add and