DRS Replication Windows<->Windows Study

[tridge at samba.org]

Hi Fernando,

Sorry for the slow response - I'm rather behind in my email at the
moment (if I am being slow responding to a question, please ping me on
the #samba-technical IRC channel).

 > In an experiment using two Windows Server 2003, we modified some user
 > settings and it replicated correctly, but in wireshark we couldn't see any
 > DRSUAPI message exchanged (we were expecting DsReplicaSync and/or
 > DsGetNCChanges requests and responses, right?).

that's right

 > Instead, we found one LDAP modifyRequest/modifyResponse message
 > that seems to replicate those modified settings.

There can be a few reasons for this. The most common reasons are:

 1) you started the capture after the DRSUAPI connection was
 established. Wireshark relies on seeing the initial DCERPC bind call
 to know what pipe is being used (it looks for the GUID in the
 bind). If it doesn't have that initial bind then it just marks the
 packets as "dcerpc" and not as the specific drsuapi pipe. You may be
 able to work around this by using "decode as" to force decoding as
 DRSUAPI, or better yet, make sure you capture from before the TCP
 connection was established.

 2) the DRSUAPI protocol is encrypted, so you need to use a version of
 wireshark that can decrypt the packets, and you need to give
 wireshark the right keytab to decrypt the krb5 encrypted
 packets. That means using a very recent version of wireshark (build
 it from source) and passing the -K option to point at a keytab. There
 are several ways to get the keytab. One is to virst vampire the w2k8
 box to s4, then use "net export keytab".

 There are also some bugs in wireshark decrypting some of the AES
 encryption used between windows. Metze has a workaround using a
 LD_PRELOAD for wireshark. Let me know if you think you need this and
 I'll post details.

 3) The DRSUAPI parser in wireshark is quite incomplete, and doesn't
 decode some important parts of the protocol.

 To fix this you could work with Ronnie Sahlberg (sahlberg at samba.org)
 to convert the wireshark parser to use PIDL, like some of the other
 wireshark parsers use. PIDL is the IDL compiler that Samba uses, so
 if wireshark was converted to use PIDL for DRSUAPI then you would get
 the same parse of the DRSUAPI packets that the Samba code gets. This
 would be a good little project for one of you to work on if you like,
 and would help with DRS development quite a lot.

 4) If using w2k8 at both ends, then they may be negotiating NDR64
 instead of NDR32. Ronnie has only just started adding NDR64 support
 to wireshark. You can either try his latest code, or you could use
 the ndrdump command in s4 to decode it packet by packet (using the
 --ndr64 flag to ndrdump). You will need to pull the packets out of
 wireshark one at a time using right-click "Export selected packet
 bytes" on the RPC payload.

I'd also suggest using the repadmin command on windows to look at the
replication status. It can show you the time of the last successful
replication. Does that time match your change?

 > In another similar experiment, using two Windows Server 2008, we could see
 > those DRSUAPI messages but there isn't any LDAP modifyRequest/modifyResponse
 > message, like on the first experiment.
 > 
 > Was this LDAP message expected?

a few LDAP operations are not unusual, but you do expect to see DRS
replication calls. I suspect you are just not seeing them in wireshark
for one of the reasons given above.

 > The first experiment in more details:
 >     * The "ad_update_user_filtered.cap" file attached holds the network
 > traffic captured and the "krb5.kt" file attached holds the keytab file for
 > kerberos decrypting if someone wants to check. The capture file was
 > previously filtered to avoid unnecessary packages, but I can provide the
 > full capture file if someone wants it.

ok, I see you know how to get a keytab, good!

When I tried to open the file here I got a msg from wireshark saying
it is corrupt. Perhaps you could make the full file available
somewhere? (preferably on a download site, let me know if you don't
have a public site you can use). Or put it on one of the machines we
both have access to (eg. Eduardo's machine).

Cheers, Tridge