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.
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!
Discussing a wide range of topics impacting enterprises and data center security.
Subscribe to Security & Mobility Now
- wendohw on: Network Security Management -- it’s all about Oper...
-
ahamdad@cfao.co
m on: Best Practises in Authentica tion with Junos Pulse ... - scottdware on: When (and where) to use SSL VPN: Security, Portabi...
- on: Bitcoin DDoS Attack: 6 Steps to Turn a Profit
-
on:
It’s Not Size, But Sophistica
tion That Matters -
on:
Collective Defense Requires Greater Informatio
n Sh... -
on:
Deconstruc
ting Web Attack Trends in 2012 -
Ashwin Krishnan (Ashwin)
on:
A thermostat can be smart but how secure can it be...
-
Kyle Adams (KyleAdams)
on:
What does Super Mario’s Bowser have to do with web...
-
on:
The Truth about Virtualiza
tion Security
