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-126.96.36.199-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-188.8.131.52-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 184.108.40.206
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 220.127.116.11
* 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 18.104.22.168
* 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-22.214.171.124-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
I have multimaster replication set up on 4 LDAP servers but can't get
secure replication working on one of the servers. The setup is like this
data center 1 data center 2
ldap1 <-------> ldap1
^ | ^ |
/ | | |
| v | v
each server has its own self-signed cert.
I can successfully replicate in all the directions indicated except for
replication from data center1 ldap2 to data center1 ldap1.
I know that I have the right certificate on ldap2. I can ldapsearch -ZZ
from ldap2 to ldap1 successfully using this certificate. I can
successfully replicate from data center 2 ldap1 to data center1 ldap1
using this certificate. But replication refuses to work from DC1 ldap2 to
The logs say LDAP error: Can't contact LDAP server. Error Code: -1.
I've disabled iptables on both data center 1 ldaps. I've rebuilt the
replication agreement a dozen times. I've ldapsearch -zz'ed a dozen times.
I've reinstalled the CA certificate (using the one from my openldap
directory, so I know that it is the same one that is working for
ldapsearch -ZZ, as well as exporting it from ldap1 again and reinstalling
it). What else can I possibly do to get this working?
These are my rpms -
# rpm -qa | grep 389
# uname -a
Linux dc1-ldap2 2.6.32-431.5.1.el6.x86_64