Thanks again Richard, My attempt to determine why the bind DN remains as "" have still not located the cause - though I guess that is due to this being my first usage and I have merely missed the obvious! > 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 can see from the bind result that the initial "dn" is still the required: "cn=nema2,ou=EDS,o=teligent,dc=co,c=uk" ..but the BIND dn remains as "", with the method as "sasl"? Consumer Access log file extract: [03/Jul/2006:10:24:11 +0100] conn=11 fd=67 slot=67 SSL connection from 192.168.27.15 to 192.168.144.61 [03/Jul/2006:10:24:11 +0100] conn=11 SSL 256-bit AES; client CN=nema2,OU=EDS,O=teligent,DC=co,C=uk; issuer CN=CAcertnema2 [03/Jul/2006:10:24:11 +0100] conn=11 SSL client bound as cn=nema2,ou=EDS,o=teligent,dc=co,c=uk [03/Jul/2006:10:24:11 +0100] conn=11 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [03/Jul/2006:10:24:11 +0100] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=nema2,ou=EDS,o=teligent,dc=co,c=uk" [03/Jul/2006:10:24:11 +0100] conn=11 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [03/Jul/2006:10:24:11 +0100] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [03/Jul/2006:10:24:11 +0100] conn=11 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [03/Jul/2006:10:24:11 +0100] conn=11 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [03/Jul/2006:10:24:11 +0100] conn=11 op=3 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:11 +0100] conn=11 op=3 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:12 +0100] conn=11 op=4 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:12 +0100] conn=11 op=4 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:15 +0100] conn=11 op=5 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:15 +0100] conn=11 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:19 +0100] conn=11 op=6 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:19 +0100] conn=11 op=6 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:28 +0100] conn=11 op=8 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:28 +0100] conn=11 op=8 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:24:34 +0100] conn=10 op=4 UNBIND [03/Jul/2006:10:24:34 +0100] conn=10 op=4 fd=64 closed - U1 [03/Jul/2006:10:24:46 +0100] conn=11 op=10 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [03/Jul/2006:10:24:46 +0100] conn=11 op=10 RESULT err=0 tag=120 nentries=0 etime=0 [03/Jul/2006:10:25:08 +0100] conn=11 op=12 UNBIND [03/Jul/2006:10:25:08 +0100] conn=11 op=12 fd=67 closed - U1 Consumer Error log file extract: [03/Jul/2006:10:24:11 +0100] NSMMReplicationPlugin - conn=11 op=3 replica="ou=EDS,o=teligent,dc= co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:12 +0100] NSMMReplicationPlugin - conn=11 op=4 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:15 +0100] NSMMReplicationPlugin - conn=11 op=5 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:19 +0100] NSMMReplicationPlugin - conn=11 op=6 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:28 +0100] NSMMReplicationPlugin - conn=11 op=8 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:46 +0100] NSMMReplicationPlugin - conn=11 op=10 replica="ou=EDS,o=teligent,dc=co,c=uk": Unable to acquire replica: error: permission denied [03/Jul/2006:10:24:50 +0100] NSMMReplicationPlugin - agmt="cn=EDS from Server 1" (nema2:636): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. Regards and thanks again, Kevin From: Richard Megginson <rmeggins at redhat.com> Subject: Re: Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN... To: "General discussion list for the Fedora Directory server project." <fedora-directory-users at redhat.com> Message-ID: <44A51838.4040409 at redhat.com> Content-Type: text/plain; charset="windows-1252" 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 servers 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 > certmapping 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. ...log file extract at the head. > > I ensured that the exact subject DN of the server certificates > corresponded to an actual directory entry (with the respective > servers 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. ...indeed, just the one. > > 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. ...extracts at the head. > > > 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
