Brian Peters wrote:
Hi all,
I'm having problems setting up a Windows Sync Agreement in the FDS.
Here's the situation:
I've set up my Active Directory server on a Windows 2000 Server box
with an SSL connection using a self-signed cert. I then installed FDS
on a Fedora Core 3 box and set that up with an SSL connection, again
using a self-signed cert. I installed the AD cert into the FDS
database with trusted peer status. These machines are on the same
network with no firewalls or anything in between.
I tested out the connection using ldapsearch on the FDS box using
simple authentication over SSL, and I was able to query the Active
Directory perfectly fine.
The next step was to set up the Windows Sync Agreement. You have to
turn on changelog and replication first, so I did so, choosing Single
Master replication. In the Windows Sync Agreement wizard, I filled in
all the fields and saved the agreement.
When the replicator fired up, all the Active Directory entries sync'ed
perfectly fine with the FDS server (i.e. I was able to query FDS and
see the sync'ed AD entries). The problem was that the status of the
Windows sync showed that it was still syncing. So basically, it
wouldn't attempt to sync again and the server wouldn't shut down
cleanly because it thought it was still syncing. I tried setting up
Windows sync over the non-SSL port, and it works perfectly fine.
So, I did some digging into this and this is what I was able to
determine. After the sync begins, I took a look at netstat on both
the FDS and AD servers, and it showed an ESTABLISHED connection
between a random port on FDS and the ldaps port on AD. The connection
stayed ESTABLISHED for about 15 minutes (keep in mind that it took
seconds to actually do the sync). After 15 minutes, the AD side
showed a socket state of FIN_WAIT_2 and the FDS side went to
CLOSE_WAIT. After a couple more minutes, the socket connection
disappeared from the AD side, but the FDS side stayed in CLOSE_WAIT.
I think the longest I let it sit was just over an hour or so, and
neither the sync status in FDS nor the socket state changed.
I also took a look at a tcpdump of the AD sync from the FDS machine,
which showed a normal-looking transfer, but the first FIN,ACK was
issued by the AD machine 15 minutes after the initial connection.
Comparing this to a tcpdump of an ldapsearch, the first first FIN,ACK
is sent from the FDS box, which is followed by a FIN,ACK from the AD,
and so on. So, it seems that the AD side is expecting a FIN,ACK, but
after 15 minutes it gives up waiting, sends a FIN,ACK and gets out of
there.
I'm basically stuck at this point, and just wondering if anyone else
has seen this behavior and/or has any suggestions. Thanks in advance.
This certainly sounds strange. I think you did one thing wrong in the
config though:
I think you need to enable multi-master replication for windows sync to work
properly. At least that's how it was designed to work.
All the testing is done with SSL connections, so to some first approximation
SSL is known to work.
It's normal for the connection to remain pinned up to AD even when there
aren't any more updates to sync : this is done on the basis that if another
update comes along 'soon' we'd rather have kept the connection up.
It will time out eventually though.
You could try enabling replication logging and see what that produces :
this will print copious debugging output from the sync code to the server's
error log.
Actually, before you enable replication logging, take a look in the
error log you have because there might be some clues in there.
If there's some fatal error encountered in the sync code, it will
emit a message there.
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
