Security & Mobility Now
Security is top-of-mind everywhere, especially right here where Juniper experts share their thoughts on the latest security breakthroughs and product advancements
ssl_boy

Best practices in selecting Secure Access methods – The thick and thin end of the wedge

by ‎12-08-2011 05:30 AM - edited ‎12-05-2011 02:00 AM

This is a guest blog post. Views expressed in this post are original thoughts posted by Glen Kemp, Solutions Consultant at SecureData Europe. These views are his own and in no way do they represent the views of the company he works for.

 

For an administrator “new” to the Juniper Secure Access family, the plethora of access methods can make it difficult to see the wood from the trees.  Despite the presence of resource policies, many just run to the “safe” security blanket of Layer 3 Network Connect/Junos Pulse Clients, but this is like buying a Rolls Royce and keeping chickens in it.

 

Choosing a Method

 

Within the IVE OS there are five major methods of providing remote access to a connecting user with graduated levels of control and compatibility.  At the “thin” end of the wedge (shown below), Core Clientless Access (CCA) provides very hi-fidelity control for a handful of application protocols.  At the “thick” end of the wedge, Network Connect and Pulse can support any TCP or UDP application, but destination control is limited to IP and port. In the middle are the Terminal Services and SAM access methods which offer “shades of grey” of access control between the extremes. In all cases, the source address will be a specific user in a specific context.  The context can be considered a combination of authentication mechanism, the security posture of the client device or even URL they used to reach the IVE.

 

Secure Access Methods Wedge

 

When configuring a new role your general approach should be to choose the access method which offers the finest control for a given resource or requirement.  Start at the top of wedge and work down till you reach the best compromise for compatibility versus fidelity of control.  Generally the “thin end” clients are the most portable and require the fewest user permissions to operate.

 

One access method is not expected to fit every requirement; sometimes you’ll need deep and flexible integration into the Citrix Web Farm, other times you’ll just need to publish a single RDP desktop for a developer. Access to a tightly configured CCA role would only require strong authentication to be satisfied to ensure basic access is available to everyone, everywhere.  The “thicker” clients should have additional requirements to meet such as directory group membership or host checks to ensure that deeper access is only given to users and devices with sufficient privileges and security posture.

 

Once you’ve chosen Secure Access/MAG as your primary VPN gateway you may well be displacing many “legacy” or non-dedicated VPN solutions such as on-firewall VPN clients. There should be an equivalent solution in all cases, but inevitably with a different modus operandi.  As a general approach it’s best to prototype access, get some feedback from a select user group, tweak and then roll out to a bigger group of users; rinse and repeat until you’ve got all the users rolled out.  Big bang deployments tend to end in tears, or at the very least late nights.

 

Now to cover the access methods in detail.

 

Core Client Access 

 

Core Clientless Access (CCA) is the classic “Web Portal” and offers full web proxy for intranet applications such as SharePoint, iNotes and Exchange.  It can be considered a “true” SSL VPN in that it is totally clientless and dynamically rewrites Intranet content.  Crucially it offers deep and powerful single sign-on support and intermediation via Kerberos, NTLM and Basic Auth; this means that a positive and seamless user experience can be maintained even to the darkest corners of your intranet.

 

File rewriting and hosted Java applets are two underutilised aspects of the Core feature set. File rewriting dynamically renders CIFS & NFS shares into HTML, making them securely accessible from any platform. Server-side permissions can be honoured or overridden as you see fit. Session variables allow the creation of a resource policy which will “find” the user’s home directory in LDAP.  The resulting portal link neatly bypasses the mess of trying to map network drives across VPNs. The other terrific use-case is a “quick but not dirty” method of sharing documents with trustedthird parties. As the ACLs can be configured tightly and file access is logged, messing about with “proper” VPN clients or dodgythird party file exchange sites is unnecessary.

 

Hosted Java applets tend to be used in the context of thin clients such as Citrix; but virtually any applet can be embedded on the IVE with strong authentication and single-sign-on.  This is perfect for supporting the legacy “Green Screen” type applications which still kick around an alarming number of organisations.

 

Terminal Services/Citrix/VMware View

 

Juniper Networks bundle the various types of thin-client access under the Terminal Services banner, but this is not limited to RDP support.  At the very least you’ll probably offer RDP access to a few choice servers to administrators, but this only scratches the surface of the products capabilities, especially in the context of Citrix. Again, you can create a link to an individual server if that’s what you need, but the IVE fully understands the native Citrix Farm XML API and can dynamically render a list of applications, deliver the Java client and control session security features.  This method allows you to provide thin client access to corporate applications for trustedthird parties (such as partner call centres), home users and roaming users in web cafes’ with a minimal footprint.

 

Secure Application Manager (SAM)

 

The SAM can be considered the “original” SSL VPN in that it tunnels client/server traffic over port 443 and is dynamically delivered. SAM is delivered as ActiveX or Java and requires relatively few client side permissions, although gradual improvements in browser security have somewhat dented its utility. In my experience IRO 85% of your user’s requirements will be mail, Intranet/SharePoint and a file resources; this makes SAM a powerful candidate as the default access method.  Connections are directed into the VPN with a DNS injection and tunnelled via the client loopback address. This is a killer feature because it neatly side-steps the issue of overlapping address spaces and allows very fine-grain control over application access. This is ideal forthird party access where you may only allow access to a specific server application, but don’t know or care about the client platform. Deploying a “full-fat” VPN client to athird party doesn’t tend to be popular and removes the worry of granting any kind of Layer 3 access to anyone you don’t know especially well.

 

Network Connect

 

