1. Resolve login issues quickly with the policy trace tool.
The standard (event) logging on the Juniper Secure Access SSL VPN is very thorough; however, the detail and clarity provided by the policy trace tool is exceptional. If an individual user is experiencing login issues, navigate to: Troubleshooting > User Sessions > Policy Tracing.
Feed in the username that is experiencing issues and the realm they should be using. In most cases, you only need to click, Pre-Authentication >Authentication > Role Mapping, to get a comprehensive idea of what is happening. Leave the other policies sections unchecked, unless you have a specific issue with resource access, as they can be verbose. Click Start Recording to start gathering data, and then ask the user to log in again.
Tip: Logging in as the problem user on your own workstation may not provide useful insight because policies often take into account the local machine status. Just because it works for you doesn’t mean it will work for the end user.
Clicking on the View Log button will then show the complete login process, including attaching to the domain or Lightweight Directory Address Protocol, authentication and role mapping.
Tip: If you don't see any activity for the specified user and realm combination, it's possible the user is attempting to authenticate against a URL and sign-in policy bound to an alternate login realm. This is usually caused by the user accessing the wrong URL, for example, "secure.foo.com" instead of "secure.foo.com/partners".
Two error messages often are seen together: "No match on rule" followed by "No roles mapped." This means the Secure Access SSL VPN appliance was unable to match the logged-in user against any rules. The two most common reasons: The user is not a member of a group specified on a role-mapping rule; or the user's workstation didn't meet the requirements for a mandatory host checker policy, and no other roles matched. Both of these situations should be easily visible with the logs.
2. Create a strong host checker policy that enables on-demand access.
Even as BYOD evolves to support smartphones and tablets, many organizations still issue a large number of Wintel laptops to their users. To ensure these devices are working properly, implement a strong host checker policy. Through this approach, you can ensure devices connecting remotely are still in a good state of repair. The host checker analyzes and identifies a wide variety of client platforms, as well as provides a range of remedial actions.
At a minimum, the host checker should be used to identify whether the connecting client is part of your enterprise's standard equipment deployment procedures. A simple test will look for known registry keys or files on the local disk, but a more thorough assessment will interrogate machine certificates issued by an Active Directory-integrated certificate authority.
To provide a good level of security, the host check assessment should also check the health of the deployed desktop antivirus suite. Juniper's Endpoint Security Assessment Plugin (ESAP) can identify and attempt to remediate problems by restarting services or forcing pattern updates. But note: Carelessly implemented, ESAP can prevent users from accessing the network, so it should be used with caution. With appropriate policies in place, users should always receive sufficient connectivity to self-remediate or to obtain assistance from desktop support.
Going even further, integrated Shavlik patch management offers a deep assessment of the client's security. This typically works best with robust management tools that automate the delivery of application and operating system patches. The ESAP verifies the patch management is working correctly, and only permits full network access for healthy machines. This is helpful in scenarios where application vulnerability directly affects the client, and when preventing unpatched devices from accessing the network is critical.
Tip: The host checker has many features -- some of which are licensed, but all work "out of the box" -- and the checker is worth exploring to understand what additional benefits you can gain.
3. Use authorization-only access to provide ActiveSync security.
While ActiveSync offers many security options for a BYOD deployment, Juniper's Secure Access provides a simple built-in solution that won't affect licensing. Furthermore, it allows the restriction of traffic into an Exchange server and reduces the processer impact by offloading Secure Sockets Layer (SSL) encryption. The only real caveat is that to work optimally, a wildcard certificate (such as *.foo.com) or one dedicated to ActiveSync (such as owa.foo.com) is required. Most deployments will already have a dedicated certificate; it is just a case of importing it into the Secure Access appliance and moving the Domain Name Server.
To do this, take the following steps:
- Create a host entry on the Secure Access -- such as "mobilemail.foo.local" -- that points to the private IP address of your Exchange server, but doesn't use the real server name. This is to prevent policy conflicts with users accessing Outlook Web Access, which requires an alternative set of policies.
- If required, import your certificate key pair under: System Configuration > Certificates > Devices Certificates > Import Certificate & Key.
- If you have a dedicated certificate for ActiveSync (i.e. not a wildcard), it will need to be attached to a virtual port on the Secure Access.
- Create a new role under Users > User Roles and name it ActiveSync Role. Disable all options except the Web policy.
- Create a new Web resource policy under Users > Resource Profile and click New Profile. Select the version of the Exchange you are using from the Type drop-down list. Name the policy ActiveSync RP. This should automatically refresh the browser and change some of the options further down the page.
- Enter the base URL for your Exchange server, but use the host entry name specified in the first step. By pressing tab to the next section, many of the subsequent fields will auto-fill with policies.
- Leave the Security Settings alone, but you can restrict the upload and download of attachments. Clicking on either Prevent download.. or Prevent upload.. should automatically generate new Web Access Control Autopolicies based upon the base URL created in the previous step. You may adjust these if necessary, but in most cases, they should work fine.
- Autopolicies will also be created for caching and Web compression. Adjust if necessary, but the standard settings should provide good performance for most ActiveSync clients. Click Save changes to commit the configuration.
- At the next window, assign the policy to the ActiveSync role created in the previous step and then click Save changes.
- On the Bookmarks menu, leave the configuration as is, as no adjustment is necessary; most of the settings will be overridden by the ActiveSync policy.
- Under Authentication, click Signing-in > Sign-in Policies. Click the New URL button to create a custom URL.
- On the User Type, select Authorization Only Access; this should automatically refresh the page with new options.
- Under the Virtual Hostname, enter the public URL of the ActiveSync server you wish to use, such as "owa.foo.com".
- Enter the backend URL based upon the hostname you created in step 1 and for which you created a resource policy in step 5. For example, "http://mobilemail.foo.local:80". You may also describe the policy.
- Select No Authorization under Authorization Server. This will be handled by the ActiveSync server.
- Under role option, select the role you created in step 4. This should automatically inherit the access control and other settings from step 5.
- It's recommended you select Allow ActiveSync Traffic Only to provide additional filters on inbound traffic. Click Save changes to commit the configuration.
Tip: You should be able to connect to the ActiveSync server via the embedded application on your favorite smartphone. The status page on the Secure Access should now show inbound connections and include a separate counter for ActiveSync users.
For more information about Juniper Secure Access SSL VPN and MAG platforms, click here.
About the author:
Glen Kemp is an enterprise solutions architect for a U.K.-based managed services provider. He designs and deploys network and application security tools, including access control, remote access, firewalls and other "keep the bad guys out" technologies. He is also an experienced professional services consultant; delivering elephants and not hunting unicorns. His blogs can be found at sslboy.net and at the Packet Pushers Podcast. Follow him on Twitter @ssl_boy.
This was first published in July 2013