Analyzing Exchange RPC traffic over TCP/IP

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.

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: 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):

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.

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 ExchangeA'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.
   
   The End Point Mapper is consulted in order to determine on which port the service wanted is listening.
   
   A Bind and BindAck between the two services will happen to establish RPC communication.
   
   Optional - A series of Requests and Responses with opnums will be issued.
   
   Optional - The RPC communication is ended.
   
   The TCP connection is broken with Fin packets.
2. The End Point Mapper is consulted in order to determine on which port the service wanted is listening.
   
   A Bind and BindAck between the two services will happen to establish RPC communication.
   
   Optional - A series of Requests and Responses with opnums will be issued.
   
   Optional - The RPC communication is ended.
   
   The TCP connection is broken with Fin packets.
3. A Bind and BindAck between the two services will happen to establish RPC communication.
   
   Optional - A series of Requests and Responses with opnums will be issued.
   
   Optional - The RPC communication is ended.
   
   The TCP connection is broken with Fin packets.
4. Optional - A series of Requests and Responses with opnums will be issued.
   
   Optional - The RPC communication is ended.
   
   The TCP connection is broken with Fin packets.
5. Optional - The RPC communication is ended.
   
   The TCP connection is broken with Fin packets.
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.