Microsoft delivers feature-rich SSL-VPN ~ Assuntos de Redes e Afins

This story appeared on Network World at
http://www.networkworld.com/reviews/2010/030810-microsoft-forefront-ssl-vpn-test.html

Forefront Unified Access Gateway is enterprise-grade, software-based remote access tool

By Joel Snyder, Network World
March 08, 2010 12:07 AM ET

Authorization angst

SSL VPNs start by authenticating the user, so we tested that first. Most deployments will probably use the built-in Active Directory links, which is a good thing, because we had a difficult time making any of the alternative authentication options work.
Officially, UAG offers a wide variety of other authentication sources, including RADIUS, several LDAP directories, as well as more obscure methods. We tested the ones we thought would be most useful, including Active Directory, LDAP, RADIUS and SecurID.
The good news is that we were able to make authentication work with all sources, with only minor restrictions. LDAP authentication, always one of the biggest bugaboos, is helped in UAG by the creation of templates for some common LDAP servers. However, if you have chosen to make any adjustments to the schema of those servers, you won't be able to use them with UAG. Since our server looked mostly like a standard Netscape LDAP server (one of the choices), we were able to authenticate successfully.
Where we ran into problems was in the authorization side of the house. In SSL VPNs, authorization is a critical feature that lets you build security policy differently for different groups of users. Most SSL VPNs, UAG included, use the concept of "groups" to provide access control.
We wanted to see how well we could get group information out of our authentication servers to the UAG. We found that UAG wouldn't work properly with any of the servers we tried, for different reasons each time.
With LDAP, since our server didn't match exactly the schema that UAG had built-in, our group hierarchy wasn't available, and UAG couldn't see it. With RADIUS, UAG's option to customize the extraction of group information was grayed out and, more importantly, we couldn't add these groups to our access control lists. With SecurID, we wanted to get group information out of Active Directory — a common approach for most enterprises using SecurID — but couldn't make that work either, even with a Microsoft guru on-site to help.

If your plans for UAG are exclusively built around a fairly standard Active Directory, and if you don't plan on using external sources for authorization (for example, if all authenticated users get the same services), then UAG's authentication features will be quick and easy to use. However, if you want to integrate your SSL VPN across other directory services besides Active Directory, UAG may not work well for you.

Endpoint security: Works fine on Windows

Endpoint security is a commonly-used feature in SSL VPNs because it lets the network administrator check compliance before letting a remote system connect to the VPN. Reflecting its pre-Microsoft heritage, Forefront UAG offers two separate ways of handling endpoint security: a comprehensive and extensive set of policy building blocks based on UAG-specific host checking software, or the option to simply defer to Microsoft's own NAC technology built into newer Windows distributions, Network Access Protection (NAP). If you want, you can also use both.
We dove deepest into the built-in policy tools, and found that we were able to create moderately sophisticated access control policies using a well-designed management system.
UAG offers the ability to define separate policies for the major operating system, Windows, Mac OS X and Linux. Each policy can have its own set of rules, defined using a typical Boolean logic. Our example policy let users in if they had Sophos Anti-Virus installed, running and up-to-date, along with either the Sophos or Microsoft personal firewalls installed and running. We tested to be sure that various "misconfigurations" would block us out, and UAG worked very well here.
UAG's capabilities for Mac and Linux didn't work as well, although it was not for lack of trying. UAG has a policy definition language for both these operating systems. For example, we could have checked for the presence of any of 10 different Mac OS X personal firewalls. In our policy, that's what we selected. With Apple's Safari and Google's Chrome browsers, UAG simply refused to even start its endpoint compliance checking. With Firefox, we got an endpoint compliance check, but a false positive: even with Apple's firewall turned on, we couldn't get in.
It's possible — even likely — that with sufficient rooting around in the depths of UAG and our Mac clients we could make this work, but our testing shows pretty clearly that it doesn't work well out-of-the-box on these operating systems. Your best bet is not to count on EPS checking working on non-Windows operating systems.
Fortunately, UAG provides a fine-grained way to control how endpoint security affects access. You can require endpoint security to "pass" before even letting the user log in as a start. And, you can apply individual (and different) policies to each resource you make available through the SSL VPN. This is probably more control than most network managers will want, but it's nice that you have that flexibility.

Access control at the application layer

