XADM: Analyzing Exchange RPC Traffic Over TCP/IP

ID: Q159298

The information in this article applies to:

SUMMARY

With Exchange Server, you sometimes need to read and analyze sniffer traces when troubleshooting server-to-server communication along with client-to- server communication. This article addresses RPC sniffs between various Exchange Server services.


MORE INFORMATION

End Point Mapper

To understand the various stages an RPC Client goes through in order to connect to a certain service, we must first understand how the Remote Procedure Call (RPC) Service', otherwise known as the End Point Mapper, aids Exchange in its quest for service UUID numbers. The End Point Mapper performs a variety of tasks but the one we are interested in is its ability to tell us the port number a service we are looking for is listening on. UUID's can be generally categorized by their first 2 characters, for Microsoft Exchange v4.0 and v5.0:
A4 - STORE
F5 - DIRECTORY
E1 - ENDPOINT MAPPER
Let us take the following example where ExchangeA Server wants to send a message to ExchangeB Server (ExchangeA and ExchangeB are in the same site therefore the communication mechanism is RPC and in this case it is over TCP/IP).

The first thing that ExchangeA must do is query ExchangeB's End Point Mapper to find where its MTA is listening. The reason for this is the port number that each Exchange service listens on can change on subsequent startups. The End Point Mapper is responsible for tracking which service is listening on which point. When an Exchange service starts, it registers itself with the End Point Mapper and asks the End Point Mapper to assign it a port number. The End Point Mapper is always listening on port 135 for TCP/IP and the End Point Mapper's UUID is (E1AF8308-5D1F-11C9-91A4- 08002B14A0FA).

The following 11 frames show the complete conversation between ExchangeA (on port 3464) and ExchangeB's End Point Mapper (on port 135): 

1. TCP: ....S., len:    4, seq: 562005063-562005066, ack:         0, win:
   8192, src: 3464  dst:  135

2. TCP: .A..S., len:    4, seq: 875064831-875064834, ack: 562005064, win:
   8760, src:  135  dst: 3464

3. TCP: .A...., len:    0, seq: 562005064-562005064, ack: 875064832, win:
   8760, src: 3464  dst:  135

4. MSRPC: c/o RPC Bind:         UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA
   call 0x54004E  assoc grp 0x0  xmit 0x16D0  recv 0x16D0

5. MSRPC: c/o RPC Bind Ack:     call 0x54004E  assoc grp 0x33CFA  xmit
   0x16D0  recv 0x16D0

6. MSRPC: c/o RPC Request:      call 0x1  opnum 0x3  context 0x0  hint
   0x84

7. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x80  cancels
   0x0

8. TCP: .A...F, len:    0, seq: 562005292-562005292, ack: 875065044, win:
   8548, src: 3464  dst:  135

9. TCP: .A...., len:    0, seq: 875065044-875065044, ack: 562005293, win:
   8532, src:  135  dst: 3464

10. TCP: .A...F, len:    0, seq: 875065044-875065044, ack: 562005293, win:
   8532, src:  135  dst: 3464

11. TCP: .A...., len:    0, seq: 562005293-562005293, ack: 875065045, win:
   8548, src: 3464  dst:  135

Frame 1 - ExchangeA sends a Syn packet to ExchangeB.

Frame 2 - ExchangeB acknowledges the packet with a SynAck packet.

Frame 3 - ExchangeA sends an acknowledge of the SynAck. We now have a TCP connection between ExchangeA and ExchangeB.

Frame 4 - ExchangeA is Binding to ExchangeB's End Point Mapper. We know this by the UUID number (E1AF8308-5D1F-11C9-91A4-08002B14A0FA) it is sending the Bind to and also by the dst: port number.

Frame 5 - ExchangeB acknowledges the Bind with a BindAck. We now have an RPC connection between ExchangeA and ExchangeB's End Point Mapper.

