Thank you Rich!
Jovan Vukotić • Senior Software Engineer • Ambit Treasury Management • SunGard • Banking •
Bulevar Milutina Milankovića 136b, Belgrade, Serbia • tel: +381.11.6555-66-1 •
jovan.vukotic@sungard.com<mailto:jovan.vukotic@sungard.com>
Join the online conversation with SunGard’s customers, partners and Industry experts and
find an event near you at:
www.sungard.com/ten<http://www.capitalize-on-change.com/?email=7015000...;.
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Friday, June 21, 2013 5:29 PM
To: General discussion list for the 389 Directory server project.
Cc: Vukotic, Jovan; Mehta, Cyrus
Subject: Re: [389-users] DES hash values in replicationAgreement with Simple Bind
On 06/21/2013 08:56 AM, Jovan.VUKOTIC@sungard.com<mailto:Jovan.VUKOTIC@sungard.com>
wrote:
Hi,
We have four 389 DS masters, version 1.2.11 that we are organizing in multi-master
replication topology.
On one host we do not have admin server and consequently do not have an option to use 389
Management Console to configure replication agreements.
I configured it from the command line as per Administration Guide( replication manager,
changelog, supplier replica and replication agreements entries), but could not establish
connection to neither servers from the Agreement due to Invalid credentials error (49).
I suspect the problem is DES hash of
nsDS5ReplicaCredentials
attribute value.
I copied it from another Replication Agreement from the other DS instance pointing to the
same Multi-Master replica.
You can't do that.
That replication Agreement was created in 389 Console and worked fine (i.e. replica got
acquired). Hence, I thought since the replication manager entry is the same, copied DES
hash would be OK.
It did not work.
Right, you can't do that.
Furthermore, when compared with the DES hash created for that very replication manager
entry on the third server( again via 389 Console, just for the sake of the test) it
turned out to be different.
Do you know any command analog to pwdhash that can generate hash in DES format?
No.
If not, how then to provide nsDS5ReplicaCredentials attribute value of replication
agreement entry?
ldapmodify:
ldapmodify ... <<EOF
dn:
cn=rAgrmnt1,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn
=config
changetype: modify
replace: nsDS5ReplicaCredentials
nsDS5ReplicaCredentials: the new clear text password
EOF
FY reference, I used the following entry to do create Replication agreement:
dn: cn=rAgrmnt1,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn
=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
description: inst1 supplies inst2
cn: rAgrmnt1
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost:
consumer.replica.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: uid=ReplManager,cn=config
nsDS5ReplicaTransportInfo: TLS
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: {DES}secret //copied from another servers dse.ldif file,
from its agreement with the same nsDS5ReplicaHost
I will appreciate any help.
Thank you
Jovan Vukotić • Senior Software Engineer • Ambit Treasury Management • SunGard • Banking •
Bulevar Milutina Milankovića 136b, Belgrade, Serbia • tel: +381.11.6555-66-1 •
jovan.vukotic@sungard.com<mailto:jovan.vukotic@sungard.com>
[Description: Description: Description: Description: Description:
coc-signature-03-2012]<http://www.capitalize-on-change.com/?email=7015...
Join the online conversation with SunGard’s customers, partners and Industry experts and
find an event near you at:
www.sungard.com/ten<http://www.capitalize-on-change.com/?email=7015000...;.
--
389 users mailing list
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users