One of the key features of an SSL VPN is a greater focus on who is connecting. This lets the SSL VPN manager enforce user-focused access controls, rather than simply allowing everyone who connects to go everywhere in the network. UAG gives the administrator the option to define access controls on every resource individually, as well as to create virtual systems (UAG calls them "trunks") that have separate sets of resources, portal configurations and access controls.
For user-based controls, the network manager can block or allow access on an application-by-application basis at the user ID or group level (or both). In addition, UAG makes a distinction between "upload" and "download" type activities. These aren't done at the user/group level, but at the application level. This means that you can, for example, prohibit all authenticated users from uploading .MP3 files to your Exchange Webmail server, but allow them to download them.
A third type of access control is the ability to broadly control allowed and disallowed URLs for every Web-based application available through the UAG gateway. This URL-specific application control is one of the bits of nice intellectual property in the UAG SSL VPN that isn't found in most other SSL VPNs.

Click to see: Net results/score card

UAG isn't necessarily a full-fledged application-layer firewall, but it has a considerable amount of intelligence about what is acceptable for Web traffic through the VPN. This helps to reduce the possibility that an authenticated user will try to crack through internal applications, because UAG doesn't allow URLs that aren't allowed for that particular application.
Of course, giving UAG the capability to understand what is and isn't legal for each of your applications doesn't happen without some work. UAG has built-in to its configuration knowledge of all of Microsoft's major enterprise applications, including Exchange Server, Office Communicator and SharePoint. (This is a change from earlier versions of UAG, which also had support for non-Microsoft applications.) If your own application isn't included, you can write rules using UAG's GUI to add it to the configuration, or you can simply let the defaults take effect.
The one place where UAG's access controls really didn't measure up was in offering remote network access (usually called network extension). With network extension, the SSL VPN turns into a more traditional VPN concentrator, giving broad network access to users who have installed the (Windows only) client software.
However, access controls don't really apply within UAG. Instead, you use the underlying firewall that protects the UAG server, Microsoft's Forefront Threat Management Gateway, to provide broad-based access controls, but you can't apply them on a per-user or per-group basis through UAG. DirectAccess, Microsoft's new IPv6-based VPN technology, is included in UAG but also does not have any type of granular access controls.

Management: A mixed bag

Management is handled through a Windows-based application. The management tool can control a single UAG gateway, or a group of servers acting as a single gateway, but can't control multiple independent gateways. Generally, UAG management is well done and easy to use. We had a half-day of training from Microsoft during our testing and quickly felt comfortable with the application management. Although UAG sits on top of both Windows 2008 R2 and Forefront Threat Management Gateway firewall, you don't have to dive into either of those products very often.
The configuration tool also includes context-sensitive help which is, for the most part, quite well done. In many important areas, terms are not defined and necessary details are missing, so additional work is needed, but overall the help is there when you need it — an important feature in a product that comes without a manual.
UAG uses a commit model for configuration changes, although there is no versioning or rollback capability. However, when you do commit changes ("activate" in UAG), the gateway management interface takes care of any changes to the underlying TMG configuration. The commit step actually got annoying during our testing, because each change-test cycle requires about a 2-minute delay (on a very unburdened multi-core HyperV server) to activate, which slows down the cycle considerably.
Monitoring and logging tools showed mixed results in our testing. UAG includes a Web-based monitoring tool that can display the status of the entire UAG gateway, including relevant event log messages. During normal operations, this will probably be sufficient. However, debugging and troubleshooting tools are poorly handled. As we were trying our various tests, we were constantly in the dark about why and how something wasn't working. When UAG works right, you don't care; when it's not working right, you have almost no way to figure out what is happening or why there's a problem.
We found a number of unfinished edges in the product, such as in portal customization and network extension management, but following the 80/20 rule, most network managers will find their configuration and day-to-day management experience to be straightforward and efficient.

Impressive interoperability

