USEast Technologies Blog Site

UAG DirectAccess – Don’t Fear the Reaper or IPv6

2010-03-12T06:28:46.4165305-05:00

UAG DirectAccess – Don’t Fear the Reaper or IPv6

Feed: The Edge Man
Posted on: Thursday, March 11, 2010 7:10 PM
Author: tshinder-msft
Subject: UAG DirectAccess – Don’t Fear the Reaper or IPv6

“All our times have come
Here, but now they’re gone
Seasons don’t fear the reaper
Nor do the wind, the sun or the rain (We can be like they are)
Come on baby (Don’t fear the reaper)
Baby, take my hand (Don’t fear the reaper)
We’ll be able to fly (Don’t fear the reaper)
Baby, I’m your man….”

Listen to 30 seconds of the song here (play #3)

OK, enough of the Blue Oyster Cult, let’s get down to business.

Whenever I introduce people to DirectAccess, I start with all the great things it has to offer. IT gets to control and manage the DA clients on the Internet in the same way they control and manage clients that never leave the corpnet. End users get to connect to what they need on the corpnet without having to think about it. Everyone is happier than ever and this is what IT and end users have been waiting for, what everyone really was expecting of remote access since the first dial-up connection was made way back in the 20th century.

After the troops get charged up about what DirectAccess has to offer, I get to the foundations of the solution. I start with Windows Firewall with Advanced Security. OK, that’s cool, we’ve all worked with host-based firewalls and that’s no problem. Then I get to IPsec. Hmmm. That’s a little scary, but then, most of us have used IPsec for L2TP/IPsec connections, and some of us have even used it to connect VPN gateways using site to site IPsec tunnel mode connections. So while a little scary, IPsec isn’t a deal breaker. DNS? No problem! How about creating SSL web sites? Again, total no brainer. Certificates and PKI? Sometimes problematic, but putting together a PKI and issuing certificates is pretty mainstream these days, and DirectAccess doesn’t impose any “off-label” type of certificate requirements, just everyday computer and web site certificates. So even when PKI is on the table, DirectAccess is still looking like a might juicy proposition.

Then I say “IPv6”

Jaws drop, eyes glaze over, smiles turn to frowns, elation turns to desolation, and the entire upbeat nature of the conversation turns into a something akin to a funeral procession.

When that happens, I’ve got to turn things around fast, or else it it’ll turn from “Don’t fear the reaper or IPv6” to “you’ve lost that lovin’ feelin”. The good news is that when you deploy DirectAccess using UAG, you don’t need to fear IPv6 (and maybe the reaper too).

I understand the trepidation involved with IPv6. A lot of companies have already decided that there is little to gain from IPv6, and that it’s unlikely that we’ll see widespread adoption of IPv6 on the Internet in our lifetimes. So why deal with what looks like a complicated mess of 128 bit numbers that are impossible to remember and a new addressing scheme that makes IPv4 look like child’s play?

True, DirectAccess uses IPv6 communications as it’s foundation. All communications from the DA client to the UAG DA server are IPv6. This means that the client application on the DA client must be IPv6 aware. However, the server doesn’t need to be IPv6 aware, because UAG has a few tricks up its sleeve to make it all work.

In fact, the UAG DA server has enough technology built right in so that you can completely avoid any understanding of IPv6 and still get DirectAccess working on your network. Now, I’m the last guy in the world who would advocate that you should know nothing about the basic underlying networking technologies that run your solution. And I bet that once you get into the DirectAccess game, you’ll want to dig into IPv6 a little more. What you’re really concerned about is having to become an “IPv6 networking jockey” and end up in a 4 year long course of study on IPv6 before even getting started on DirectAccess.

As we say here in Texas “that dog don’t hunt”

And we don’t need that dog to hunt. Here are some of the technologies used by UAG DirectAccess that allow you to put some skin in the DirectAccess game without putting on an IPv6 propeller cap:

ISATAP – stands for the Intrasite Automatic Tunnel Addressing Protocol. The UAG DA server will set itself up automatically as an ISATAP router and provide your IPv6 aware hosts IPv6 addresses and routing information. ISATAP capable hosts include Windows Vista and above and Windows Server 2008 and above. What do you need to make this work? Not much. Enable your DNS servers to answer queries for ISATAP, enter ISATAP Host (A) records on your DNS servers, and make sure IPv6 is enabled on your network hosts (it’s on by default, but some people turn it off). That’s it! Now all your IPv6 hosts on the network have IPv6 addresses, and you didn’t have to do anything other than run the UAG DA wizard, configure the DNS server a little bit and not turn off IPv6 to make it work. No IPv6 jockey license required. Oh, and one more thing, since ISATAP tunnels IPv6 packets within an IPv4 header, routing within your IPv4 infrastructure will work just fine, no changes on your IPv4 routers required. None, not any.
6to4 – is a IPv6 transition technology that the DA clients and UAG DA server can use to connect the DA client to the UAG DA server over the IPv4 Internet. 6to4 is used when the DA client is assigned a public IP address. The IPv6 packets are encapsulated in a IPv4 header and send over the 6to4 tunnel adapter to the DA server. What do you need to do to make this work? On the client, nothing – it works automatically after you run the UAG DA wizard and have Group Policy applied to the DA client. On the server – again nothing. Just run the UAG DA wizard and apply the Group Policy to the DA server and it works. Again, you can know nothing about IPv6 transition technologies and it just works. IETF membership not required.
Teredo – is another IPv6 transition technology that enables the DA client to connect to the DA server over the IPv4 Internet. In this case, Teredo is used when the DA client is located behind a NAT device (either a NAT router or a NAT firewall) and the device allows outbound UDP port 3544. If the DA client has a private IP address and outbound access to UDP 3544, then the DA client uses Teredo to encapsulate the IPv6 messages from the DA client to the UAG DA server in an IPv4 header to send over the IPv4 Internet. What do you need to do to make this work? Like with 6to4, just run the UAG DA wizard, apply the Group Policies, and the DA client and UAG DA server are automatically configured to use Teredo. Holy Toledo!
IP-HTTPS – is yet another IPv6 transition technology that allows the DA client to connect to the UAG DA server over the IPv4 Internet. IP-HTTPS is a “last ditch” method to encapsulate the IPv6 packets in an IPv4 header. When the client is assigned a private IP address, and the NAT device or firewall is configured to allow only HTTP/HTTPS outbound, then the DA client falls back to IP-HTTPS. The reason why we consider IP-HTTPS to be a “last ditch” effort is that yout users are going to find IP-HTTPS connections to not be quite as “performant” as 6to4 or Teredo connections (assuming that they’ve been paying attention). This makes sense when you think about adding SSL to the already existing IPsec computational efforts and the extra protocol overhead involved with using HTTP as the transport. What do you need to do to make this work? Ha! Nothing – the UAG DA wizard creates the configuration, creates the Group Policy settings and all you need to do is wait for the Group Policy settings to be applied to the DA clients and UAG DA server and away you go. No muss, no fuss.
NAT64/DNS64 – NAT64/DNS64 (pronounced NAT 6 to 4/DNS 6 to 4) is a cool little piece of technology that the UAG team put together so that you can get DA working with the software assets you likely have running today. If I had to bet a quarter, I’d say that not everything on your network was IPv6 capable (that is to say, capable of running native IPv6 addressing or act as a ISATAP host). That would include all those Windows 2000 and Windows 2003 Servers you have on the network (yes, I know quite a few of you are still running Windows 2000). Since neither Windows 2000 nor Windows Server 2003 are IPv6 capable, you need a little help to get them to work with DirectAccess. No problem! NAT64/DNS64 accepts the connections from the DA client, automatically creates a IPv6 address for the name requested by the client, and then does a “NAT” kind of protocol transformation so that the IPv6 communication from the DA client is forwarded to the IPv4 only server on the network using IPv4. The response is returned to the DA server, which translates the IPv4 response into an IPv6 message that is returned to the DA client. Nice! But what do you need to know, what do you need to do to make this work? Enable two checkboxes in the UAG DA wizard. That’s it.

There you go. IPv6 for the UAG DA admin. The point is that you need to know very little if anything about IPv6 to get a production ready UAG DA server up and running. Will you benefit from getting to know some about IPv6? Sure, as you’ll understand what’s going on in the background and you can be more flexible in your deployment. Will you benefit from being an IPv6 jock? You bet! When you reach that level of sophistication you can start thinking about moving your corpnet into native IPv6, and use IPv6 aware routers, switches, NIDS and the rest. Knowledge is always power, but UAG DA already includes quite a bit of power on its own so it spares you from the rigors of intimate (or even passing) knowledge of IPv6.

So don’t fear IPv6. The seasons don’t fear IPv6, nor does the sun nor the wind nor the rain. You can be like they are! However, since 98%+ of you reading this are probably men, I’m not going to call you “baby” and I’m not “your man” :)