Network connect (NC) is as powerful as any “Traditional” IPSEC VPN client but can also be dynamically delivered. The primary use case for NC is corporate users and provides an “on network” experience with complete control over split tunnelling, client-side DNS and PAC files as well as Layer 4 ACLS. It is usually started from the portal window and a client launcher is available, but for a desktop client experience the Junos Pulse client is more appropriate. NC can also be used if you have athird party who needs to shuffle large amounts of data in or out of your gateway. For this scenario I’d suggest tight ACLS with a static address reservation or VLAN so they can easily identified as they transit your network. The Juniper IDP is also helpful as you can set up two-way signalling in case a user or third party attempts anything they shouldn’t.  As of version Pulse 2.0, NC is the only choice if you want to use Multicast across the VPN or need to honour IP “Type of Service” (TOS) bits. 

 

Juniper Junos Pulse (Windows)

 

The Junos Pulse client is the new kid on the block and integrates aspects of NC, Host Checker, Juniper Odyssey, and the JWXOS soft client as well as some new cool stuff such as Network Location Awareness (NLA). The ideal use-case for Junos Pulse is managed “Wintel” devices with cached profiles. NLA will automatically attempt to “dial home” to the corporate VPN gateway to ensure a seamless always-on connection.  For this reason it is not suitable for trusted third party scenarios; you want to keep those guys at arm’s length and force them to log on when necessary. It’s not about making life difficult, but making sure that third parties only connect when they actively have data to exchange. If they need an “always-up” connection then a point-to-point IPSEC VPN is more suitable.  If your users heavily use 3G datacards or similar, it may be worth disabling the auto connect features to prevent bandwidth being unnecessarily chewed, even with a client side WAN Accelerator installed. Pulse clients are available for a variety of platforms, but their functionally is largely dictated by the capabilities of the client OS, and is the subject of another blog.

 

The beauty of the Secure Access family is that the policy engine allows you to dynamically select the access method which is most appropriate to the user and their context.  Inevitably there is no one “right answer” to all your network access requirements, but the IVE provides sufficient flexibility to be able to cope with most eventualities. There are a couple of more obscure and optional client access methods I’ve not mentioned such as ActiveSync and the email client, but I’d be interested to hear about the unusual problems you’ve run into and how you’ve solved them with the client access methods available, comment is free!

Comments
by Ben Ward (crouchingbadger) on ‎12-21-2011 10:30 AM

Nice post, Glen,

 

I'm wondering about Terminal Services/Citrix/VMware View which we have on our IVE. I'm looking for a good way to segregate enterprise NMS applications to satisfy their Java and ancient browser requirements and often it seems the best way would be to install the clients once and just run them via RDP.  Is this method the most effective considering 60% of the usage will be from the NOC (ie. inside not outside)? Are there any methods that emulate a window-based interaction, rather than running a whole screen-based RDP session (a bit like Sun Secure Global Desktop)?

 

Ben

by on ‎12-21-2011 01:17 PM

Hi Ben, we've had a couple of customer scenarios like this were the SA has been used as a "poor mans NAC" where access needs to be controlled to a select few hosts & user groups and it works well, although obviously you've got to watch the concurrency otherwise the per-user cost may get excessive. This can be controlled with tight session timeouts..

 

I've never come across Sun Secure Global Desktop, but generally the IVE will host thin clients & control where it can control the underlying protocol to the back-end server; there are no server side proceses which can be run (except for Integrity measurement, but that's another kettle of Chickens).  Any TCP/UDP application can be proxied through the SAM and NC, and you can also host reasonably complicated Java applets & supporting files but there is no native X window emulation..

by Oscar Jimenez Sanabria(anon) on ‎12-08-2012 07:56 AM

hi Glen

 

i am thinking to use Core Client Access method in SA ,but i also bought Patch Remediation Management (PRM) however
my problem is that to use PRM (Shavlik patch deployment engine) is mandatory to use Junos Pulse
Client, my questions are the following :

how can i to use PRM (Shavlik patch deployment engine) for Core Client Access method ?
what is the best practice for core Client Access method with Junos Pulse ?
is a best practice to use PRM (Shavlik patch deployment engine) with Core Client Access method ?

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About Security & Mobility Now

Discussing a wide range of topics impacting enterprises and
data center security.

Subscribe RSS Icon

Our Bloggers

Kyle Adams
Senior Software Engineer

Profile | Subscribe

Ritesh Agrawal
Director
Software Engineering

Profile | Subscribe

Erin K. Banks
Senior Technical Marketing Manager

Profile | Subscribe

Ajay Bharadwaj
Product Manager

Profile | Subscribe

Michael Callahan
Vice President
Product Marketing

Profile | Subscribe

Scott Emo
Director
Product Marketing

Profile | Subscribe

Mora Gozani
Senior Manager
Product Marketing

Profile | Subscribe

Ashur Kanoon
Sr. Manager
Technical Marketing

Profile | Subscribe

Seema Kathuria
Manager
Product Marketing

Profile | Subscribe

Kevin Kennedy
Senior Director
Product Management

Profile | Subscribe

Dave Killion
Software Engineer

Profile | Subscribe

Rebecca Lawson
Senior Director
Product Marketing

Profile | Subscribe

Rajoo Nagar
Senior Manager
Product Marketing

Profile | Subscribe

Erin O'Malley
Manager
Product Marketing

Profile | Subscribe

Galina Pildush
Strategy & Planning
Architect

Profile | Subscribe

Edward Roberts
Director
Product Marketing

Profile | Subscribe

Bill Shelton
Director Field Sales

Profile | Subscribe

Ashutosh Thakur
Product Line Manager

Profile | Subscribe

Troy Vennon
Software Engineer

Profile | Subscribe

Brad Woodberg
Product Manager

Profile | Subscribe

Labels
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.