Exchange Management Console Requires Access to a Forest Root Domain Controller

In an effort to secure their environments, many customers implement firewalls between various internal subnets. This can cause issues for Exchange 2007 if certain ports are blocked. For more detail on ports required by Exchange 2007, see the Data Path Security Reference article here:

https://technet.microsoft.com/en-us/library/bb331973(EXCHG.80).aspx

A scenario that comes up less frequently is what to do in the case of a parent/child domain structure. Aside from any Active Directory concerns, Exchange must have network access to domain controllers in the root domain of the forest. This includes any Exchange tools being run from remote workstations.

Recently, we encountered a case where a customer had restricted network access from a client network so that they only had access to servers in a child domain of the forest. Exchange was installed on servers in the child domain, so most functions worked appropriately. The issue we found was in performing certain operations from the Exchange Management Console (“EMC”) from the clients that had no access to the root domain. Certain functions in the EMC attempt to perform a connectionless LDAP (CLDAP) request to a domain controller in the forest root. This is different from the Exchange Management Shell (“Shell”), which will connect to a local DC or GC (even in the child domain) to process its requests.

Here is an example from a NetMon capture I took while trying to create a mailbox from the EMC:

118 1.546875 192.168.12.2 192.168.10.2 CLDAP searchRequest(1856) "<ROOT>" baseObject

130 1.546875 192.168.12.2 192.168.10.2 CLDAP searchRequest(1857) "<ROOT>" baseObject

142 1.546875 192.168.12.2 192.168.10.2 CLDAP searchRequest(1858) "<ROOT>" baseObject

150 1.546875 192.168.12.2 192.168.10.2 CLDAP searchRequest(1859) "<ROOT>" baseObject

In my test, 192.168.12.2 is the client machine running the EMC and 192.168.10.2 is a domain controller in the forest root. Since we never get a response from the DC, the operation eventually times out and fails.

Contrast this with a capture taken while doing the same thing (creating a mailbox) via the Shell:

6 0.000000 192.168.12.2 192.168.11.2 LDAP alta-smp > ldap [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=350| searchRequest(43) "<ROOT>" baseObject

7 0.000000 192.168.11.2 192.168.12.2 TCP [TCP segment of a reassembled PDU]

8 0.000000 192.168.11.2 192.168.12.2 LDAP searchResEntry(43) "<ROOT>"

In this case, the Shell automatically selected a specific DC in the child domain (192.168.11.2), which is in a network that is accessible to the client. You will also note that we used LDAP to connect, meaning a TCP session is established, whereas CLDAP would create a UDP session.

So, basically, this is just a difference in our code from the Shell to the EMC. Another example you’ll see is when you try to specify a Configuration Domain Controller from the EMC versus the Shell. To set it in the Shell, you would simply use this cmdlet:

$AdminSessionADSettings.ConfigurationDomainController = ‘server.domain.com’

From the Exchange Management Console, you must browse for a DC instead of specifying one:

Once you click the “Browse” button, EMC queries for the _ldap SRV record in the root domain and attempts to make a CLDAP connection to it, so you will see the same type of traffic in the trace as the one listed above.

The bottom line is that Exchange servers and any computers running the Exchange management tools must have network access to domain controllers and global catalogs in the root domain of the forest. If you must restrict network traffic, you should place a GC from the root domain in the local subnet that is being restricted.