I’ll talk more about IPv6 concepts in the future on this blog and also in some guides I’m planning on putting out that will provide you with some “kissing cousin” familiarity with key UAG DA IPv6 concepts. Not enough to blow your mind, but enough where all the pieces will fall into place quickly so that you’ll maybe get jazzed enough to look into IPv6 a bit more when you have the time.

HTH,

Tom

Tom Shinder

tomsh@microsoft.com

Microsoft ISDiX\Anywhere Access Team

UAG DirectAccess

View article...

Portcullis Systems Announces the Unified Access Gateway Appliance

2010-03-12T06:21:28.6144735-05:00

Portcullis Systems Announces the Unified Access Gateway Appliance

Appliance offers the latest technologies for Secure Enterprise Application Access

MARLBOROUGH, Mass.--(BUSINESS WIRE)--Portcullis Systems, Inc., a global partner with Microsoft™ and HP™ (www.portcullissystems.com) today announced the Portcullis Systems Unified Access Gateway line of appliances. Available for immediate order, these appliances provide the latest technological breakthroughs to support organizational mobility and secure remote access to critical applications and data. Portcullis Systems UAG appliances are delivered on HP-based technologies to provide customers with the best, most reliable appliances and Enterprise-level support around the world. Availability is immediate and will be available through Portcullis Systems and their channel partners internationally.

“The addition of our proprietary management technologies, application acceleration and outstanding 24 x 7 global support provides incomparable value and a truly unique offering for secure remote access technology.”

Today, enterprises must allow for remote access to applications and valuable information to remain competitive and they must do this without jeopardizing security. This also must be accomplished in a manner that is acceptable to users. The Unified Access Gateway securely publishes resources to make them available to users while simultaneously improving security over traditional access methods.

Analyst Phil Schacter of Burton Group agrees. “With the increased mobility of the workforce, organizations need to expand their support for secure networking while safeguarding data center assets from compromised credentials or malware-infected devices,” he said. “The mobile workforce needs secure remote connectivity with transparent access to a range of data center services hosted on a mix of Windows and non-Windows servers.”

The Portcullis Systems Unified Access Gateway appliance will provide customers with functionality not available in a single offering before. Key features of the joint solution include:

Secure application access through a customized portal, created dynamically for each user based on their device type, location, authentication credentials, end-point status and more.
In-depth application knowledge allowing white-listing of valid traffic patterns for valid use, and blocking non-sanctioned transactions or security threats. This can be used to block or allow functionality within an application (e.g. Provide access to Outlook Web Access, but block the ability to upload or download files within OWA).
Support for Microsoft DirectAccess, allowing direct network connectivity regardless of the location of the end-user.
The addition of Ballista™ Application Acceleration technology to improve application performance to end-users connecting via the gateway.
Both iLO and PSAM management systems to provide full management capability of your Portcullis Systems appliance estate, regardless of their geographic location.

“Our appliances allow our customers to provide secure application and data access to end-users, business partners and their customers from a wide variety of devices in a very secure manner that is consistent with their security policies,” said Michael Oldham , CEO at Portcullis Systems. “The addition of our proprietary management technologies, application acceleration and outstanding 24 x 7 global support provides incomparable value and a truly unique offering for secure remote access technology.”

For information about the Portcullis Systems Unified Access Gateway, contact Portcullis Systems sales at sales@portcullissystems.com.

About Portcullis Systems

Founded in 2008 as a spin-off of NEI, formerly Network Engines, Inc., Portcullis Systems provides substantial expertise around the Microsoft Forefront Security products. As a recognized leader within their market, they provide significant value to their customers, above and beyond the value of the Microsoft applications that come as part of their appliances.

Portcullis Systems currently has hundreds of customers worldwide representing some of the world’s largest financial institutions, government ministries, defense departments, healthcare organizations and industry-leading enterprises.

Portcullis Systems is a privately funded company focused on network and applications security. With headquarters in Marlborough, MA, USA, Portcullis Systems also serves customers from its offices in the UK and through distributors throughout Europe, Middle East and Africa.

For more information, call (781) 996-4900 in North America,

+44 208 196 2420 +44 208 196 2420 for International, or visit www.portcullissystems.com.

Firewall Kernel Mode Tool integrated into Forefront TMG 2010

2010-03-12T06:18:17.866-05:00

Firewall Kernel Mode Tool integrated into Forefront TMG 2010

Feed: Forefront TMG (ISA Server) Product Team Blog
Posted on: Monday, March 08, 2010 12:13 PM
Author: isablog
Subject: Firewall Kernel Mode Tool integrated into Forefront TMG 2010

You can use the Firewall Kernel Mode Tool (FWEngMon.exe) to analyze and troubleshoot firewall connectivity issues by monitoring the Forefront TMG kernel-mode driver (fweng.sys). For example, you can use fwengmon to monitor all the listeners created by Forefront TMG, since not all of them appear in the output produced by netstat.

Starting with Forefront TMG 2010, fwengmon is integrated into Windows 2008 network shell (netsh) on the Forefront TMG server; you no longer need to download it separately.

For information on how to use fwengmon on Forefront TMG, see Yuri Diogenes's blog Where is fwengmon on Forefront TMG 2010?

Author:
Rachel Aldam, Technical Writer, Forefront TMG

Reviewer:
Jim Harrison, Program Manager, Forefront TMG

View article...

Why Microsoft DirectAccess Represents a Real Paradigm Shift

2010-03-02T17:49:30.111-05:00

Why Microsoft DirectAccess Represents a Real Paradigm Shift

Feed: The Edge Man
Posted on: Tuesday, February 23, 2010 8:37 PM
Author: tshinder-msft
Subject: Why Microsoft DirectAccess Represents a Real Paradigm Shift

DirectAccess is a new remote access technology enabled by the combination of Windows Server 2008 R2 and Windows 7. Unlike other remote access technologies such as reverse proxy, reverse NAT, SSL VPN gateways, and network layer VPNs, the goal of DirectAccess is to extend your network to any location in the world, so that your domain member client systems are always connected to the corpnet.

Think about the mix of remote access technologies you use now. Some of them might be in place to support partners, for which you want to provide very limited network access. But what about your employees? If you’re like me, you’ve probably spent most of your professional life trying to figure out how to give employees the information they need, in the most efficient way possible, so as to create the least frustration for both the employee and the Help Desk and IT overall. Most of all, you want to make sure this access is secure and that security doesn’t interfere with productivity.

There have always been two major stumbling points when providing productivity-enabling remote access to employees:

Employees often found it difficult to get the remote access solution working, or when they did, found the experience limiting in some way and therefore became less productive compared to when they were in the office
IT found it difficult to manage the security of the devices their employees were connecting from. Even in the ideal situation where you gave an employee a laptop with the corporate “golden image”, that image often fell out of compliance because the client system was not connected to the corpnet often enough to have the appropriate configuration settings applied through Group Policy or other desired configuration methods, such as System Center Configuration Manager. In addition, it was difficult to keep track of your off-campus fleet, since you never knew when they were going to connect to the corpnet again, if ever.

When you think about it, neither you nor your users ever wanted to use VPN. You never really wanted your employees to have to use SSL VPN gateways. You never actually wanted your users to have to gain access to resources over reverse proxies and NAT devices. You never really wanted to use any of the myriad number of remote access “artifices” that you’ve put in place.

But you did, because your goal was to provide your business an advantage by delivering out of office users access to information so that they could get their work done from anywhere.

But these solutions didn’t really didn’t do what they were supposed to do – at least not for you and your employee users:

How many times have you gone to a hotel an found out that it did not support PPTP or L2TP/IPsec?
How many times have you had all VPN access denied to you from your out of office location?
How many times have you had to deal with network ID collisions between the network you were on the corpnet ?
How many times did you need to use a web version of the application you wanted to use, because you couldn’t establish a VPN?
How many times have users called you or your help desk because the VPN connection did not work from the hotel room, conference center, partner network or customer’s office?
How many times did your users call regarding forgetting which name to use to connect to a resource when they’re out of the office, which of course is a different name when connected to the corpnet?
How many times did you wish that you had the same command and control over all your managed, domain member computers, regardless of their location?
How many times did you wish that all you had to do is turn on your computer, and you could connect to all the resources you were authorized to connect to, regardless of your location – the only thing you had to remember is to turn your computer on and enter your credentials?

No, we didn’t want these remote access solutions for our employees, but they were the best we could do.

What we actually wanted all this time was DirectAccess.

I can tell you that as a user, DirectAccess becomes a transformational experience. It completely changes the way I approach my work. In the past, if I left the office, I anticipated the traditional road warrior’s “negotiations with the remote access gods”.

The negotiations went something like this:

Please don’t assign me an address on the same network ID as my office
Please let L2TP/IPsec work
Please let PPTP
Please let secure Exchange RPC work
Please allow RDP to work
Please allow more than just HTTP/HTTPS outbound

You just never knew what the computing experience was going to be. If the network layer VPN worked, then almost everything worked. Of course, I’d have to fire off the VPN client first, and make sure the client was configured correctly (easy for me, not so easy for the average or even above average user). If neither network layer VPN protocol worked, then I spend my time living the second-class life of browser based applications. And file access experiences ranged from problematic to catastrophic.

There were often workarounds, but I could employ them because I’ve been doing networking for a long time. Average users would give up, call the Help Desk or try their best to do what they could with what they had – with the end result being a significant compromise in productivity and a flagging faith in the entire remote access experience and reduced expectations for what could be done when away from the office.

DirectAccess changes the game. Not only the game, but the entire playing field. So many of the problems related to remote access technologies that I’ve described so far are due to the users “location awareness”. While location awareness in the software is a very useful thing (and used by DirectAccess in the background), it’s not something you and your users want to worry about.

It’s the entire “location awareness” issue that creates problems for users:

Am I going to be able to use VPN?
What Web site URL do I use?
Am I going to have to reconfigure my application to work on the outside?
I’m going to have to do things differently when I’m on the outside

This “location awareness” creates both conscious and unconscious friction with the surface of user productivity. Energy is wasted and productivity is reduced. With DirectAccess, the entire “location awareness” issue is a non-issue. When you and your users connect with DirectAccess – the experience is the same all of the time.

The computing experience at work is the same
The computing experience at the ball game is the same
The computing experience at the hotel is the same
The computing experience at the conference center is the same
The computing experience at the customer site is the same

How is the computing experience the same in each of these scenarios? Because the following describes the computing experience for all five of the scenarios listed above:

Turn power on or wake the computer from sleep
Log on with your user name and password, or smart card and pin
Connect to corporate file shares, web sites, SharePoint sites, SQL servers, Exchange Servers, and just about any other server you can think of using their native application layer protocols
Close the computer lid and put the computer to sleep

Notice there was no “starting the VPN connection” or “connecting to the SSL VPN portal page” or anything else that required the user to be “location aware”.

This is what makes DirectAccess the paradigm shifting, transformational technology it is. And what really proves the point is how quickly you will take it for granted. That is a key component of what I consider to be transformational technology – you take it for granted because it was always supposed to be this way. In fact, you’ll find that the technology, over time, will seem boring to you. And for new computer users who have never experienced DirectAccess , they will find it really boring – or at least not exciting or transformational, because they will assume that is how remote computing should have always been done.

The story on the IT side of the house is just as compelling. Now you have access to the DA clients anytime a DirectAccess client is turned on; the user doesn’t even need to be logged on. You can apply patches, do “just in time” updates, install software, remove software, perform real-time remote management and configuration or assistance over RDP, and many more management tasks because the connection between DA clients and management servers is bidirectional and always available between the management servers and DA clients.

Your DA clients will be in the same state of compliance as machines that never leave the corpnet and they have access to all the management, command and control systems you use to manage any machine on the corpnet.

The reason is that DirectAccess allows you to extend the corpnet and its management infrastructure to the DA client.

I know that you’ve heard about “paradigm shifts” and “transformational technologies” in the past. IPsec server and domain isolation had that potential. But it never caught on. Network Access Protection, something I can remember hearing a number of people at TechEd 2004 demand “I need it now!” But after it was released, sort of “hung in the stretch” (to use a horse racing term). Why? I don’t know if there are any official reasons why, but I suspect that these two fantastic, potentially game changing technologies were just too complex and the expected return on investment for dealing with such a level of complexity ended up being too low.

This can’t and must not happen to DirectAccess – there are two main reasons why I don’t see DA “dying on the vine”:

Although some in the media have communicated that it is complex, in fact, there are far fewer moving parts that you might think – most who consider it overly complex have not tried to set it up
Many of the moving parts are already deployed on your network and you can easily integrate them into your DirectAccess deployment
The gains in improved manageability will more than pay for the time it takes to learn the new technology
The gains in end user satisfaction and increased productivity will not be incremental, they will be differential – meaning that end user productivity will increase significantly after DA is deployed, and will continue to increase over time as the frictionless DirectAccess experience is fully integrated into the computer users’ ways of working

So there you have it – my reasons why DirectAccess will change the world, and it’s a world that both IT and end-users have always wanted to live in.

It’s also a world that I want to help you get to. In the following months this blog will be dedicated to UAG DirectAccess and provide you hints, tips, tricks, ideas, opinions, workarounds, designs, and experiences that will speed your path to DirectAccess deployment. Because the only way you’ll really know the joy of the DirectAccess experience is to experience it. And after that, you’ll take it for granted – but you’ll be taking for granted an all new world of computing – one that allows you to get more done faster without ever needing to think about where you are.

