Forefront Tmg 2010 Keygen
Another TMG blog post 🙂 Was working with a client to replace an ISA 2004 server with a TMG 2010 server. Both were configured as the clients only firewall, and clients were configured to be both SecureNAT and Web Proxy clients.
Forefront Tmg 2010 Enterprise Serial Numbers. Convert Forefront Tmg 2010 Enterprise trail version to full software. Recently I've seen a lot of discussion across various online forums about licensing challenges for Microsoft Forefront TMG and UAG 2010. As you most likely know, these. Without proper licensing, many are seeking key generators (keygen) or crack codes for their TMG or UAG implementation.%name Microsoft Forefront.
The issue was with outbound FTP traffic (internal users access external FTP sites). When configured as SecureNAT (no proxy configuration in IE) FTP worked fine.
When the client was configured as a Web Proxy client (proxy configured to “Automatically Detect Settings” or proxy server hard set to the IP/name of TMG), FTP would time out and fail to connect to various FTP sites. The clients are configured to do passive FTP. As it turns out, when a SecureNAT client uses FTP, TMG connects to the external site with passive FTP. And when a Web Proxy client uses FTP, TMG connects to the external site with active FTP, which often fails. The solution is to use a little documented setting in TMG to force the use of passive FTP for Web Proxy clients.
So little documented that all the links refer to ISA 2006. To resolve, set the DWORD value NonPassiveFTPTransfer to 0 in the registry on the TMG server, which sets the mode to Passive.
The default value is 1, indicating that Active mode is used. The value will likely need to be created and it goes here: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/W3Proxy/Parameters It is also likely that you will need to create the Parameters key. Make the change and restart the Microsoft Firewall service. This particular issue is actually documented and, but refers to ISA 2006/2004/2000 and is obscure enough that you probably won’t find it unless you know exactly the right keywords to search for. On a related note, here is the single best article I have seen on working with FTP on ISA and TMG. I recently wrapped up a large TMG deployment in support of a new Exchange 2010 resource forest and there were a lot of lessons learned (read: issues that needed to be overcome), so I figured I would try to capture the main ones for the blogosphere. Part 3 of 3 – Fun with NTLM and Outlook Anywhere This article assumes a fairly decent knowledge of both TMG and Exchange.
It is not meant to be a detailed step-by-step configuration guide. All steps should be tested prior to production rollout. Before I get into the issue in detail, a little background on the environment. A new Exchange resource forest was built to host Exchange for two separate forests/domains where the user accounts lived. Everything in the resource forest was built on Windows Server 2008 R2. TMG is in the same forest and domain as Exchange and Kerberos Constrained Delegation (KCD) is configured.
TMG must be in the same domain as whatever is being published in order to use KCD. With KCD configured, our testing from a Windows 7 PC showed that Outlook Anywhere was working perfectly and not prompting for credentials when opening Outlook. In another round of testing (from an XP PC in a different domain), the user was prompted for authentication. After reviewing all TMG settings and watching TMG logs, it did not appear to be a TMG issue. To test, we forced the client to go direct to a CAS server by editing the host file. They were still prompted for authentication.
We tried fetching all windows and office updates, no luck. Since my Windows 7 test PC in the first domain was working perfectly, we decided to try a Windows 7 PC joined to the second domain. The Windows 7 PC in the second domain worked perfectly directly to the CAS (no prompts) and worked perfectly to TMG. So TMG is off the hook here. The issue, as it turns out, is that Server 2008 R2 is only taking NTLMv2 authentication by default, but the default setting on Windows XP is to only allow LM and NTLM authentication, and never NTLMv2. The authentication methods are controlled by the registry key, found at HKLMSYSTEMCurrentControlSetControlLsa. Rather than dumbing down the Server 2008 R2 CAS servers, the client changed the LmCompatibilityLevel on the XP workstations from the default value of 0 to the new value of 2 through Group Policy.
The default value of 3 was left alone on the CAS servers. No more authentication prompts! Part 1 of 3: Part 2 of 3. I recently wrapped up a large TMG deployment in support of a new Exchange 2010 resource forest and there were a lot of lessons learned (read: issues that needed to be overcome), so I figured I would try to capture the main ones for the blogosphere. Part 2 of 3 – OWA Login Issues (Account is Disabled??) This article assumes a fairly decent knowledge of both TMG and Exchange. It is not meant to be a detailed step-by-step configuration guide.
All steps should be tested prior to production rollout. This particular issue started happening when I enabled the ability for users to change their passwords from the TMG login page.
Immediately after that, when logging on to OWA with an account from the account forest (which is the account connected to the ), TMG says the account is disabled (and it’s not). One of the key items here is that the sAMAccountName is the same on both accounts. I found a KB article about the exact same issue but for ISA. The issue is in the additional things TMG does behind the scenes during login to determine password age and expiration. It stops on the first account it finds, which is the one in TMG’s local domain, which is in fact disabled as it is in the resource forest, so you are denied. To verify, we turned off the password stuff in TMG and it began to work properly again. The fix for the ISA issue was to apply a hotfix, then run a script to enable the new functionality.
Since TMG uses the same code base as ISA, I made the assumption that the hotfix code was already part of TMG and all we would need to do is run the script. The assumption turned out to be correct, just run the script in the KB article below on your TMG servers. I think you only need to run it on one server in each array (didn’t make a note of that), but it won’t hurt to run it again on each node. Associated ISA KB: Part 1 of 3.
After replacing the certificate used by CSS (for ISA), or EMS (for TMG) under the ISASTGCTRL service’s certificates, you may still have issues with ISA not connecting to the CSS (or TMG not connecting to the EMS), and you may see the following error in Server event logs: Event Type: Error Event Source: Schannel Event Category: None Event ID: 36870 Date: 3/9/2010 Time: 7:33:44 PM User: N/A Computer: COMPUTER Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x6. When the certificate is selected during the initial setup, the process grants the account that the CSS is run under Read access to that certificates key, which is found in the following location for Server 2003: C:Documents and SettingsAll UsersApplication DataCryptoRSAMachineKeys For Server 2008 and up it is in: C:ProgramDataMicrosoftCryptoRSAMachineKeys When you replace the certificate manually, those permissions aren’t granted to the new key. To resolve this, you must find the file the correlates to the certificate being used. To do this, view the certificate in the Certificates MMC and locate the Serial Number of the certificate.
From a command prompt, run: certutil –store my In the output, locate the certificate with the matching Serial Number. ================ Certificate 0 ================ Serial Number: Issuer: CN=My CA NotBefore: 2/23/2010 9:22 AM NotAfter: 2/23/2011 9:22 AM Subject: CN=L3K1126.mydomain.com Non-root Certificate Template: MSComputer, MS Computer Cert Hash(sha1): c1 6a 3b 75 79 2e 69 33 bf 9d 22 a6 33 e0 71 99 25 ef e2 94 Key Container = 18793fa9a34ad7d16ae373_2c047212-c86a-4f64-90d7-61c4e5337707 Provider = Microsoft RSA SChannel Cryptographic Provider Encryption test FAILED The “Key Container” attribute is the name of the associated file in the MachineKeys directory. Grant the account that the ISA Configuration Storage (or TMG EMS) is running under READ permissions to that file. By default, ISA & TMG are run as “NETWORK SERVICE”, so most likely it should look like this when you are done: This should begin to work immediately on ISA with no service restarts or reboots required. I haven’t tested it with TMG but I would think the same thing would be true.
If not, simply restart the ISA/TMG services or reboot. To resolve an issue for a client recently, I needed to connect into the TMG 2010 AD LDS instance manually to remove a duplicate Local Domain Table entry that was causing errors when viewing the LDT in the GUI, and also when exporting the configuration.
The error was: Forefront TMG cannot load the property page. Error: 0xc004032a The string is not valid Local Domain Table (LDT) domain name.
The error occurred on object ‘Internal’ of class ‘Network’ in the scope of array ‘Gateway’. Below is the connection information needed to connect ADSIedit to the AD LDS instance used by TMG. I recently ran into an issue with LDAPS Authentication from ISA 2006 to an internal domain controller.
I am working with a client to deploy two ISA 2006 Enterprise Edition servers in their DMZ. They have single NICs (NLB is enabled) and are not members of the internal domain, and are in their own workgroup (I know, I know, not an ideal use of ISA, but that’s a story for another time). Because they are not in the domain, we decided to use LDAPS authentication (they already had an internal CA and certificates on all of their domain controllers). Rules were added on the internal firewall rule to allow the ISA servers to do CRL checking to the internal CA and LDAPS traffic (port 636) to the domain controllers.
On the outside firewall, a rule was created to allow the ISA servers internet access for external CRL checking (this was needed to validate the third-party CA certificates in use on the published web servers when making the SSL connection from ISA to the web servers). Once the rules were in place, the setup of LDAPS on the web listener was straightforward and it worked – sort of. The initial login took about 15-20 seconds. Subsequent logins were immediate, until LDAPS session were idle for too long, then the next login took 15-20 seconds again. It was discovered that the internally issued certificates had both an Active Directory and HTTP CRL Distribution Point, and that AD was listed first.
The theory was the ISA was attempting to pull the CRL from AD first and failing, before succeeding in pulling the HTTP published version. A coworker helped me find at the computer level.
Most of the CRL checking settings found out there though a good old Google search are for a specific user or IIS related, neither of which is applicable in the ISA LDAPS scenario, as the connection is not established under any specific user context and IIS is not involved at all for the LDAPS session. According to the information, the default timeout value when processing a CRL is 15 seconds, which would explain the 15-20 seconds logons from ISA perfectly. I added the following registry key to both ISA servers, rebooted them, and now the initial logins take 2-3 seconds. Note that the value specified is in milliseconds and that the HEX value 000003e8 is equivalent to 1000 in decimal (1 second).
If you would like to read the next part in this article series please go to. NOTE: As those of you who read the most recent newsletter know, Tom is taking a full time position with Microsoft and I am going to be taking over some of his former duties here on ISAserver.org. - including writing articles for the site. Many of you already know me through my work on Windowsecurity.com, TechRepublic, WXPnews/VistaNews/Win7News and other venues. For those who don't, you can find out more about. Introduction I love new things, and I am excited about coming into this new position just in time to introduce a new product: Microsoft's Threat Management Gateway 2010 EE RTM. In this article, we'll start at the beginning, with how to how to install TMG 2010 EE RTM.
Of course, the real beginning is the planning phase, where you determine what the hardware requirements are going to be, and what role the TMG firewall is going to play on your network. However, if you're new to the TMG firewall, you probably just want to get it installed and see what it looks like. Planning for deployment can take place later if you decide you like what you see, and we'll address that in a later article. Meanwhile, this is the first of a two-part piece that will guide you through the installation process and point out potential 'gotchas' that you might encounter along the way. Day Z Zombie Survival Game.
Let us get started! As always, the first step is to make sure your hardware meets the minimum requirements, which you can find. Many of you will be doing this initial installation for testing and evaluation purposes. ISBN 978-0-273-75201-1 Download. So we will install the RTM release of the TMG firewall in a virtual machine, and the VM will have two network interfaces: • An external interface, which is bridged to the production network that allows it to connect to the Internet, and • An internal interface that only allows it to connect to other virtual machines. In this example, the only other virtual machine is a, and the TMG firewall belongs to the same domain as the domain controller.
This is going to be a 'vanilla' install. The only thing we have done in advance is join the TMG virtual machine to the domain and then installed Windows Updates. I have not installed any Exchange components or any other 'out of band' software. Our goal is to do what most admins will do - install the software in an 'out of the box' configuration and then try to make it do what we want it to do as we learn more about the product.
NOTE: One thing that you should know before we get started is the DNS configuration on the TMG VM's NICs. Because you should never (well, almost never) include an external DNS server on any of the firewall's NICs, I have configured the external interface with no DNS server setting, and the internal interface with the IP address of the internal DNS server, which is also a domain controller.
This is going to cause some issues that I'll take about later when we run into them. Here is a simple network diagram of what I am working with right now and for this article: Diagram 1 The first step is to download the evaluation version of the software. At this time, TMG is not available on MSDN, but you can download an evaluation. After you get the file downloaded, double click on it and it will unpack the files. After the files are unpacked, you will see the Welcome to Microsoft Forefront TMG page. This looks a bit different compared to what we saw with the ISA firewall and it includes some welcome new options.
Notice the Prepare and Install section - now you can run Windows Updates from the installation page. We already did that, so we don’t need to do it now. Another new option, Run Preparation Tool, is one that we will use. Click that one now. Figure 1 It’s clear that the TMG developers had large monitors when they created this interface. The dialog boxes are huge.
I suppose that makes it nice for both the devs and the users – but makes it a bit of a pain for writers who have limited horizontal space for screenshots J On the Welcome to the Preparation Tool for Microsoft Forefront Threat Management Gateway (TMG) page, click Next. Figure 2 On the License Agreement page, put a checkmark in the I accept the terms of the License Agreements checkbox and click Next. Here you are accepting the license agreements for the Microsoft Chart Controls for Microsoft.NET Framework 3.5 and 3.5 SP1 and Microsoft Windows Installer 4.5.
Figure 3 On the Installation Type page, you have three options: • Forefront TMG services and Management • Forefront TMG Management only • Enterprise Management Server (EMS) for centralized array management The new TMG makes it easier than ever to work with TMG EE, in contrast to the complexity of EE management with the ISA firewall. That is why we are installing EE in this article series – to show that you can get EE installed easily. Later we’ll create a standalone array and then we will take down the standalone array and create an enterprise array. It’s easy and fun! But first, let’s just handle the basics and select the Forefront TMG services and Management option. Figure 4 On the Preparing System page, you will see installation progress for the prerequisite software. Figure 5 The Preparation Complete page shows that the prerequisite software was installed successfully.
Figure 6 Now the Welcome to the Installation Wizard for Forefront TMG Enterprise page appears. Click Next to start installing TMG EE. Figure 7 On the License Agreement page, select the I accept the terms in the license agreement option and click Next. Figure 8 Enter your customer information (user name, organization name and product serial number) on the Customer Information page and click Next. Figure 9 On the Installation Path page, you can use the default path or choose your own path in specifying the location where you want to install the TMG firewall’s files. In this example, we’ll use the default path and click Next.
Figure 10 Ah, now here is a blast from the past - the Define Internal Network page. For the TMG firewall, as for the ISA firewall, the default Internal Network is where your core infrastructure services are contained; these include Active Directory, DNS, DHCP and WINS. You can change this definition later if you like, but we need to be able to access these resources during installation, so we have to define the default Internal Network now. Click the Add button on the Define Internal Network page.
This brings up the Addresses dialog box. There are several ways to add the addresses for the default Internal Network, but my preferred method is to use the Add Adapter approach. Click Add Adapter. Figure 11 On the Select Network Adapters dialog box, select the LAN NIC (or whatever name you have defined for that NIC) and then put a checkmark in the checkbox for that NIC. Make sure the information in the Network adapter details section accurately reflects the details of the NIC you selected. Then click OK. Figure 12 The addresses associated with the internal NIC now appear in the Addresses text box.
These addresses are based on routing table entries on the firewall - if you have not configured routing table entries on the firewall yet, these addressees might not be entirely correct, but it’s something that we can fix later, which you’ll see as we move through the installation process. Figure 13 Click Next on the Define Internal Network page. Figure 14 As with the installation of the ISA firewall, a number of services will need to be restarted or disabled when you’re installing the TMG firewall.
In this case, these include: • SNMP service • IIS Admin service • WWW Publishing Service • Microsoft Operations Manager Service NOTE: TMG is not saying that these are currently installed – it’s just telling you that if they are installed, they’ll be disabled or restarted. Figure 15 Click Install on the Ready to Install the Program page. Figure 16 A progress bar shows your progress in the installation.
Figure 17 Another dialog box will appear and give you more information about how long things are going to take. Notice that these are estimated figures; despite the numbers you see here, it took almost 30 minutes for installation to complete for me. This might be related to DNS issues, which I'll discuss later. Figure 18 Now the Installation Wizard has competed and you might think you’re finished.
In the past, with the old ISA firewall, this would have been it. The next step would have been to go into the ISA firewall console and get to configuring Networks, Access Rules, and other components to get the thing working. But with TMG, you’re not quite done yet. If you select the Launch Forefront TMG Management when the wizard closes, there will be a set of three more wizards that make it possible to get up and running at the end of the installation process.
Figure 19 Because these wizards are new, and we’re at the end of our word count for this article, we’ll save our discussion of the new installation wizards for the next article in this two part series. Hopefully this will whet your appetite for what comes next. Summary In this article, we started off by explaining that we would install the new TMG 2010 EE firewall in a plain vanilla configuration.
The only settings on the TMG firewall VM are the DNS settings, and the firewall VM has been joined to the domain before beginning the installation of the firewall software. Next we launched the installation processes, configured the default Internal Network, and let the installation complete. In the next installment of this series, we’ll complete the installation of the firewall by going through the three new wizards that are nested in a new Getting Started Wizard. See you then!
If you would like to read the next part in this article series please go to.