One of the most important parts of an SSL VPN is the proxying of Web pages from the original server, through the VPN, to the end user's browser. With a ton of technologies on Web sites, including Flash and Javascript, and with techniques such as AJAX, this is getting harder each year.
We tested UAG with a full suite of Microsoft enterprise application servers, including Exchange 2007, Exchange 2010 and SharePoint. In each case, UAG was able to flawlessly pass traffic between the enterprise application servers and the client Web browser.
With our own Web applications, we had only one problem, with a Shockwave Flash site, which did not work properly when sent through the SSL VPN. However, Javascript, well- and poorly-constructed HTML all worked fine.
UAG's protocol translation facility only supports one application, CIFS file servers. Because all CIFS files are seen as a single "file sharing" link in the Web portal, you don't have much granularity of control at the SSL VPN layer. Instead, Active Directory credentials are passed down from the UAG system directly to the file servers and the end file server access controls define what files you can see and which you cannot.
In other words, UAG doesn't restrict access any more than the file servers already do based on group information. What UAG does do is provide access controls based on endpoint security status. For example, the test system we used blocked uploads if your antivirus was not up to spec, but downloads were fine.
We ran into a couple of bugs in the UAG file sharing. When used with a pure Active Directory authentication, everything worked smoothly. However, if we tried to log in to the UAG portal with one set of credentials and use a different set for file sharing, that wouldn't work. We also uncovered a bug when uploading larger files to the UAG file sharing server, with end users getting the dreaded "404 – File or directory not found" error rather than a more informative error message.
Network extension also worked well, with some limitations. UAG supports two different types of network extension. One is based on the original Whale protocol, and the other is based on Microsoft's SSTP protocol. Unfortunately, Whale supports XP and Vista, while SSTP is supported on Vista and Windows 7. This means that any company which has both XP and Vista needs to configure both methods, and have two different access points open.
That's not hard, and we had no problem setting that up. The bigger issue is user training, where Windows 7 users must use a different client and different procedure than Windows XP users. Also, because SSTP runs over Port 443 and Whale protocol doesn't, help desks may run into issues where one works but the other doesn't because of some intervening firewall.
The final area we tested was port forwarding, a technique for exporting single client-server applications. In Windows clients, this was easy to configure and worked well. We used the most common example, Microsoft's own terminal services, which is elegantly supported by UAG. We also tested VNC, a terminal server used in other operating system environments, and one of our own SQL client-server applications, without problems on Windows platforms.
One of the coolest features of UAG was single application forwarding. Using this feature, we could advertise a single application running on a server through the SSL VPN and keep the end user from getting all the way to the desktop. On our test Windows client system, this worked great. Application forwarding, which is based on an ActiveX control provided by Microsoft, isn't supported except in Internet Explorer browsers. Port forwarding also worked on both of our test Macintosh client systems.
In general, we found that UAG was very interoperable with most Web applications (Flash being the exception), application port forwarding, network extension and application forwarding when used in a Windows environment. We had less success and more frustration in the Mac world. Network managers will be able to use UAG and its associated tools to make their internal networks accessible in a safe and controlled way to staff outside the network boundary.

Portal customization conundrums

One of the main functions of an SSL VPN is to export Web-based applications, so the inevitable itch to tinker and fiddle with how the Web page looks strikes frequently. UAG doesn't make it particularly easy to customize the look-and-feel of the Web pages. Full control is there — as long as you feel comfortable diving into the middle of XML files, ASP.NET pages, and writing your own Javascript and Visual Basic.
A few customizations are easy to do. For example, having inaccessible applications (for example, because you're not allowed to run them) not show up on the portal is an important security consideration. UAG also has the concept of multiple types of devices: personal computers, handheld devices and mobile devices; you can block some applications from showing up on devices that can't support them.
On the other hand, some customizations that every other SSL VPN makes trivial are painfully difficult. Let's say you want to put your logo on the home page, and change the copyright notice. You can do it, but you have to navigate a 17MB Web site with 325 files and 35 directories to find the files that you need to update. UAG also does not support any user customization of their own portal, such as maintaining a set of personal bookmarks.
Another piece of portal functionality we tested was the single-sign-on capability. UAG makes it easy to provide single sign-on for applications that link to your Active Directory, simplifying the process for end users and probably increasing security along the way.
Other parts of single sign-on, though, such as saving Web-site specific credentials or using a static password for a Web site are not supported well, if at all. This type of authentication simplification is important when UAG is used as a portal to internal Web sites that aren't connected to Active Directory, or when you're using UAG as a reverse proxy portal to gain access to external Web sites. It's not a hard feature to implement — most other SSL VPNs do it just fine — but UAG doesn't have it.
In our testing, links to Web sites — especially Microsoft Web applications such as SharePoint and Exchange — that used cached credentials in Active Directory authenticated fine without requiring the user to re-login. We had varying success with non-Active Directory Web sites, depending on how the Web site requested login credentials.

Snyder is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.
Read more about security in Network World's Security section.
All contents copyright 1995-2010 Network World, Inc. http://www.networkworld.com

Assuntos de Redes e Afins

Linkbar

segunda-feira, 8 de março de 2010