HTH,

Tom

Thomas W. Shinder MD

Microsoft ISDUA – UAG DirectAccess – Anywhere Access Team (AAT)

tomsh@microsoft.com

View article...

Why Split Tunneling is Not a Security Issue with DirectAccess

2010-03-02T17:44:14.074-05:00

Why Split Tunneling is Not a Security Issue with DirectAccess

Feed: The Edge Man
Posted on: Tuesday, March 02, 2010 7:24 AM
Author: tshinder-msft
Subject: Why Split Tunneling is Not a Security Issue with DirectAccess

As a member of the Anywhere Access Team with a primary focus on UAG DirectAccess (DA), one of the questions that I hear a lot relates to the security of the solution, due to the fact that split tunneling is enabled by default.

If you’re a VPN guy, you are probably aware of the issue of split tunneling. When split tunneling is disabled, the VPN client uses the VPN gateway as its default gateway, so that all off subnet communications must go through the VPN gateway. It also prevents the the VPN clients from potentially routing communications between two networks, such as the client’s network and the corporate network.

For this reason, most experienced VPN admins disable split tunneling by default. This has become a habit for VPN admins and they don’t think twice about it. However, what they gain in security is lost in performance for the corporate Internet connection.

The reason for this is that the VPN client must go through the VPN gateway to access Internet content, so that the request/response path for Internet content is from the VPN client, to the VPN gateway, to an Internet gateway on the corpnet, to the Internet, and then the response is returned using the same path in the opposite direction.

As you can imagine, if you have more than a few VPN clients, this could become a major bottleneck on your Internet bandwidth.

The DA team understands this problem very well. If the DA client connection isn’t highly performant, users will likely be unsatisfied with the solution. The productivity gains you expected will evaporate, as users won’t use DA to connect to the corpnet, and they’ll return to their old inefficient ways of working.

So, DirectAccess by default enables split tunneling. All traffic destined to the corpnet is sent over the DA IPsec tunnels, and all traffic destined for the Internet is sent directly to the Internet over the local interface. This prevents DA clients from bringing the corporate Internet connection to its knees.

However, it has left the issue of potential risks of split tunneling in the minds of admins who are considering DA. One option is to use “force tunneling”. You can find out more about force tunneling at http://technet.microsoft.com/en-us/library/dd637812(WS.10).aspx One of the primary disadvantages of force tunneling is reduced performance, especially in the context of reaching IPv4 only resources.

But this begs the question: is DA split tunneling really a problem? The answer is no.

Why? Because the risks that exist with VPNs, where the machine can act as a router between the Internet and the corporate network is not valid with DirectAccess. IPsec rules on the UAG server require that traffic be from an authenticated source, and all traffic between the DA client and server is protected with IPsec.

Thus, in the scenario where the DA client might be configured as a router, the source of the traffic isn’t going to be the DA client, and authentication will fail – hence preventing the type of routing that VPN admins are concerned about.

HTH,

Tom

Tom Shinder
Microsoft ISDUA
Anywhere Access Team/UAG DirectAccess

View article...

Increase DirectAccess Deployablility

2010-02-24T15:51:33.921-05:00

Increase DirectAccess Deployablility

Feed: Forefront Experts
Posted on: Monday, February 15, 2010 11:39 AM
Author: Hal Berenson
Subject: Increasing DirectAccess Deployability

Andrew Garcia over at eWeek has written an excellent article describing his experience testing Microsoft Forefront UAG 2010's capabilities for assisting deployment of Microsoft Windows' DirectAccess. I thought I'd add a little color commentary to the deployment topic..

A little over a year before the release of Windows 7 and Windows Server 2008 R2 the UAG team looked at what it could do to incorporate DirectAccess as a technology in its overall "access" mission. Later, a Microsoft-wide virtual team looked into what we could do to accelerate DirectAccess deployment. These two activities have already born fruit, both in new features in UAG 2010 and the new DirectAccess Connectivity Assistant.

As an example, one of the key features UAG brings to the DirectAccess deployment story is support for the DNS64 and NAT64 IPv6 transition technologies. The "64" refers to "6-to-4", as in IPv6 to IPv4 (as oppsed to the common usage implying something to do with 64-bits). DNS64 and NAT64 are the latest technologies for allowing IPv6 clients to communicate with IPv4 servers. They are in the process of replacing the earlier DNS-ALG and NAT-PT technologies that were found to be flawed and moved to historical status by the Internet Engineering Task Force (IETF). As a result of DNS-ALG/NAT-PT's status customers may not be willing to deploy them and vendors (some of whom already support these technologies in shipping products) may not want to advocate their use. That left a big gap for customers considering deployment of DirectAccess, how to enable communications with servers that only support IPv4? UAG 2010 stepped in to help and is the first product to bring the newer DNS64 and NAT64 to market. Others will certainly follow as the need to enable transition to IPv6 becomes more urgent.

Although not part of UAG, the Microsoft DirectAccess Connectivity Assistant (DCA) is another important part of our efforts to accelerate DirectAccess deployment. One piece of feedback we received from early adopters of DirectAccess was that their end-users loved DirectAccess so much that when it didn't work they were quite vocal about their frustration. Perhaps it worked just fine from their home or hotel, but not when they were in their favorite coffee shop. The lack of an indicator that DirectAccess was "on" and working properly added to end-user frustration. The lack of an easy way to gather and deliver diagnostic information to IT, so they could help solve the problem, raised support costs. DCA displays the status of DirectAccess connections in the Windows 7 notification area, gives the end-user assistance in solving connectivity problems, and provides diagnostic information should IT need to get involved in resolving connectivity problems. DCA is now available for download on TechNet.

