Issues with user validation against Microsoft AD

[BertM]

In OPNsense 16.1.18, there thill is a number of issues with validating Microsoft AD users.
The most important of these issues are:

• Filtering based on OU does not work.
• Filtering based on AD Group membership cannot be configured

These things work OK in pfSense but not in OPNsense, and this prevents me from migrating from pfSense to OPNsense.
Let me explain how I use this in pfSense.
Our company has a dozen branch offices in several countries worldwide.
All branch offices have a Microsoft Domain Controller, connect to the internet via pfSense and are interconnected via IPsec VPN.
There are over 2000 users in the AD, and only a hand-full of them are allowed a road-warrior IPsec VPN to any of these offices.
Because I do not want the Windows Domain Administrators to mess around with the network devices, we defined a number of groups in the AD and users are allowed road-warrior VPN access to any of the offices, based on membership of these AD groups.
This way I do not need to configure individual users in the pfSense devices, just groups (and allow "User - VPN - IPsec xauth Dialin" privileges for the group), and the Windows Admins only need to add the users as a member of the AD group to allow them to use their AD account to open a road-warrior VPN.

How did I configure this in pfSense?

In the Servers config on pfSense, I entered the following in the config for the nearest Domain Controller:
In the seach scope I set the level to entire subtree and entered the proper Base DN.
In Authentication containers, I entered the OUs where the groups reside in the AD
In the bind credentials, I added a user account that was able to query the AD
Set User naming attibute to samAccountName
Set Group naming attribute to cn
Set Group member attribute to memberOf

In the Groups config I entered the groups names exactly as they are named in the AD, and assigned the proper privileges to the groups.

What is it that does not work in OPNsense?

1. Filtering based on OU does not work.
What I mean is that OPNsense does not honor the level setting in the search scope, and it also does not honor the setting in Authentication containers.
What should happen is that only accounts in the OUs that are entered in the Authentication containers should be able to validate.
However, it does not matter what you enter in the Authentication containers (you can even enter a non-existing OU), any AD user is able to validate.
Also the level setting in the Search scope does not seem to matter but, given the issue above, I am not able to really test that.
What should happen is that if the level is set to one level, only users in the defined containers should be able to validate, and when it is set to entire subtree all users in the defined OU and any OU below that should be able to validate.

2 Filtering based on AD Group membership cannot be configured
In the GUI, there are no fields where the Group naming attribute and the Group member attribute can be configured.
As a result, Access based on AD group membership cannot be configured.

[Julien]

out curiosity have you tried to use the RADIUS server with AD? it works fine and you can add the domain users to the authentication .

[BertM]

@jamerson: Nope.
The nice thing about using AD authentication is that we already have Domain Controllers in all locations.
Given the throughput of the Site to Site VPNs, particularly to countries like Russia or Japan (latency), my guess is that we don't get away with just one central Radius server and that we need to install one in each location.
Hardware resources are limited, and there is no IT presence in the branch offices, only in the central location in the Netherlands.

We already have pfSense devices in all locations, and AD authentication works fine in pfSense.
The thing is that we want to migrate these things to OPNsense.

[Julien]

Are those sites connected through one AD and one tree? or every site has own AD ?
we have a similar configuration between 4 offices, Stockholm , Rotterdam, Amsterdam , Barcelona .

4 office has own AD with 1 Tree on the active directory . install a network policy and access services on the AD , add a group " VPN USER " to it ,
whenever a new user join the company we create his/hers account and make sure he is a member of the VPN user group and it works.

[BertM]

Sorry for the late response. (been rather busy lately)
We have one single Active Directory domain.
There is a separate OU for each country, and below the country OU, there are separate OU's for the various locations..

So, for example, Base DN is DC=DOMAIN,DC=TOPDOMAIN
Autherntication Containers is OU=SecurityGroups,OU=Haneda,OU=Japan

In the Active Directory, there is a security group called VPN_Users in the specified Authentication Container. and VPN Users are member of that group in the AD.

What I would want is to specify the a group in OPNsense called VPN_Users (exactly the same name as the groupname in the AD)
Then, in the server configuration in OPNsense, I would like to be able to specify the User Naming attribute as "samAccountName",
the Group naming attribute to "cn", and the Group member attribute as "memberOf".

What this means is that when a user logs-in to VPN, (or OPNSense) with a username for which a matching samAccountName can be found in the AD (and the password is OK), and the AD account has the memberOf attribute set for a group of which the cn matches a group in OPNsense, the user would get the privileges assigned that are defined in OPNsense for that group.

It is not exactly rocket science, and I have it working perfectly with pfSense.
But as I already mentioned, we would like to move away from pfSense towards OPNsense, but then things like this should work flawlessly, because apart from the Netherlands and Germany, there is no IT presence what-so-ever in any other location.

Kind rergards,
Bert

[oisteink]

Sorry to resurrect an old thread but it shows fairly high up on google when you search.

I had the same issue and solved it by:
Setting up an LDAP server for VPN acces
- Setting memberOf=<my vpn group dn here> in the extended search.

Works as intended - only tried Open VPN so far. Users that are member of the VPN group can connect, other users can not.