Archive
Windows Azure Multifactor Authentication and Forefront TMG 2010
When Microsoft first announced Windows Azure Multi-Factor Authentication, a cloud-based strong authentication solution, my first thought was “I wonder if it works with Forefront TMG 2010?” Being cloud-based, my first thought was perhaps not. However, once I started digging in to it I quickly learned that it includes a software component that can be installed on-premises and will even integrate with on-premises security solutions via a number of interfaces, including RADIUS. Forefront TMG 2010 has supported RADIUS authentication for many years, so I put together a test lab and in no time at all I had Windows Azure multi-factor authentication working with Forefront TMG 2010 remote access VPN. Forefront TMG 2010 integrated with Windows Azure multi-factor authentication provides the highest level of protection for remote access users. Leveraging Windows Azure cloud-based strong authentication is extremely cost effective, with very low per user or per authentication costs and no on-premises hardware to purchase. The Windows Azure public cloud, which is ISO/IEC27001:2005 certified, provides the most secure and reliable strong authentication service available today. To learn how to configure Forefront TMG 2010 to work with Windows Azure multi-factor authentication, click here.
Identifying and Reducing Anonymous Traffic Allowed by Forefront TMG 2010
My recent blog post about altering the SafeSearch enforcement rule in Forefront TMG 2010 to require authentication has sparked some discussion on Twitter and Facebook regarding unauthenticated, anonymous access, particularly to resources located on the public Internet. In a perfect world (ok, my perfect world!), all access to and through the TMG firewall would be fully authenticated. Unfortunately, for a variety of reasons, this isn’t achievable. To start, authenticating all traffic to and through the TMG firewall would necessitate that all clients be configured as explicit web proxy clients. In addition, if non web-based protocols are allowed by firewall policy the Firewall Client would need to be distributed to all clients. While this is ideal if we’re designing a solution on paper, in the real world many administrators don’t have the luxury of forcing proxy configuration or installing the Firewall Client on all their systems. For example, some systems may not be under the administrator’s control or they may be required to support non web-based protocols on platforms other than Windows, for which the Firewall Client is not supported. Also, as veteran ISA and TMG firewall administrators know all too well, there are some applications that simply don’t play nice with an authenticating proxy, even with the Firewall Client installed. Applications that don’t leverage Winsock for network communication or that use IP-based protocols such as ICMP or GRE also prevent us from realizing our goal of authenticating all network traffic through TMG. Windows Update traffic also poses challenges for authenticating all TMG traffic, as the Windows Update service often makes requests to the Internet for updates in the background and perhaps even if there is no interactive user logged on.
Just because out of necessity some traffic has to be allowed through the TMG firewall anonymously doesn’t mean that undertaking an effort to reduce unauthenticated traffic isn’t a worthwhile project. If you’re interested in doing something like this, have a look at the Fastvue blog and read Scott Glew’s excellent article detailing how to use TMG Reporter to identify and reduce unauthenticated traffic on the Forefront TMG 2010 firewall. Not using TMG Reporter? You’re missing out! Download a free evaluation here!
Enable Authentication for SafeSearch Enforcement Rule in Forefront TMG 2010
SafeSearch enforcement in Forefront TMG 2010 is a simple and effective way to prevent users on your network from accessing explicit adult content via popular search engines. Enabling SafeSearch enforcement is accomplished by opening the Forefront TMG 2010 management console, highlighting the Web Access Policy node in the navigation tree, clicking the Configure SafeSearch link in the Tasks pane and selecting the option to Enable SafeSearch.
When SafeSearch is enabled a rule is created that grants access to all users from the Internal network to all sites in the Search Engines category.
Effectively this grants unauthenticated access to many search engines including Bing, Google, and Yahoo. This level of access is quite broad and enables anonymous users to access quite a bit of content, which might not be desirable in some environments. It is not possible to change the users in the GUI either, unfortunately. However, it can be changed programmatically using COM and VBscript. For example, the following code will change the users from All Users to All Authenticated Users.
Dim Root, Array, Rule
Set Root = CreateObject("FPC.Root")
Set Array = Root.GetContainingArray()
Set Rule = Array.ArrayPolicy.PolicyRules("SafeSearch")
Rule.AccessProperties.UserSets.Add "All Authenticated Users", fpcInclude
Rule.AccessProperties.UserSets.RemoveSpecified "All Users"
Array.Save
Array.WaitForReload
Important Note: This change is not officially supported by Microsoft. If you make this change it may potentially cause other issues, so please proceed with caution.
Once the script has completed the SafeSearch rule will now apply to All Authenticated Users and prevent unwanted anonymous access to web sites categorized as Search Engines.
Addressing Security Issues with PPTP VPN in Forefront TMG 2010
At the recent DEFCON hacking conference, security researchers demonstrated a method to crack the MS-CHAPv2 authentication protocol with a 100% success rate. MS-CHAPv2 is used as the default authentication method for remote access VPN in Forefront TMG 2010.
With the public availability of tools to automate the cracking process, PPTP communication using MS-CHAPv2 should be considered unencrypted. There are two options available to mitigate this concern: disable MS-CHAPv2 and enable EAP with PPTP, or disable PPTP and switch to a more secure remote access VPN protocol such as L2TP/IPsec or SSTP. Enabling EAP requires the use of smart cards or certificates for authentication which makes implementation more challenging. SSTP is an excellent option as it leverages SSL/TLS to protect the MS-CHAPv2 authentication process. However, SSTP is only supported on Windows Vista SP1 and later clients. L2TP/IPsec is another good choice, and although it does support certificates it can also be configured using a pre-shared key. If long, complex passwords are used and care is taken to ensure that the password is well protected, it can provide a secure remote access solution.
Forefront TMG 2010 Account Lockout Feature for FBA
Consider a scenario in which you have published your Exchange 2010 Outlook Web App servers using Forefront TMG 2010 and are using Active Directory or LDAP authentication along with Forms-based Authentication (FBA). In an effort to gain access to the system, an attacker may perform a brute force password attack by either manual or programmatic means. The attacker will attempt to guess the password for a given user until they reach the configured account lockout threshold as defined in Active Directory. Once this happens, the attacker will have to wait for the password to unlock automatically or be unlocked by an administrator depending on your security policy. Effectively this results in a Denial of Service (DoS) because the legitimate user is unable to authenticate when this happens.
To address this concern, Forefront TMG SP2 includes a feature that allows administrators to enforce an account lockout policy on the Forefront TMG firewall itself. When configured with thresholds lower than those configured in Active Directory, this feature provides valuable protection from DoS that result from unsuccessful password guessing attempts. To enable this feature, install Forefront TMG 2010 SP2, and then follow these detailed instructions.
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.
Error 0x8004FE2F Activating Windows on Forefront TMG 2010 Protected Network
When attempting to activate Windows Server 2008R2 you may receive one of the following error messages:
A problem occurred when Windows tried to activate. Error Code 0x8004FE2F
Or…
A problem occurred when Windows tried to activate. Error Code 0xC004FC03
If you attempt to activate Windows from the command line using slmgr.vbs -ato you may also encounter one of the following error messages:
Activating Window Server(R), ServerEnterprise edition {GUID}...
On a computer running Microsoft Windows non-core edition, run 'slui.exe
0x2a 0x8004FE2F' to display the error text.
Error: 0x8004FE2F
Or…
Activating Window Server(R), ServerEnterprise edition {GUID}...
On a computer running Microsoft Windows non-core edition, run 'slui.exe
0x2a 0x80072EE2' to display the error text.
Error: 0x80072EE2
The problem may occur for systems that are located on a network that is protected by a Forefront TMG 2010 firewall, and the access rule that allows the traffic requires authentication. The Windows activation process relies on WinHTTP and by default, WinHTTP communication is sent as SecureNAT client traffic. SecureNAT clients unfortunately cannot be authenticated, so the request fails.
There are two ways resolve this issue. The first is to configure WinHTTP on the Windows system you are trying to activate to use a proxy serverexplicitly. Open an elevated command prompt and enter the following command:
netsh winhttp set proxy <name or IP address of proxy server>:<port>
For example:
netsh winhttp set proxy tmg.richardhicks.net:8080
Instead of making this change to each system you want to activate, an alternative is to create an anonymous access rule on the Forefront TMG 2010 firewall that allows HTTP and HTTPS traffic to those destinations required to activate Windows. Using the Forefront TMG 2010 management console, create an access rule that allows HTTP and HTTPS from the Internal network to a Domain Name Set that contains the following destinations for all users:
activation.sls.microsoft.com.nsatc.net go.microsoft.com *.sls.microsoft.com
Make sure this rule is placed before any other rules for HTTP or HTTPS that require authentication.
Once configured, activating Windows should work without issue.
Forefront TMG 2010 Service Pack 2 Now Available
Service Pack 2 for Microsoft Forefront TMG 2010 is now available. In addition to numerous fixes released since SP1 and SP1 hotfix rollup 4, this service pack also includes the following new features:
New reports – A new site activity report that provides details about requests made to specific web sites for individual users.
New error pages – TMG SP2 provides the option to use new error pages that feature a whole new look and feel. In addition, these new error pages are more easily customized and can now include embedded objects.
Kerberos authentication for NLB – TMG SP2 includes the ability to leverage Kerberos authentication for clients accessing enterprise arrays via the NLB virtual IP address (VIP).
You can download Forefront TMG 2010 service pack 2 here. Please note that this update requires that Forefront TMG 2010 SP1 and software update 1 for TMG SP1 be installed prior to installing Forefront TMG 2010 SP2. Once TMG SP2 has been installed successfully the build number will be 7.0.9193.500.
For information regarding the installation of SP2 for Forefront TMG 2010 on enterprise arrays, click here.
Connect
Richard Hicks' Forefront TMG Blog 