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: > > 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. > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060630/aedb9c02/attachment.bin