Making products easily deployable is a major focus for the Identity and Security Division and customers should start to see the result as we roll out new products. For DirectAccess we continue to drive a Microsoft-wide effort to accelerate deployment. In the short run you'll notice an increasing amount of deployment guidance becoming available. I urge you to keep an eye on the Forefront UAG Product Team Blog for announcements as well as for hints and deep dives to help with your UAG deployments (DirectAccess and otherwise).

View article...

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall

2010-02-23T10:04:07.336-05:00

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall

There is a pretty good 3 part tutorial over on ISA Server.org by Deb Shinder on setting up an Email Hygiene solution on the new TMG Firewall. This is a powerful solution but care must be taken to install things in the right order. The tutorial provides step by step instructions with screen shots.

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall – Part 1: Installation.

Installing and Configuring the E-mail Hygiene Solution on the TMG 2010 Firewall – Part 2: E-Mail Policy.

Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall – Part 3: Configuring AntiSpam Policy.

Snowstorms Pummel Worker Productivity, Citrix Survey Finds

2010-02-19T08:54:11.427-05:00

Snowstorms Pummel Worker Productivity, Citrix Survey Finds

Published Friday, February 12, 2010 5:27 PM by David Marshall

Behind the traffic pile-ups, cancelled flights and power outages caused by recent record storms in the Middle Atlantic States, there’s another sobering story – the enormous cumulative loss of business productivity caused by employees’ inability to work from home when commuting became impossible. A survey of 500 people in four states and the District of Columbia, commissioned by Citrix Online, found that 52% of respondents have lost six or more hours of work due to this winter’s severe storms; this represents a potential loss of nearly 50 million total man hours of productivity in these states. Half have been forced to cancel or delay a meeting in the last year due to inclement weather. Further, 47% stated they have no technology tools, flex time, telework provisions or alternate assignments to assist when commuting is a problem.

“Enabling your employees to work from anywhere is simple,” said Chuck Wilsker, President and CEO of the Telework Coalition and a member of Citrix Online’s Worldwide Workplace Council. “The keys are to plan ahead, determine the specific needs of your organization, identify best practices for managing your virtual workplace, and using technologies, which are both suited to productivity and can address your benchmarks for success. The first application I ever used that allowed me to work remotely was GoToMyPC and it’s still a wonderful solution. Citrix Online’s Worldwide Workplace Council has authored a paper outlining the five steps to a virtual workplace program.”

For example, Ira H. Siegal, CPA, of Bala Cynwyd, Pennsylvania, an affiliate of 123College.com, inc., turned to GoToMeeting when he saw that snow threatened to prevent attendees from coming to a seminar last week. He recalled, “As I watched the snow get deeper, some of the people who had registered to attend my seminar started to question whether it would occur. I polled them, and they said they would have trouble shoveling out their cars and navigating the roads to make it to my event. I realized I needed a back-up plan, and decided to conduct an online seminar instead. GoToMeeting saved the day for me, and allowed me to conduct business from the safety of my home.”

The Citrix Online survey, which covered New York, New Jersey, Pennsylvania, Virginia/D.C., and Maryland, found that 38% of respondents were unable to commute to work at least once during the storms in December 2009 and January and February 2010. For many, this meant a lost day of productivity; results revealed 50% of those surveyed had no work situation away from their office.

For more information about Citrix Online, a division of Citrix Systems, Inc. (NASDAQ: CTXS), or Work Shifting, visit http://www.citrixonline.com/ or http://www.workshifting.com/.

Filed under: Survey

Microsoft DirectAccess Connectivity Assistant

2010-02-19T08:34:40.868-05:00

Microsoft DirectAccess Connectivity Assistant

Feed: Bink.nu
Posted on: Saturday, February 13, 2010 4:48 PM
Author: Steven Bink
Subject: Microsoft DirectAccess Connectivity Assistant

Check out the Microsoft DirectAccess Connectivity Assistant, the newest edition to the Windows® Optimized Desktop Toolkit 2010 to help reduce costs and improve the experience of DirectAccess.

The Microsoft DirectAccess Connectivity Assistant (DCA) helps organizations reduce the cost of supporting DirectAccess users and significantly improve their connectivity experience.

DCA informs mobile users of their connectivity status at all times; provides tools to help them reconnect on their own if problems arise; and creates diagnostics to help mobile users provide IT staff with key information if necessary—all to help customers operate with more efficiency, and at a lower cost.

DCA is the newest addition to the Windows® Optimized Desktop Toolkit 2010, which is designed to help IT pros plan, deliver, and operate the right desktop technologies for users across their organization.

The download includes the following components:

Microsoft_DirectAccess_Connectivity_Assistant.zip
Microsoft_DirectAccess_Connectivity_Assistant_x32.msi
Microsoft_DirectAccess_Connectivity_Assistant_x64.msi
Microsoft_DirectAccess_Connectivity_Assistant_DeploymentGuide.docx
Microsoft_DirectAccess_Connectivity_Assistant_Release_Notes.en.htm
DirectAccess Connectivity Assistant GP.admx
DirectAccess Connectivity Assistant GP.adml

Download details DirectAccess Connectivity Assistant

Send via e-mail | Submit to Digg | Add to Live Favorites

View article...

Forefront TMG 2010 Email Protection Updates

2010-02-12T13:34:33.162-05:00

Forefront TMG 2010 Email Protection Updates

