Access Server is based on open source software. This means you can create clients for whatever platform or device without restrictions, develop a UI using the management interface while at the same time interoperate with all of the more advanced features of OpenVPN AS such as multi-factor authentication.
This functionality allows Access Server users to develop their own authentication modules that can initiate an authentication challenge/response sequence. This means that the authentication module can ask the user any number of questions, and get their responses back, in order to decide whether or not to allow access. All Access Server clients have integrated support for this functionality, which operates on top of the existing OpenVPN auth system. This functionality can be supported by any OpenVPN client, not just the AS clients.
By using custom authentication modules it’s possible to implement single-sign on, where signing into the VPN automatically pre-authenticates the web applications that end-users need to access through the VPN. For example, the auth module can query an LDAP server to get authentication status. If authentication succeeds, it can obtain a session token from LDAP and transmit it (via the OpenVPN control channel) to a Python script running on the client, which can then (for example) set a cookie in the web browser. This can all be done in a few lines of custom code, because the AS makes the LDAP API available to the customer module, as well as a data transmission API that allows transmission of arbitrary data to client-side python scripts via the OpenVPN control channel.
Access Server has a much more flexible model for client-side script execution than OpenVPN (OSS). For one, the AS allows scripts to be pushed to clients, but includes many safeguards (such as script signing) to prevent abuse of this capability. AS allows Python scripts to be pushed to any AS client regardless of what OS it is running. If AS client is being used, it is guaranteed that a Python 2.6 interpreter is always available.
Furthermore, it is possible to execute scripts in the context of the desktop user instead of the root context of the OpenVPN daemon. In fact, this turns this script-pushing capability into “Secure Application Delivery”. This can also be used for things like single sign-on.
AS clients fully support the both MacOS X keychain and Windows Crypto API for key storage. This feature improves security of AS because no OpenVPN client configuration file contains the private key. This support is configuration-free in the sense that the appropriate certificate and private key are selected by scanning the keystore for keys signed by the OpenVPN CA cert. From administrator perspective both MacOS X and Windows keychains look the same, i.e. their differences have been abstracted away.
There are a number of ways that the AS Mac client goes beyond the
OpenVPN (OSS) client:
1. Full Keychain support
2. Solid support for pushed DNS servers
3. Integration with OS X SystemConfiguration framework for
generating VPN Connect/Disconnect events
4. A real desktop client (instead of a Java applet).
AS is tightly integrated with UCARP for failover. Configuration sync takes place between the primary and backup nodes, so only a single node needs to be managed. The backup node will kick in immediately with the current configuration if the primary node fails.
AS has a full XML-RPC API with hundreds of methods that can control and monitor every aspect of the AS. Even the AS client is fully API driven. In fact, even the AS web client is simply an Ajax app that interacts with the OpenVPN backend via a client-side XML-RPC API. This API can be used for a number of other things.
The AS knows how to instantiate multiple OpenVPN daemons on a given box and load balance between them to get maximum performance from all CPUs. This is tricky to do with OpenVPN (OSS) by itself.
AS can be configured to have OpenVPN daemons listening on both TCP and UDP ports. Further, the client will adaptively try UDP first, then fall back to TCP if that fails. All this is fully automatic.
AS has a mode where all web functionality can be completely disabled on both server and client. This means AS can be run with only the OpenVPN TCP and UDP ports open to the internet, and the AS client can be used without touching a browser. This avoids having to take browser-related security issues into account.
Using OpenVPN (OSS) in large deployments can be cumbersome as one needs to distribute configuration files to clients somehow. Access Server allows an executable installer to be bound with the client configuration file for a user. In practice, one can easily generate a DMG installer for Mac or an MSI installer for Windows that already has the user’s config file attached to it.
Because the Access Server clients allow the user’s certificate and private key to be located in the system certificate store (Crypto API on Windows or Keychain on Mac), it’s possible to make an OpenVPN client configuration that is universal in the sense that you can give the same configuration file to every user. This feature, in combination with bundled profiles, allows one to have a single installer that can be deployed to all client machines running the same operating system. Further, there is no security-sensitive information in the installer, because the profile that is bound to it lacks any private key.
AS support for CRLs goes beyond what OpenVPN (OSS) offers. One can modify the CRL file on the fly and the changes take effect immediately. It’s also possible to include CRLs for multiple branches in the cert chain. In fact the AS will even bump off a user that is already connected, if a real-time change to the CRL revokes their certificate.
This feature allows clients to block off access to the local subnet except for the gateway.