OpenVPN Access Server post_auth RADIUS group mapping script
Although Access Server can be configured out of the box to use Active Directory's RADIUS server for authentication, items such as user permissions and group assignments must still be configured separately in the Admin Web UI. Even though his task might be easy for smaller setups, this becomes almost impossible to do with a large scale VPN deployment. This guide is written to simplify such a deployment and integrate Access Server with Active Directory, so most of these settings can be managed centrally in Active Directory, without duplicating much of these permissions in the admin web interface itself.
If the outlined steps are followed correctly, this guide will allow you to do the following:
- Translate Active Directory groups into Access Server groups, so that scripts, permissions, IP assignments can correlate to a specific AD group.
- Assign a static IP address to a particular user given their AD profile (these users must be assigned an Access Server group - see below)
- AD user/group specific controls for the AS 'admin', 'autologin', 'lzo', 'reroute_gw', and 'deny-web' flags.
To begin, you must first have the NPS role installed and running. For a simple setup regarding NPS, please refer to the article here: Configuring Active Directory (Windows 2008 Server R2) RADIUS Server for OpenVPN Access Server.
Log on to your Access Server via SSH and obtain root privileges. Then download the RADIUS post_auth script:
cd /usr/local/openvpn_as/scripts wget https://swupdate.openvpn.net/scripts/post_auth_radius_mapping.py -O post_auth_radius_mapping.py
After the script is downloaded, install it to your server:
cd /usr/local/openvpn_as/scripts ./sacli -k auth.module.post_auth_script --value_file=post_auth_radius_mapping.py ConfigPut ./sacli start
If you do not see any error messages at this point, the script has now been installed and is ready for use. If you have not already done so, login to your Admin Web UI and configure the server to use RADIUS for authentication.
As the script itself has different uses, we will go through each use case scenario in sections.
Case 1: Setting up OpenVPN Access Server Access Flags via Active Directory and NPS
As mentioned previously, usually the administrator is required to perform such steps by manually adding users to the Admin Web UI. However, by exploiting how Active Directory handles RADIUS requests, we can integrate these flags directly into the Active Directory interface. This is done by remapping the Callback-Number RADIUS reply attribute.
This functionality is implemented similarly to Linux's permission mask values, and consists of the following 5 bits:
- 1st (left-most) bit: prop_superuser: Is this connecting user an administrator? Should this user be able to login to the Admin Web UI? (0 = no, 1 = yes)
- 2nd (left-most) bit: prop_autologin: Should this user be able to download an autologin profile and have autologin privileges? (0 = no, 1 = yes)
- 3rd (middle) bit: prop_lzo: Should LZO compression be turned on? (0 = no, 1 = yes)
- 4th (left-most) bit: prop_reroute_gw_override: If the option of redirecting the user's Internet traffic over the VPN is turned on globally, the behavior should be modified so that (0 = disable Internet routing, 1 = only route DNS servers). Please note that this option has no effect when the redirection is not turned on globally, and thus cannot be used to turn on redirection specifically for individual users when the option is turned off globally.
- 5th (left-most) bit: prop_deny_web: Should the user not have access to the web interfaces such that profile distribution must be done manually by the administrator? (0 = no, 1 = yes)
Any values above not set to a zero (0) or an one (1) will be ignored by the processing script and the defaults for these options will be used. For simplicity and clarity of this article, we will be using a letter F to indicate default values.
NOTE: The script requires that exactly five characters to be specified in order for the
Callback-Number reply attribute to be processed. If you do not want to override a specific option, mask that option with a letter F.
Here are some examples:
1) To indicate that the user/group is an admin, and that autologin should be enabled for this user/group, without overriding any other options:
Set Callback-Number to 11FFF.
2) To make sure that LZO compression is turned off for a specific user/group:
Set Callback-Number to FF0FF.
3) To do nothing at all:
Set Callback-Number to FFFFF, or not the setting Callback-Number reply attribute.
There are two places where the Callback-Number reply attribute can be set,
- User level: Under Active Directory Users and Computers, inside the user's properties and under the Dial-in tab. The access flags can then be set for this user under the option Always Callback to:text field.
- Policy level: The Callback-Number attribute can also be added at the policy level using Server Manager and inside the NPS MMC snap-in under the policy's Settings tab. Please note that when adding this reply attribute, that a string (not hexadecimal)of 5 characters are expected.
For your information, the Callback-Number reply attribute can be set at both the user and policy levels concurrently. When this happens, the setting at the user level will override what is set at the policy level (For example, you can turn off LZO compression for all users in at the policy level, except specific users which you define an override at the user level.
Case 2: Setting up OpenVPN Access Server Group Mappings via NPS
The purpose of this function is to create a dynamic mapping for your AD groups to your AS (Access Server) groups. This way, the AD groups you specify can be placed automatically in a specific AS group, and appropriate group permissions, scripts, and access controls can be applied to these users without manually configuring them in the Admin Web UI.
Like Case 1's policy level access flags definitions, group mappings for AS are also done within the Server Manager and inside the NPS MMC snap-in. In this case, however, multiple policies should be created inside the Network Policies folder inside the NPS snap-in, each policy corresponding to a single AS group. For example, an AD group of 'Administrators' would have its own policy granting RADIUS access, and an AD group of 'Sales' will have a second, separate policy defining this access.
After these policies are created, like the steps for Case 1's policy level access flags management, add the Framed-Pool reply attribute containing the AS group name you would like this policy to have (e.g. Admin). Do note that since this is merely a mapping, you can map multiple AD groups to a single AS group, and AD and AS groups do not have to have the same corresponding names.
Suppose we want to have the following group mappings (AD group --> AS group):
Enterprise Admins --> Admins Domain Admins --> Admins Technicians --> Admins Sales --> Sales Domain Users --> Users VPN Users --> Users
Create three NPS policies with the following details:
NPS Policy 1:
Conditions: Enterprise Admins OR Domain Admins OR Technicians Settings: Add Framed-Pool reply attribute = Admins
NPS Policy 2:
Conditions: Sales Settings: Add Framed-Pool reply attribute = Sales
NPS Policy 3:
Conditions: Domain Users OR VPN Users Settings: Add Framed-Pool reply attribute = Users
Please note there is no error checking in the processing script for typos or misspelled group names. For this reason, it is highly encouraged that you test these policies after creating them since a typo in them will prevent your users from being able to log on to your server.
Case 3: Setting up static IP addresses within Active Directory and NPS
Access Server and Active Directory can be configured to accept static IP assignments from Active Directory. As seen in Case 1, this option can be configured within the user's properties under the Dial-in tab.
In order for this assignment to work, however, these requirements must be satisfied:
- The user in question must belong to an AS group (this can be either set manually in the Admin Web UI under the User Permissions section, or set using Case 2 as described earlier)
- The group hosting the user must contain a group specific subnet for that specific group
- The static IP you are planning to assign must reside in the aforementioned group specific subnet (the global dynamic/static pools cannot be used)
If all of these criteria are satisfied, the connecting user will be placed in the group you have chosen, and will be assigned the static IP address you have chosen in Active Directory.
Similar to Case 2, misconfigurations in this section may cause your user to lose their ability to connect to your VPN server. If this happens, you can log on to the Admin Web UI, and review the Log Reports section for error details.