Archive
Forefront TMG 2010 Configuration Change Description Survey
When making changes to the Forefront TMG 2010 firewall, by default the administrator is prompted to enter a description of the configuration changes made before they are applied. For those TMG administrators that use this facility, what kind of information do you put in this change description box? A verbose explanation of changes made? Details about why the change was made? Your name, network ID, or initials? Is it helpful to provide reference to a help desk ticket or a change request?
Tell me how you use this feature and what kind of information you typically provide by commenting on this post. I’ll approve the most interesting and useful ones as they come in. Thanks in advance for participating!
Unable to Retrieve Data from Array Members after Enabling Kerberos Authentication with NLB on Forefront TMG 2010
Immediately after configuring Forefront TMG 2010 to support Kerberos authentication with NLB, you may encounter a scenario where the Forefront TMG management console fails to communicate with the members of the array and includes the following error message:
Unable to retrieve data from: <array_members>
In addition, an Event ID 4 from the Security-Kerberos source is recorded in the system event log:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server tmgsvc2. The target name used was tmg3$@richardhicks.net. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (RICHARDHICKS.NET) is different from the client domain (RICHARDHICKS.NET), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
When making the changes to support Kerberos authentication in load balanced scenarios, the Forefront TMG firewall service is configured to run in the context of a domain user account. When the Forefront TMG management console was first opened, it authenticated to the array members using the Service Principal Name (SPN) registered to the machine (computer) account. As the changes are applied and the services are restarted, the array members are now running in the context of a domain user account. However, the management console continues to send a Kerberos ticket with the SPN registered to the machine account. The Forefront TMG firewall service running in the context of the domain user account cannot decrypt this Kerberos ticket and replies with a Kerberos error.
Resolution in this case is quite simple. Closing the Forefront TMG management console and opening it again will force the client to re-authenticate, this time using the correct SPN. The Kerberos event log errors are anomalous and can safely be ignored.
Win a Signed Copy of Forefront TMG 2010 Administrator’s Companion
To celebrate the end of a very successful 2011 for my blog, I am giving away another copy of the Forefront Threat Management Gateway (TMG) 2010 Administrator’s Companion signed by all of the authors – Jim Harrison, Yuri Diogenes, Mohit Saxena, and Tom Shinder!
To be eligible to win, all you have to do is comment on this post and tell me how I, or one of my blog posts, helped you with a particular issue. On Friday, December 30, 2011, I will select one lucky reader to receive this book. As an added bonus, I will also include a copy of Yuri Diogenes and Tom Shinder’s Deploying Forefront Threat Management Gateway (TMG) 2010, also signed by both authors!
Enter now for a chance to win this great prize! I will ship the book to any country too. Sorry, previous winners are not eligible.
Forefront TMG 2010 Protocol Direction Explained
When reviewing the configuration of a pre-defined protocol or creating a custom protocol on the Forefront TMG 2010 firewall, many new (and sometimes even veteran) firewall administrators can be confused by the protocol direction. The correct configuration of the protocol direction is essential for proper firewall operation, but there are times when it can be somewhat unintuitive. In this post I’ll provide some clarification.
TCP
For TCP protocols the direction can be specified as either inbound or outbound.
For access rules, protocol direction is configured as outbound. Traffic flows outbound from the source to the destination. This is true even when creating an access rule to allow traffic inbound to the Forefront TMG 2010 firewall itself. It sounds counterintuitive, but the TCP protocol direction for access rules allowing access to the Local Host network should still be outbound. Why? Again, because traffic flows outbound form the source to the destination, in this case the TMG firewall’s Local Host network. If, in this case, you were to configure the protocol direction as Inbound (intuitively, inbound to the TMG firewall) it will not work.
For publishing rules, protocol direction is configured as inbound. Traffic flows inbound from the source to the published service on the Forefront TMG 2010 firewall. Pre-defined server publishing protocols include the “server” suffix, as shown here:
UDP
For UDP protocols the direction can be specified as either Receive, Receive Send, Send, or Send Receive.
For access rules, protocol direction is configured as Send. Traffic is sent from the source to the destination. If a response is expected then the protocol direction is configured as Send Receive. This is required because UDP is connectionless and the return traffic would otherwise be denied by the TMG firewall.
For publishing rules, protocol direction is configured as Receive. Traffic is received by the TMG firewall from the source to the published service on the Forefront TMG 2010 firewall. If a response is expected then the protocol direction would be configured as Receive Send.
IP and ICMP
For IP and ICMP protocols the direction can be specified as either Send or Send Receive.
IP and ICMP protocol definitions are only supported for access rules, so protocol direction is configured as Send. As with UDP, IP and ICMP are connectionless and if a response is expected then the protocol direction is configured as Send Receive.
Mastering Microsoft Forefront UAG 2010 Customization
Recently my good friends Ben (Erez) Ben-Ari and Rainier Amara announced their new book Mastering Microsoft Forefront UAG 2010 Customization, which is scheduled for release early next year. As many of you know, Ben is the author of the Microsoft Forefront UAG 2010 Administrator’s Handbook, an essential reference for anyone working with Forefront UAG 2010. The new book focuses on customization, which is one of the features that make Forefront UAG 2010 a powerful and compelling remote access solution. I have the tremendous privilege of serving as the book’s technical reviewer, and as I am getting an advanced look at Ben and Rainier’s work I can tell you this book will be a must-have for anyone working with Forefront UAG 2010. The book will be available in print and e-book formats and can be pre-ordered here.
Installing Forefront TMG 2010 SP2 on Enterprise Arrays
July 4,2012 – Update: A script is now available on ISATools.org that will identify the exact order in which to install TMG SP2 for your environment. You can download the script here.
To successfully install Service Pack 2 (SP2) for Forefront TMG 2010, you must first install Service Pack 1 (SP1), then Software Update 1 for SP1 (SP1U1) as I indicated in a previous blog post. None of the other hotfix rollups available for Forefront TMG are required to upgrade to SP2. For Forefront TMG 2010 enterprise arrays, these updates must be installed in a specific order to eliminate potential conflicts. The proper sequence is as follows:
First, install SP1 for Forefront TMG 2010 on the…
- Enterprise Management Server (EMS)
- Reporting server in each array
- Remaining array members in each array
Next, install Software Update 1 for Forefront TMG 2010 SP1 on the…
- EMS
- Reporting server in each array
- Remaining array members in each array
Lastly, install SP2 for Forefront TMG 2010 on the…
- EMS
- Reporting server in each array
- Remaining array members in each array
For standalone arrays, treat the array manager as the EMS and follow the order outlined above. In addition, if you are adding a new array member to an existing array, install Forefront TMG 2010 and apply the updates in order before joining the array. Make certain that the new array member is at the same update level as the EMS and other array members. Also, consider slipstreaming SP2 with your installation media to save yourself some time.
Special thanks to Jim Harrison for clarification on the installation order.
Connect
Richard Hicks' Forefront TMG Blog 