Frame 6 - ExchangeA sends an RPC Request of opnum 0x3 to ExchangeB along with the UUID of the service it is looking for (in this case it is ExchangeB's MTA). This is to request the port number of the service with the corresponding UUID.

Frame 7 - ExchangeB returns the port number that the service that matches this UUID is listening on. ExchangeA now has all the information it needs to find the MTA on ExchangeB.

Frames 8 through 11 - Closing down the TCP connection between ExchangeA and ExchangeB.

Now that ExchangeA knows the port number it needs to connect to ExchangeB's MTA. An important note here is the Exchange MTA does an RPC bind slightly different than most RPC binds. It performs a two-way handshake, meaning, not only does ExchangeA have to bind to ExchangeB but ExchangeB must bind to ExchangeA before any messages can be sent. Therefore, you should see a Bind followed by a BindAck then another Bind from the other server followed by another BindAck as illustrated below. 

1. TCP: ....S., len:    4, seq: 562005113-562005116, ack:         0, win:
   8192, src: 3470  dst: 4764

2. TCP: .A..S., len:    4, seq: 875064881-875064884, ack: 562005114, win:
   8760, src: 4764  dst: 3470

3. TCP: .A...., len:    0, seq: 562005114-562005114, ack: 875064882, win:
   8760, src: 3470  dst: 4764

4. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE
   call 0x1EBE80  assoc grp 0x0  xmit 0x16D0  recv 0x16D0

5. MSRPC: c/o RPC Bind Ack:     call 0x1EBE80  assoc grp 0x3150EAC1  xmit
   0x16D0  recv 0x16D0

6. TCP: .AP..., len:  206, seq: 562005250-562005455, ack: 875064990, win:
   8652, src: 3470  dst: 4764

7. MSRPC: c/o RPC Request:      call 0x1  opnum 0x0  context 0x0  hint
   0x11E

8. TCP: .A...., len:    0, seq: 875064990-875064990, ack: 562005792, win:
    8082, src: 4764  dst: 3470

9. TCP: ....S., len:    4, seq: 875064951-875064954, ack:         0, win:
    8192, src: 1969  dst: 1733

10. TCP: .A..S., len:    4, seq: 562005173-562005176, ack: 875064952, win:
   8760, src: 1733  dst: 1969

11. TCP: .A...., len:    0, seq: 875064952-875064952, ack: 562005174, win:
   8760, src: 1969  dst: 1733

12. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE
   call 0x6C645F65  assoc grp 0x0  xmit 0x16D0  recv 0x16D0

13. MSRPC: c/o RPC Bind Ack:     call 0x6C645F65  assoc grp 0x215D6F47
   xmit 0x16D0  recv 0x16D0

14. TCP: .AP..., len:  192, seq: 875065087-875065278, ack: 562005282, win:
   8652, src: 1969  dst: 1733

15. MSRPC: c/o RPC Request:      call 0x7DFE09C  opnum 0x1  context 0x0
   hint 0x2

16. TCP: .A...., len:    0, seq: 562005282-562005282, ack: 875065335, win:
   8377, src: 1733  dst: 1969

17. MSRPC: c/o RPC Response:     call 0x7DFE09C  context 0x0  hint 0x1C
   cancels 0x0

18. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x20  cancels
   0x0

Frames 1 through 3 - Once again our TCP three way handshake.

Frame 4 - ExchangeA MTA is binding to ExchangeB MTA.

Frame 5 - ExchangeB acknowledges the Bind with a BindAck.

Frame 6 -

Frame 7 - ExchangeA sends an RPC Request with opnum 0x0. An opnum 0x0 is an MtaBind call. This will trigger ExchangeB's MTA to issue a Bind to ExchangeA as the MTA's need a two way connection.

Frame 8 - ExchangeB acknowledges it received Frame 7.

Framess 9 through 11 - Our TCP three way handshake initiated by ExchangeB this time.

Frame 12 - ExchangeB MTA is binding to ExchangeB's MTA.

Frame 13 - ExchangeA acknowledges the Bind with a BindAck.

Frame 14 -

Frame 15 - ExchangeB sends an RPC Request with opnum 0x1. An opnum 0x1 is an MtaBindBack call. This is setting up the two way conversation the MTA's need.

Frame 16 - ExchangeA acknowledges it received Frame 15.

Frame 17 - ExchangeB's response to Frame 7.

Frame 18 - ExchangeA's response to Frame 15.

This illustrates the flow of an RPC connection. The example above illustrates specifically a typical connection between two MTA's. This same kind of conversation will happen between the other various Exchange Services as well although the MTA is the only one that needs a two way conversation to exchange information.

The information contained in this article uses the MTA for its examples. An important note is this same type of conversation will happen with any and all Exchange RPC communication over TCP/IP.
  1. The TCP three-way handshake will be established.


  2. The End Point Mapper is consulted in order to determine on which port the service wanted is listening.


  3. A Bind and BindAck between the two services will happen to establish RPC communication.


  4. Optional - A series of Requests and Responses with opnums will be issued.


  5. Optional - The RPC communication is ended.


  6. The TCP connection is broken with Fin packets.
When looking through sniffer traces of RPC communications, or any TCP communication, it is important that you are aware that multiple conversations can be occurring simultaneously. Do not assume that simply because a Request packet follows a BindAck packet that this Request came from the particular conversation you are interested in. A quick check of the destination and source ports with TCP will tell you if the packet you are looking at is part of the conversation you are interested or not. If the destination and/or source port number is no the same as the port numbers used in the TCP three way handshake, the packet you are looking at is part of a separate conversation.

A good display filter within Network Monitor, filtering on the destination and source port numbers will serve as a great aide in ensuring the packets you are looking at do indeed belong to the conversation in question.

One other important note is this article addresses RPC over TCP only. No matter what the underlying protocol is, the RPC piece of this article remains the same. For example RPC over IPX would work quite similarly except the IPX communication would have to be established prior to RPC much in the same way TCP must be established before RPC.

Additional query words: Netmon Network Monitor 


Keywords          : kbnetwork kbtool kbusage exchange 
Version           : winnt:4.0
Platform          : winnt 
Issue type        :

Last Reviewed: April 8, 1999