Fedora directory users - Jul 2006 - Re: Fedora DS 1.0.2 Multiple Master SSL replication: empty bind DN...

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,dcco,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@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@redhat.com>
Message-ID: <44A51838.4040409@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

Kevin McCarthy wrote:
> 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"?
>   
Actually, the method is SASL/EXTERNAL, which means the BIND identity 
comes from somewhere else (in this case, the certificate).  So, dn=""
is
ignored since it is obtained from the certificate.
>
> 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
>   
All of this means that you are definitely doing client cert auth.  You 
say that the entry cn=nema2,ou=EDS,o=teligent,dc=co,c=uk exists on both 
servers (and cn=nema1 or cn=nema also)?  And you have this DN listed in 
the supplier DN in the replica configuration?  If so, then it could be 
that replication does not allow you to specify a supplier DN that lives 
in the replicated area.  What we usually recommend is that you create a 
replication pseudo user in the configuration naming context e.g.
dn: cn=repluser, cn=config
objectclass: person
sn: repluser
cn: repluser
userPassword: password

Then configure cert mapping to map the subjectDN in the cert to this 
user.  To make certmapping work, you may have to name the replication 
pseudo user something like cn=nema or cn=nema2 so you can use the 
attributes in the cert subjectDN to map to the pseudo user.  Then you 
will need to have the pseudo user DN as the supplier DN in the replica 
configuration.
> [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@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@redhat.com>
> Message-ID: <44A51838.4040409@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
>>     
>
>
>

Hi Richard,

Thanks, the addition of the cn=config replication entry did indeed allow the
replication to commence between both servers and the additions/deletions of
new user entries were fairly quickly propagated to the other server.

Regards,
Kevin


-----Original Message-----
From: Richard Megginson [mailto:rmeggins@redhat.com] 
Sent: 03 July 2006 15:26
To: Kevin McCarthy
Cc: fedora-directory-users@redhat.com
Subject: Re: [Fedora-directory-users] Fedora DS 1.0.2 Multiple Master SSL
replication: empty bind DN...

Kevin McCarthy wrote:
> 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"?
>   
Actually, the method is SASL/EXTERNAL, which means the BIND identity 
comes from somewhere else (in this case, the certificate).  So, dn=""
is
ignored since it is obtained from the certificate.
>
> 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
>   
All of this means that you are definitely doing client cert auth.  You 
say that the entry cn=nema2,ou=EDS,o=teligent,dc=co,c=uk exists on both 
servers (and cn=nema1 or cn=nema also)?  And you have this DN listed in 
the supplier DN in the replica configuration?  If so, then it could be 
that replication does not allow you to specify a supplier DN that lives 
in the replicated area.  What we usually recommend is that you create a 
replication pseudo user in the configuration naming context e.g.
dn: cn=repluser, cn=config
objectclass: person
sn: repluser
cn: repluser
userPassword: password

Then configure cert mapping to map the subjectDN in the cert to this 
user.  To make certmapping work, you may have to name the replication 
pseudo user something like cn=nema or cn=nema2 so you can use the 
attributes in the cert subjectDN to map to the pseudo user.  Then you 
will need to have the pseudo user DN as the supplier DN in the replica 
configuration.
> [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@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@redhat.com>
> Message-ID: <44A51838.4040409@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
>>     
>
>
>