- FIM 2010 R2 Book
- The Story in this book
- Overview of FIM 2010 R2
- Basic Configuration
- User Management
- Group Management
- Self-Service Password Reset
- Using FIM to manage Office365 and other Cloud Identities
- FIM Portal Customization
- Customizing Data transformations
- Issuing Smart Cards
Posts Tagged TMG
In this Announcement Availability of Microsoft Forefront TMG 2010 on SecureGUARD Appliance Series from SecureGuard we can read that. “As announced by the Microsoft Server & Cloud Blog, Microsoft Forefront TMG 2010 will be discontinued and will be no longer available for purchase as of Dec. 1, 2012. Nevertheless SecureGUARD Appliances with TMG 2010 licenses will be available for purchase significantly longer than Dec. 1, 2012.”
My supplier tells me that SecureGuard at the moment plans to support their TMG appliances until 2023.
Read about all SecureGuard appliances and offerings on http://www.secureguard.de
Interested in buying SecureGuard appliances? Contact me at firstname.lastname@example.org or just comment on this post.
I just want to take this opportunity to say thanks to everyone that over the years have worked with ISA and TMG. Having myself worked with ISA and TMG since beta of ISA 2000 I can only say… You all did a fantastic job, making ISA and TMG one the best firewalls on the market. Thank you!
What is the plan for TMG in the future? Will it vanish or will it just be a part of the next generation where TMG and UAG become one “Unified Gateway”?
Why suddenly ask these questions you might wonder, well…
The last Gartner report, published 25 May 2011, on Secure Web Gateways presents the following Maqic Quadrant for Secure Web Gateways.
As you can see it does not list TMG and the report contains the following text:
“Microsoft has informed Gartner that it does not plan to ship another full version release of its SWG product, the Forefront Threat Management Gateway (TMG). The product is effectively in sustaining mode, with Microsoft continuing to ship Service Pack (SP) updates; the next one, SP2, is planned for 3Q11. Microsoft will also continue to support TMG for the standard support life cycle — five years of mainstream support and five years of extended support. In the SWG category, TMG will become less competitive over time, since Microsoft’s goal is not to compete head-to-head with other vendors in that space. We believe that Microsoft will repurpose TMG technologies in other products and services as part of its overall cloud strategy.”
I have spent the last few days trying to get some “official” comments on this from Microsoft but has so far failed. So we can only speculate what this means.
My speculation around this is that this is part of the cloud strategy as mentioned in the Gartner report and UAG is the gateway product prepared for the cloud. My guess and speculation is that this is not the end of TMG as function but maybe as standalone product. I think we will see TMG and UAG merge into one “Unified Gateway”.
During the last 48 hours I have recieved information leading me to believe my guess and speculation above is not entirely correct. The “truth” is not yet revealed but hopefully Microsoft realize that customers and partners are waiting for clarification on the product roadmap of TMG and UAG.
[End of Update]
As soon as any official statement is presented I will add that to this post.
[End of Update]
In todays world, working remotely, and accessing information from outside the corporate network, is a demand. One huge problem with many solutions today is that this will make us expose our domain password on un-secure clients like mobile phones and internet café’s. On these un-secure devices it is very hard for us to know if there is some kind of password snatcher, and if the password is stolen this can often be used to logon to our corporate resources.
KCD (Kerberos Constrained Delegation) makes it possible for us to build solutions that do not require the domain password to access resources like ActiveSync, OWA and Sharepoint. Microsoft ForeFront UAG and TMG are two great products that can make use of KCD to secure your infrastructure.
How to make it work…
What you do is that you configure TMG/UAG to authenticate using a method that do not require the users domain password. This could be an OTP (One Time Password) for example. You then configure delegation to use KCD and UAG/TMG will request a Kerberos ticket on behalf of the user and present that as credentials to the service. In many scenarios you will find that UAG´s more flexible authentication options will make this much easier using UAG then TMG.
The ActiveSync example…
ActiveSync is widely used to access email based on Microsoft Exchange. Usually this means the username and password of the domain account is stored in the device. A mobile phone, no matter how “smart”, is not a secure platform. What you can do is to configure a second identity store where the username and “activesync password” is stored. You then use UAG/TMG to authenticate against that store and then use KCD to get the users data from Exchange. This way the password stored in the device is not the same as the domain password and you can also enforce a different password complexity and change policy.
First of all we need to understand that in order for KCD to work there are some demands on the infrastructure.
- The UAG/TMG server must be a member of the same domain as the resource the user tries to access.
- UAG/TMG needs to be trusted for delegation for the specific service
- The username needs to be the same if using multiple identity stores.
- The resource needs to accept Kerberos authentication.
More to come…
I am currently working on a more detailed article to show how to configure the ActiveSync example using UAG and AD LDS as the ActiveSync user store. I might even throw in a section on how FIM (ForeFront Identity Manager) can be used to automate the process of managing the second identity store required in this example.
Yuri Diogenes [MSFT] has just started a new Wiki page on TechNet. Anyone working with TMG should visit and contribute to the Forefront Threat Management Gateway (TMG) 2010 Survival Guide.
Migrating from ISA to TMG is in some case quite easy, but in others it can be quite a jurney. In one of my latest cases it was indeed an interesting jurney…
So let me share some findings with you.
Moving from Standalone ISA to TMG Array.
This does not look to be a problem in theory, but…
Things you can do in a standalone ISA are sometimes not possible in a cluster.
This time it was the use of multiple subnets on a single nic. When moving to NLB you cannot have a VIP from a different subnet.
Found this out when i entered the scene day 1… And this caused the project also needing to do some IP-routing changes in the network.
Even though it is possible to export/import configurations in some scenarios. You usually want to take the opportunity to change the rules to take advantage of new features in TMG and also to clean up in the “mess” after adding rules over the years. While doing this kind of migration I have discovered many times that customer tells you one thing and the rules show something else.
You ask the cu…
“Have you made any special settings that we need to consider?”, and cu will answer “No”.
Well what you find in the rules is that a lot of them have “special non-default settings”. And when do you find this out… When users start testing! A little bit to late in other words.
The problem is that it is not a trivial task to check 100 rules in detail in order to grasp how many places have “special settings”.
This cu had a few FTP rules in place. They already knew which ones needed to be cleared from the “Read-Only” flag. They had learned that the hard way in ISA. But they did not know if they also required “Active FTP”. In a TMG cluster you need to “enable” Active FTP on first the enterprise level… And also on the Array level.