Richard, thank you for your response!
.hopefully whatever configuration mistake I made to cause a NULL bind DN
will soon come to light.
Dear List Members,
A typical replication error log entry now follows (seen repeatedly at
both fedora DS servers):
[28/Jun/2006:18:29:21 +0100] NSMMReplicationPlugin -
server 2" (ukstatlap:636): Unable to acquire replica: permission
denied. The *bind dn ""* does not have permission to supply
replication updates to the replica. Will retry later.
Believe me, I have been investigating this one for 2 or 3 days now
(having just switched from OpenLDAP, since multiple master
is required) before sending this submission, just in case I missed a
configuration item or work-around, but unfortunately no luck (so
The only reference I can find for SSL Client Authentication based
Multiple Master replication (2 Linux RHEL 3 servers being used) that
supplies empty DNs, is the Windows specific entry (whose work-around
tried anyway, but without success)_
Unable to acquire replica: permission denied. The bind dn
"" does not
have permission to supply replication updates to the replica. Will
To workaround the problem, after you modify and save the replication
schedule of an agreement, refresh the console, reconfigure the
connection settings (to SSL client authentication) for the agreement,
and save your changes.
The mutual _Current Supplier DNs_ are indeed set (cn=Replication
Manager,cn=replication,cn=config) and the corresponding directory
entries do exist.
The respective server certificates and CA certificates are installed,
with Subject DN entries loaded.
What are the SubjectDNs in the server certificates?
.where "<SERVERNAME>" is the respective server name of the replicating
servers e.g. "nema2" rather than a full domain name.
The following will hopefully also be relevant:
1) The tree being replicated is "OU=EDS,O=Teligent,DC=co,C=uk" i.e. the
Subject DN is within the replicated tree.
2) certutil was used to generate the server and CA certificates.
Surprisingly (to me at least) the CA certificate was then listed in the
"Server Certs" panel on the Directory Server "Manage Certificates"
3) I loaded the ascii version of the "other" server's CA Certificate
directly into the "CA Certs" panel.
4) All CA certificates have both the accept and make connection trusts
I do _not_ have Legacy Consumer enabled.
You don't need it.
CertMapping is also defined (though with a NULL DN being supplied, I
guess that will not be kicking in just yet, though there are entries
for the exact subject DN anyway.)
You might want to post your certmap.conf and see here -
.I must admit that since the Bind DN was NULL I had not realized that
certmap'ping would actually take affect.
I ensured that the exact subject DN of the server certificates corresponded
to an actual directory entry (with the respective server's user certificate
loaded), which I had thought would be matched without the need for a certmap
configuration via the original "default" option, but I tried one anyway.
certmap nema ou=EDS,o=teligent,dc=co,c=uk
certmap default default
.indeed one server still runs with the default certmap configuration to see
if it made any difference, but both servers receive a NULL bind DN "".
When using simple authentication, with or without SSL, all is well
(although replication did require both servers to Initialize the
Consumer, I thought that only one was required e.g. ID 1 initializing
ID 2, but ID 2 then needed to initialize ID 1 before successful 2-way
replication was achieved).
That's odd. You should only need to initialize once one way.
.indeed, but I guess that it can not do any harm, as the secondary server
will not actually need to supply any further updates back to the primary
server and it does at least make the mutual replication work for me - until
the certificates took their toll.
Regards and thanks again,