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, so most of these settings can be managed centrally in Active Directory, without duplicating much of these permissions in the Admin Web UI itself.
If the outlined steps are followed correctly, this guide will allow you to do the following:
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.
First, download the post_auth script you will need to install on your server:
then, put the file on the Access Server node where it is accessible.
If you have console access to your server, you can simply do this in the console by using the following command:
After the script is downloaded, install it to your server (note: you must be running as root, and be in the same directory where AD.py is downloaded to):
/usr/local/openvpn_as/scripts/sacli -k auth.module.post_auth_script --value_file=AD.py ConfigPut && /usr/local/openvpn_as/scripts/sacli start
If you do not see any error messages at this point, the script has now be installed and ready to 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:
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,
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:
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:
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.