As your company grows, you’ll need to make adjustments to your business processes and systems in order to keep up with your growth.
What works for a small group of five employees, all working under the same roof, probably won’t work when that group expands to 500 employees all scattered around the world — especially when it comes to identity management and access control.
When you only have a few employees sitting in an office, you don’t really have to worry too much about differentiating between them, or limiting their access to different organizational resources. But when your team starts growing, or when you add contractors, freelancers and part-timers, you need a way to control who gets access to what and enforce those controls — especially when they are working remotely.
When you start adopting new tools and applications for your business, the authentication process can become a hassle for employees managing so many different sets of login information. It’s essential to find different ways to streamline the login process. And when you have dozens of employees, it’s also important to find new ways to make sure everyone is practicing good password habits — you no longer have the option of just reminding them at lunch.
There is no one solution that can streamline all of this for you while still offering you the powerful security your business needs — but taking a layered approach by combining OpenVPN Access Server with JumpCloud can provide you with streamlined scalability and seamless access, whether your team is at office or telecommuting.
Combining a VPN like OpenVPN Access Server with JumpCloud is one of the best ways for a company to implement identity management and access control for remote workers. JumpCloud offers DaaS (Directory-as-a-Service) which simplifies your entire identity management process.
Integrating these two solutions provides seamless connectivity between the JumpCloud cloud-based identity and access management services and OpenVPN’s Access Server, providing businesses with control over user access to VPN-protected resources.
JumpCloud’s service can be used to enforce secure passwords with rotation, length, originality, and complexity requirements, and to add Multi-Factor Authentication. JumpCloud supports multiple authentication protocols for all users within the directory: SaaS applications can authenticate via SAML; OpenVPN Access Server can authenticate via LDAP.
Take for instance a rapidly growing web content publishing company that provides custom content and general articles for high-traffic websites and portals. A majority of their employees are part-time or freelance contractors that work remotely from their homes. The company uses OpenVPN Access Server to provide VPN access, so remote workers can securely access the HQ corporate network systems that run publishing workflow, timekeeping, and payroll services.
The company has plans to expand worldwide and adopt SaaS tools (like Adobe Creative Cloud and other programs like it) to replace some of their legacy tools. But as the number of their employees grows, it is becoming much more complicated to maintain user accounts in local OpenVPN Access Servers — and the complexity will only increase when they add more Access Servers at new locations.
They needed to be able to:
To meet these needs, the company decided to centralize their identity management by using JumpCloud’s Directory-as-a-Service Solution. The contractors were made members of a ‘Contractor’ Group in the JumpCloud directory, and were given access rights to a smaller set of SaaS and corporate applications — compared to full-time employees who were given broader access. The Access Servers were configured to use secure LDAP authentication, and connect to JumpCloud’s LDAP servers. From there, they could easily manage group permissions, such as a ‘Contractor’ group, by mapping them from Access Server to JumpCloud, granting access to a limited set of services on the corporate network.
Because JumpCloud’s service is a managed solution, the customer’s IT department does not have to install, maintain, or grow the LDAP servers or the rest of the directory infrastructure.
Identity security has been strengthened by use and password rules. Centralized identity management has led to a reduction in operational complexity, and now employees can use the same credentials (username/password) to access VPN-protected resources in the corporate network, and log into authorized SaaS applications. Based on the Group that the employee/contractor is a member of, appropriate access to both SaaS and network services are provided.
OpenVPN Access Server (version 2.6.1 and higher) and JumpCloud Directory-as-a-Service integration is now live, making it possible to give users a single identity for all of their access needs, while still providing streamlined remote access and unmatched network security. JumpCloud’s platform-independent cloud directory approach supports Mac, Windows, and Linux systems along with other platforms, such as G Suite™ and Office 365™.
Note: To integrate JumpCloud’s RADIUS-as-a-Service with your OpenVPN solution, you will need to register your OpenVPN Access Server(s) Public IP address with your JumpCloud tenant. Instruction for that can be found here: Configuring RADIUS Servers in JumpCloud
Note: for JumpCloud specific settings requirements, see Using JumpCloud’s LDAP-as-a-Service
Configuration options were qualified using the OpenVPN Virtual Appliance v 2.6.1 via the included Admin UI and the OpenVPN documentation for configuring VPN for LDAP authentication.
There are a couple of ways you can achieve access to a whole network existing behind a firewall/router. For example, you can install an OpenVPN Access Server on a server in the target network you want to reach, and open a few ports on the Internet router on that network so that incoming VPN tunnel connections end up connecting to the OpenVPN Access Server instance. An OpenVPN client program can then connect to this Access Server, and through this Access Server, it can access the network that the Access Server is on. This is the typical use case, but we see all sorts of things happening out in the field.
For example, an OpenVPN client running on Linux can also provide access to local network resources. We call this use case a "site-to-site" connection because it is most often used to tie together a network on the server side, and a network on the client side. Then 2-way communication is usually allowed. This is typically done when a company has multiple offices in different locations across the world and needs to tie them together so that resources can be shared easily on the network. In such a situation you can have a Linux device running OpenVPN client software, and it will make an outgoing connection to an OpenVPN server elsewhere, and then share access to the local network on the OpenVPN client side with that external OpenVPN server — allowing other VPN clients on that OpenVPN server to also connect back to this network. So a VPN client connected to the Access Server can hop through the Access Server to another VPN client and through there reach their local network. But only if this is configured and allowed, of course. This is the site-to-site VPN client gateway feature in Access Server.
Another thing you can do is install a router on the network that has OpenVPN already built-in. There are routers available on the market by brands like Asus and Netgear that have our open source OpenVPN implementation built into it. This means that you can deploy such a router on the network, and connect directly to that with a compatible OpenVPN client program, and you can then access resources on the private network that this router manages. These types of routers only contain the OpenVPN open source version though and are not as feature complete as the commercial OpenVPN Access Server product is. But then Access Server, because of these additional features, takes up more resources than is generally available on router devices, which typically have a very low power processor and minimal memory and barely any storage. So to get the full experience, and to integrate with JumpCloud, this last option may not meet your needs, and it would probably be better to deploy an OpenVPN Access Server on your network.
The answer depends on if you are installing the OpenVPN Access Server on Ubuntu, or connecting an Ubuntu system to an OpenVPN Access Server.
Installing OpenVPN Access Server on an Ubuntu system: We chose Ubuntu 18.04 LTS as our primary choice for installing Access Server. You will find that the images we have for HyperV, ESXi, Amazon AWS, Google Cloud, Microsoft Azure, etc., are all Ubuntu 18.04 LTS with Access Server already preinstalled on it. So if you are using such a platform, you should use our available images to install the operating system and the Access Server in a straightforward step. In essence, it all runs primarily on Ubuntu, although we also support some other Linux platforms like Debian, RedHat, and CentOS. The installation options page (link below) also shows an option to take an existing Ubuntu installation, and install OpenVPN Access Server on it. The process is merely downloading the installation file for Access Server to your Ubuntu system, installing it, and setting a password for the standard 'openvpn' administrative user. Then Access Server is installed, and you can open the web interface in your web browser and start configuring things.
Installing an OpenVPN client program, and connecting that to an OpenVPN Access Server: that part is explained on our Connecting to OpenVPN Access Server using a Linux system page (link below). On Linux you can use your package manager, which is called "aptitude" on Ubuntu, to install the 'openvpn' package. This package contains the OpenVPN program that can run either as a server or a client, depending on how you configure it. Then if you go to the OpenVPN Access Server web interface, log on as a user, and download the "user-locked profile" or the "auto-login profile," you can save that to your Ubuntu system, and then use that to start a connection on the command line. The commands you need, and additional instructions, are available on our website.
That question depends on where the 2-factor authentication is implemented. If applied on the OpenVPN Access Server itself, so that it is our product that handles the 2FA, then an option is to enable the Google Authenticator requirement on the Access Server. This option, when turned on, will force users to first log on to the web interface and go through the Google Authenticator enrollment procedure. We have chosen Google Authenticator because it has no ties to any third party services or systems. It is merely a standardized method of generating a six-digit code every 30 seconds based on the current time plus a shared secret key. And the specifications and the code are so simple that there are hundreds of programs that can take a Google Authenticator shared key, and generate six-digit codes with that. There are desktop applications, mobile applications, even browser plugins, and of course, hardware tokens, that can integrate with this.
Now, if 2FA is handled in JumpCloud, and set as a requirement there, it is possible to make Access Server comply with this by using the post_auth script programming hook. It allows additional code to run after an authentication request has succeeded - so when a username and password are correct, and the process can then continue to 2FA. This additional code in post_auth on the OpenVPN Access Server could then read a requirement from JumpCloud to, on top of the username and password authentication, to also provide an answer to a question. This could be done with LDAP, for example by reading an additional attribute from the LDAP directory for this user that requires 2FA before allowing the user to establish a VPN connection fully. The question asked of the user could be "Enter 6-digit Google Authenticator code," and this question would be presented to the OpenVPN client program, and the user must provide the correct answer before the authentication request fully completes, and a VPN connection is established. However, it is unknown whether such a code exists so it would have to be created and tested before we could offer it as a solution.
The OpenVPN Access Server product has a free support ticket system on the website. The only requirement is to sign up for a free account on our openvpn.net website. Once you have done that, you can send in tickets to our support ticket system for no charge. However, there are some things to keep in mind:
We only provide limited support for the OpenVPN open source project itself. The support ticket system on our website is primarily dedicated to our commercial solution, OpenVPN Access Server, and its accompanying OpenVPN Connect Client software. We cover help on the OpenVPN open source project to a degree, but the main goal of the support ticket system is to provide support for the commercial solution.
Let's say you want to set up OpenVPN Access Server, and you have tried to install it, and an error comes up. You can then go to our website, log in with your free account, and send in a support ticket. We'll reply in a few minutes or a few hours, depending on when you send in your ticket and how busy it is, and we'll try to provide you with an answer that lets you continue the installation of Access Server. At no point during this process will we charge you for the support we provide. We assume that once people get our product installed and working, and they discover how great it is, that they will consider buying licenses for it — which is what pays for this support and the continuation of the OpenVPN Access Server development.
But if you have, for example, a Netgear or Asus router, and it has the OpenVPN open source project implemented in there, then our ability to provide support is diminished. While we do understand how the OpenVPN open source project works — it is at the heart of our commercial solutions after all — the issue is that a third-party manufacturer may have implemented an adjusted version of OpenVPN open source code into their product, and we may not be able to get it to work the way we want. We can guarantee that our commercial solutions will work because we have created them and can help you get past problems with it, but this isn't always the case with the open source project.
An exception is when you run the OpenVPN open source client program on a Linux operating system. This is currently the only way you can make an OpenVPN client connection from a Linux system to an OpenVPN Access Server. So if you run into a connection problem or you have a problem installing the OpenVPN client program on your Linux system, we will try to assist you in getting this working as best as we possibly can.
If you want to set up a server using only the open source OpenVPN project, and not use our OpenVPN Access Server, then we will have to direct you to the open source community for support on that. There are many valuable documents and how-to guides available in the open source community websites and forums that will help you get going if you want a purely open source solution.
But if you want the best, we suggest you use the OpenVPN Access Server, and then you can count on our support.
LDAP + VPN combines the best of both worlds
Employees can use the same login info across the board — and security is stronger than ever.
LDAP-As-A-Service maximizes VPN security & simplicity
These two powerful tools combined can simplify – and secure – your network resources.
Do more for your team with LDAP + VPN authentication
Ease of use for your team and a powerful resources for IT.