^{This
recent article was published at}^{Tales
from the Edge}^{, that explains how
to configure Exchange Sync with Forefront TMG 2010, here it is the link for it:}^{http://technet.microsoft.com/en-us/library/ee513174.aspx}^{.
Also, here is a reminder about the supported scenarios with Forefront TMG 2010 and
Exchange 2007 Edge role, for the support matrix click}^here^.

^{From: http://blogs.technet.com/isablog/archive/2009/11/10/email-protection-in-forefront-tmg-2010-release-candidate.aspx}

^{The
* on this table says:}

^{Recently
a blog post was published by the Exchange team saying that they reconsidered and are
planning to support Windows Server 2008 (SP2). To read more about it please follow
this link: http://msexchangeteam.com/archive/2009/11/04/453026.aspx}

^{There
is a newer update on that, which is the one below:}

^{“…we
will be adding support for Exchange 2007 on the Windows Server 2008 R2 platform.
While we had hoped to add this application/operating system combination quickly, unfortunately
adding this support requires code changes to setup in Exchange 2007. Therefore,
our vehicle for adding this support will be via a third Service Pack for Exchange
2007 in the second half of calendar year 2010.”}

^From:^{http://msexchangeteam.com/archive/2009/11/30/453327.aspx}

^{In
other words: If you want to deploy Exchange 2007 Edge role on Forefront TMG 2010 you
will need to:}

^{Windows
Server 2008 SP2}
^{Exchange
2007 SP2}

^{If
you already installed Forefront TMG 2010 on Windows Server 2008 R2 and want to install
Exchange Edge role to enable EMail Protection feature your current supported options
are:}

^{Install
Exchange 2010 Edge Role}
^{Wait
for Exchange 2007 SP3 to come out so you can install Exchange 2003 Edge Role on Windows
Server 2008 R2}

^Author

^{Yuri
Diogenes}^{Sr
Security Support Escalation Engineer

Microsoft CSS Forefront Edge
Team}

^{Technical
Review}

^Noam
Ilovich^{Program
Manager

Microsoft Forefront Edge
Team}

^{View
article...}

Forefront TMG 2010 Web Protection Services Licensing

2010-02-12T13:13:38.605-05:00

Forefront TMG 2010 Web Protection Services Licensing

Introduction

Forefront TMG 2010 adds two new subscription-based features, known collectively as Forefront TMG Web Protection Services (WPS). These features include URL Filtering (URLF) and Anti-Malware or Enhanced Malware Protection (AM or EMP). One thing that makes these features unique within Forefront TMG is that they are licensed separately from Forefront TMG itself. This blog will discuss the various licensing and purchasing options available for URLF and EMP subscriptions and guide you through managing the license details in Forefront TMG management.

WPS Purchasing and Pricing

The first thing most people want to know is “How do I get a Forefront TMG WPS license and how much does it cost?”

Forefront TMG WPS is subscription product licensed per user or per device. This subscription is only offered through Microsoft Volume Licensing programs, and must be purchased separately from Forefront TMG 2010. Forefront TMG WPS is included in Forefront Protection Suite and ECAL. You can find information on purchasing Forefront TMG WPS through Microsoft or a Microsoft partner at http://www.microsoft.com/forefront/threat-management-gateway/en/us/purchase.aspx.

The Forefront TMG WPS pricing structure is outlined in http://www.microsoft.com/forefront/threat-management-gateway/en/us/pricing-licensing.aspx.

Verifying the Evaluation License

You may want to take advantage of Forefront TMG WPS while you wait for your license to arrive; or perhaps you want to give WPS a test drive before you decide whether you want to purchase a license. Regardless, TMG provides a free 120-day trial subscription that goes into effect as soon as you deploy Forefront TMG 2010.

Using the Getting Started Wizard (GSW)

The Getting Started Wizard (GSW) provides one way to configure these options. During this process, you can choose to enable HTTPS Inspection, URLF and EMP as well as whether to use the evaluation license (selected by default). The following steps show you where you make these choices in the GSW.

Note: if the TMG computer is a member of an array, the GSW is not available. In this case, you must use the Without the GSW steps

View article...

Direct Access FAQ's

2010-02-04T11:04:26.911-05:00

Still confused about what Direct Access really is and what it can mean for your business? Bookmark the DirectAccess FAQ for answers to many of your DirectAccess questions. Learn how your users can be seamlessly and securely connected to your network any time they have an internet connection. Keep your users up to date with security and system health policies using DirectAccess.

Forefront TMG Best Practices Analyzer Version 8

2010-02-04T11:02:17.515-05:00

Announcing the Forefront TMG Best Practices Analyzer Version 8 ! This announcement discusses new features and functions found in the latest release of the Best Practices Analyzer tool, including URL Filtering, ISP Redundancy, HTTPS Inspection, Anti-Malware protection and much more!

Forefront TMG Case Studies

2010-02-04T10:46:46.131-05:00

Forefront TMG Case Studies – Many of our customers will wait a while and look to see how a software product performs in the real world before making the decision to adopt a new technology. The same goes for the Microsoft Forefront TMG product, the successor to the popular and proven Microsoft ISA technology. Customers want to know why TMG is being adopted, why they should change from their current ISA platform, and what benefits they will realize when they decide to make the move. A great way to answer those questions is through real world case studies such as those found here where customer testimonials can help illustrate some of the benefits found in Microsoft TMG.

Microsoft Forefront Unified Access Gateway Product Team Blog : Forefront UAG RTM documentation now live on TechNet

2010-01-14T12:11:37.6060805-05:00

Forefront UAG RTM documentation now live on TechNet

Published 13 January 10 12:15 PM

The complete library of Forefront UAG RTM content is now available on the Library tab of our Forefront UAG TechCenter. This content release is the result of a joint effort coordinated by the UAG User Experience team, in conjunction with the product group, field and support engineers, our community and customers. Together we planned, developed and reviewed the library content, in order to expand and improve the UAG ITPro documentation experience.

To read the whole article, go to the source.

Source - Microsoft Forefront Unified Access Gateway Product Team Blog : Forefront UAG RTM documentation now live on TechNet

Windows Virtualization Team Blog : Big news: Microsoft and HP team up to move IT forward

2010-01-14T11:46:59.529785-05:00

Big news: Microsoft and HP team up to move IT forward

This morning Microsoft and HP announced a three-year, $250 million agreement to jointly deliver a new infrastructure-to-application model, advance cloud computing and generally reduce the costs and complexities of IT.

The press release, executive videos and other information about the agreement are available here.

This is a big commitment on the part of both companies, representing the industry’s most comprehensive technology stack integration to date. There are three main components to the agreement:

· A shared engineering roadmap to ensure strong integration between hardware and software - both on premises and in the cloud.

· Joint solutions to optimize and simplify the deployment, management and health of the datacenter.

· Investment in joint sales, service and channel partner programs

Virtualization is (of course) at the center of the partnership. New solutions based on HP Converged Infrastructure with Microsoft Hyper-V and applications will enable customers to speed up implementation time, reduce unplanned downtime, and lower network/cabling infrastructure costs. And they will help customers deliver service-based infrastructure and the foundation for cloud computing.

Windows Virtualization Team Blog : Big news: Microsoft and HP team up to move IT forward

Microsoft Forefront Server Protection Blog : Forefront DNSBL… Yeah or Nay?

2010-01-14T11:42:47.0469215-05:00

Microsoft Forefront Server Protection Blog

The official blog of the Forefront Server Protection product team.

Forefront DNSBL… Yeah or Nay?

As you might guess, DNSBL stands for DNS Blocklist. While it’s not a new technology, the usefulness of various DNS/RBL blocklists in fighting spam is indisputably immense. Over the years I’ve heard both the success stories from folks who implemented RBLs in their Exchange server deployments, and I’ve heard some horror stories from the folks who’s IPs were maliciously or mistakenly added to RBLs and the difficulties they had working with blocklist providers to delist their IPs from the RBLs. Another contributing factor to the overall painful experience with RBLs is the fact that you need to configure them with appropriate response codes and delisting logic etc. It’s manual work and as such is very error-prone. Also, some of the blocklist providers will expose their lists for free to small customers only. For example, they will allow only a certain number of queries against the blocklist per day and if the query volume exceeds the allowed (and very small in reality) free amount they will either block the queries (firewall) or ask the customer to receive the blocklists via paid subscription. If you are going to use a free DNS blocklist, you need to make adjustments (lower expectations) regarding the quality of service. Considering these factors, some Exchange admins prefer to stay away from blocklists because they just do not want to go through the headache generally associated with maintaining multiple RBL providers’ configurations.

For more info go to the source

Source - Microsoft Forefront Server Protection Blog : Forefront DNSBL… Yeah or Nay?

Forefront Team Blog : Forefront Unified Access Gateway 2010 unleashed

2009-12-21T09:55:12.723808-05:00

Forefront Unified Access Gateway 2010 unleashed

As previewed earlier this month, Forefront Unified Access Gateway (UAG) 2010 has been released to manufacturing. The evaluation software is now available here.

Part of our Business Ready Strategy, Forefront UAG enables organizations to give employees (and trusted partners and vendors) secure remote access to corporate resources. With its focus on application intelligence and granular access control, UAG is an ideal solution all of your remote access needs that provides centralized management and policy control across all users, devices, and network resources.

Building on its predecessor, Intelligent Application Gateway, UAG enables remote access via managed and unmanaged PCs and mobile devices. It integrates a deep understanding of applications, the health state of end user devices, and the user’s identity for greater security and reduced management costs.

While UAG provides a variety of connectivity options, such web publishing and SSL VPN tunnels, one of the best new features is UAG’s support and enhancements for Windows DirectAccess (DA). DA is the future of remote access allowing for seamless, always-on connectivity. Always-on keeps users happy as they are continually productive, but it also keeps administrators content as users are “always-managed.” UAG helps make DA deployments simpler, more extensible and easier to scale

The Solution Accelerator team has released a new guide for UAG which outlines the critical infrastructure design elements that are key to the successful implementation. Use this guide to shorten your Forefront UAG infrastructure planning and deployment time!

· Download the IPD Guide for Microsoft Forefront Unified Access Gateway.

· Visit the Forefront Unified Access Gateway page on TechNet to learn more.

Forefront Team Blog : Forefront Unified Access Gateway 2010 unleashed

Forefront TMG (ISA Server) Product Team Blog : Redirection to OWA 2007 Directory in ISA 2004/2006

2009-08-24T22:30:07.8503945-04:00

Redirection to OWA 2007 Directory in ISA 2004/2006

Introduction

Recently I have seen a fair number of cases where ISA Administrators were trying to redirect connections made to the root OWA Web site to the /owa folder when publishing Exchange 2007 through ISA Server 2004/2006. In these particular cases they were using a documented trick for Exchange 2003 that involves entering a path on the OWA rule that looks like this /exchange\ . The trick is documented here and works quite well for Exchange 2003. The problem is that people believe it should also work for Exchange 2007. When they try this method they end up with a garbled inbox with a lot of red Xs showing up as shown in Figure 1: See more at the SOURCE

Source: Forefront TMG (ISA Server) Product Team Blog : Redirection to OWA 2007 Directory in ISA 2004/2006