[Fedora-directory-users] Windows Sync over SSL problem

[David Boreham]

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.