If you would like to be notified of when Neil Hobson releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.
If you would like to read the first part of this article series please go to Header Firewall in Exchange 2010 (Part 1).
Introduction
This is the second and final part of an article covering the header firewall feature of Exchange Server 2010. In this article we are looking at how to use the header firewall feature to strip received headers from messages. We started part one by discussing received headers and the information that they contain. We left part one having listed out the send connectors and know that we need to make a change to the ms-Exch-Send-Headers-Routing extended right. Let’s now get down to the interesting part of this article and make the required permissions changes.
Send Connector Permissions Changes
To see which users on the send connector have the ms-Exch-Send-Headers-Routing extended right by default, we need to run the Get-ADPermission cmdlet against the send connector using a command similar to the one shown below:
Get-SendConnector –Identity {name of Send connector} | Get-ADPermission | where {$_.ExtendedRights –like “*routing*”} | fl user, extendedrights
The result of running this command is shown in Figure 2-1. You will notice that the command outputs just the user names that have the ms-Exch-Send-Headers-Routing extended right.
Figure 2-1: Listing Permissions on the Send Connector
In Figure 2-1 you can see that there are a total of seven users that have this extended right. The fact that these users have this extended right means that routing headers will be sent which implies that the header firewall feature is not enabled. In other words, to enable the header firewall feature to not send routing headers, we will need to remove this extended right. If you run this command on the Edge Transport server role to obtain the permissions on the Send connector on this particular server role, you should see similar results.
Now that we’ve confirmed the header firewall is not configured for this particular send connector scenario, it’s now time to remove the ms-Exch-Send-Headers-Routing extended right and therefore enable the header firewall. To do this, we are going to remove the ms-Exch-Send-Headers-Routing extended right from the NT AUTHORITY\ANONYMOUS LOGON user. I will explain why we are doing this against this account in just a moment. This is the command that we need to use:
Get-SendConnector –Identity {name of Send connector} | Remove-ADPermission –User “NT AUTHORITY\ANONYMOUS LOGON” –ExtendedRights ms-Exch-Send-Headers-Routing
If the command is successful, you should see the extended right removed as you can see from Figure 2-2.
Figure 2-2: Removing the ms-Exch-Send-Headers-Routing Extended Right
You might be wondering at this stage why we are removing the ms-Exch-Send-Headers-Routing extended right specifically for the NT AUTHORITY\ANONYMOUS LOGON user. The reason for this is because, by default, a send connector that has the Internet usage type has the anonymous user account configured with the ms-Exch-Send-Headers-Routing extended right. Since in this lab I am using a send connector with the usage type of Internet, it’s the NT AUTHORITY\ANONYMOUS LOGON user that I need to modify.
You can also see this via the ADSI Edit tool when viewing the permissions on the Send connector. To do this, run ADSI Edit and connect to the configuration naming context. Once here, navigate to Services \ Microsoft Exchange \ {your Exchange organization} \ Administrative Groups \ Exchange Administrative Group (FYDIBOHF23SPDLT) \ Routing Groups \ Exchange Routing Group (DWBGZMFD01QNBJR) \ Connections. From here, you will see the send connectors in the middle pane. Next, bring up the properties of the send connector and click the Security tab. You will be presented with a screen similar to that shown in Figure 2-3.
Figure 2-3: Send Connector Properties in ADSI Edit
Here you can clearly see that the ANONYMOUS LOGON user has the Send Routing Headers permission granted. Note that the screen shot in Figure 2-3 was taken before I ran the command to remove the extended right within the Exchange Management Shell. The Send Routing Headers permission shown in Figure 2-3 is the ms-Exch-Send-Headers-Routing extended right. Personally I’d recommend using the Exchange Management Shell to make permissions changes rather than editing permissions in ADSI Edit; Figure 2-3 is shown for illustration and education purposes only.
Once we’ve made the configuration change to the connector, the Edge Synchronization process will ensure that the corresponding connector on the Edge Transport also has the permissions modified accordingly. However, if you wish to speed up the change you can run the Start-EdgeSynchronization cmdlet to force synchronization immediately as you can see from Figure 2-4. Here it can be seen that there is one update to the configuration objects as a result of making the permissions change on the send connector.
Figure 2-4: Forcing the Edge Synchronization Process
We can now see what happens when a new message is sent from the organization with the header firewall now enabled for routing information. In Figure 2-5 you can see that the only received header now shown is for the Edge Transport server which is the public-facing server for the organization sending the message. The user in the nghcloud.co.uk organization can no longer see the received header for the internal server named HF-EXCH.neilhobson.com, and can therefore no longer see the internal IP address information associated with that server.
Figure 2-5: Received Headers Removed – Header Firewall Enabled
Disabling the Header Firewall
To disable the header firewall for this send connector and put back the original configuration, it’s simply a case of re-adding the ms-Exch-Send-Headers-Routing extended right back to the NT AUTHORITY\ANONYMOUS LOGON user via the following command:
Get-SendConnector – Identity {name of Send connector} | Add-ADPermission –User “NT AUTHORITY\ANONYMOUS LOGON” –ExtendedRights ms-Exch-Send-Headers-Routing
The result of running this command is shown in Figure 2-6. Notice how the deny setting is shown as false, meaning that the extended right is taking effect.
Figure 2-6: Re-enabling the Header Firewall
Enabling the Header Firewall on a Receive Connector
In the previous scenario, the header firewall was applied by the neilhobson.com Exchange organization that was sending the outbound message. Therefore, the received headers were not sent with the actual message. It’s also possible for the nghcloud.co.uk receiving organization to configure permissions on its receive connector to achieve the same result.
In this example, the following command is run against the Hub Transport server in the nghcloud.co.uk receiving organization to examine the permissions set on the default Receive connector on the Hub Transport server.
Get-ReceiveConnector –Identity {name of default Receive connector} | Get-ADPermission | where {$_.extendedrights – like “*routing*”} | fl user,extendedrights
The result of running this command is shown in Figure 2-7. This reveals a similar result to what we have seen earlier in this article in that the header firewall is not enabled. Note, however, that this time we are looking at the extended right known as ms-Exch-Accept-Headers-Routing, since we are accepting the routing headers this time rather than sending them.
Figure 2-7: Listing Permissions on the Receive Connector
To enable header firewall for this receive connector, we can run the following command to remove the ms-Exch-Accept-Headers-Routing extended right for the NT AUTHORITY\ANONYMOUS LOGON user.
Get-ReceiveConnector –Identity {name of Receive connector} | Remove-ADPermission –User “NT AUTHORITY\ANONYMOUS LOGON” –ExtendedRights ms-Exch-Accept-Headers-Routing
I won’t add any more screen shots of this process as we have covered the process already within this article and I’m sure you understand the process now.
Summary
That completes our look at the header firewall feature of Exchange Server 2010. It’s quite possible to overlook this feature but after having read this article I hope that you now understand more about it.
If you would like to be notified of when Neil Hobson releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.
If you would like to read the first part of this article series please go to Header Firewall in Exchange 2010 (Part 1).
