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

[Kevin McCarthy]

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-directory-users] 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