[Fedora-directory-users] Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN...

Fri Jun 30 12:25:28 UTC 2006

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>