Re: [Fedora-directory-users] Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN...
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,
Release: *fedora-ds-1.0.2-1.RHEL3.i386.opt.rpm*
A typical replication error log entry now follows (seen repeatedly at
both fedora DS servers):
[28/Jun/2006:18:29:21 +0100] NSMMReplicationPlugin - agmt="cn=EDS from
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 replication
is required) before sending this submission, just in case I missed a
configuration item or work-around, but unfortunately no luck (so far).
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 I
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
retry later.
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.
http://www.redhat.com/docs/manuals/dir-server/release-notes/ds611relno
tes.html
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?
CN=<SERVERNAME>,OU=EDS,O=teligent,DC=co,C=uk
.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" panel.
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 ticked.
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 - http://directory.fedora.redhat.com/wiki/Howto:CertMapping
.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
nema:FilterComps cn
nema:verifycert off
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,
Kevin
Kevin McCarthy wrote:
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,
Release: *fedora-ds-1.0.2-1.RHEL3.i386.opt.rpm*
A typical replication error log entry now follows (seen repeatedly at
both fedora DS servers):
[28/Jun/2006:18:29:21 +0100] NSMMReplicationPlugin - agmt="cn=EDS from
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 replication
is required) before sending this submission, just in case I missed a
configuration item or work-around, but unfortunately no luck (so far).
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 I
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
retry later.
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.
http://www.redhat.com/docs/manuals/dir-server/release-notes/ds611relno
tes.html
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?
CN=<SERVERNAME>,OU=EDS,O=teligent,DC=co,C=uk
…where “<SERVERNAME>” is the respective server name of the replicating servers e.g. “nema2” rather than a full domain name.
I think this is ok, as long as your DNS (/etc/resolv.conf) configuration can resolve nema2.
The following will hopefully also be relevant:
- The tree being replicated is “OU=EDS,O=Teligent,DC=co,C=uk” i.e.
the Subject DN is within the replicated tree.
- 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” panel.
- I loaded the ascii version of the “other” server’s CA Certificate
directly into the “CA Certs” panel.
- All CA certificates have both the accept and make connection trusts
ticked.
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 - http://directory.fedora.redhat.com/wiki/Howto:CertMapping
…I must admit that since the Bind DN was NULL I had not realized that certmap’ping would actually take affect.
If you are using client cert based auth (and not just username/password auth with SSL) then certmapping will be used. To ensure that you are doing client cert auth, you can examine the access log on the replication consumer - look for the connection and BIND from the supplier. If you're not sure what you're looking at, just post the relevant excerpts here.
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
I think this DN should correspond to the issuerDN (i.e. the subjectDN of your CA cert). But I don't think it's used for cert mapping.
nema:FilterComps cn
This means you must have one and only one entry called cn=nema2, ....., o=teligent,dc=co,c=uk somewhere in your tree.
nema:verifycert off
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 “”.
This leads me to believe it is not doing client cert auth. Also check the errors log for your supplier and consumer.
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,
Kevin
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
389-users@lists.fedoraproject.org
-
Kevin McCarthy -
Rich Megginson