pfSense 2.3: delegated with users Administration Active Directory [Quick Guide]

3:25 pm February 14, 201715163

I. introduction

I got a little hands in pfSense then I want to write you this tutorial. This tool open source is able to connect to an LDAP directory, in this case the Microsoft Active Directory, in order to centralize authentication with different services like access to the administration interface, VPN access or connection to the captive portal. Although in some cases, the liaison between pfSense point and the Active Directory will be Radius.

With pfSense, it is possible to declare the connection to an AD to authenticate users (some users, not all), to delegate the administration of the firewall. for example, we’ll define a group that will have the right to set the captive portal of the firewall part, we’re going to assign rights to a group, and this group is a group of the AD. We can have a second group that can only access the firewall logs, for example.

You could totally create local groups on pfSense, with local users, but it’s still more fun to question directly the AD for not having to undergo the login and/or password changes. In addition, it is not monstrous as config.

In short, we’re going to:

  • declare the Active Directory on pfSense (one on the premise where you have an operational AD)
  • test authentication
  • declare a group in pfSense to tie in with the AD
  • assign rights to this group
  • define our AD server for authentication
  • test connection to the WebGUI with an AD account

II. Declare the Active Directory on pfSense

connect to the WebGUI of your pfSense with an administrator account.

Click on the button “ System ” and “ User Manager ” that allows to manage users and groups pfSense, so that to configure an authentication server.


Click then on “ Authentication Servers “.


Three screenshots that follow are part of the same configuration page. All parameters need not be changed, see it as a whole.

  • Descriptive name : specify a name for this server, I advise you to indicate the field
  • Type: indicate “LDAP”, which is the default choice of pfSense
  • Hostname or IP address : If the pfSense is able to resolve the DNS name of your domain controller, specify the FQDN name as I did in my example. But you can also simply indicate the IP.

It is not necessary to modify the other parameters, unless you want to use a certificate to encrypt exchanges, which is recommended of course.

Note : My pfSense knows my AD as a DNS, which allows to solve the name adds – – connect.local, but you can use an IP address.

That’s it for this first part.


Here is the continuation of the setting:

  • Search Scope : let “ Entire Subtree ” for the scope of research, and for the “Base DN” select the root of your AD by taking example on what I did for the field “it – connect.local”.
  • Containers authentication: specify one or more or where pfSense can look to find users who attempt to connect. Fill at least one value and then click on “Select a container” you can take of other or if necessary.

Then uncheck the option for “ anonymous Bind ” Let’s rather authenticate to query the AD. Beforehand, I created an account in the AD which is single user and which for the SamAccountName (login): pfsense.connect

indicate the DN for this user, if writing a DN seems too complicated, or also to avoid the errors of seizures… You can query directly by PowerShell on your AD (just to adapt the login):

(get-aduser-filter 'samaccountname-eq "pfsense.connect"'). DistinguishedName 

then copy the value returned in the field “ Bind credentials ” the pfSense conf, and then on the field to the right indicate the password associated with this account. In fact, I’m surprised that the password is displayed in clear!


Finally, last part of the Conference, we got the good end! 🙂

you can only specify “ group ” to “ posixGroup “, and make sure you do not tick the option “ LDAP Server uses RFC 2307 style group membership ” otherwise pfSense will not retrieve the name of the group that belongs to your user.


Save the configuration with the “Save” button.

III. test the AD authentication

before you test authentication with the diag tool integrated with pfSense, I show you a screenshot of my AD, it can allow to better visualize my config. You will see that I have an account “ pfsense.connect ” that I used before pfSense can interrogate the AD, then the group “ pfSenseAccess ” contains users who need access to pfSense.


In the menu “ diagnosis”, click on “ Authentication”.


Choose your AD as authentication server can test a login and a password which is supposed to work.


Click on “Test”, if everything is OK you should get this message:


If this is the case, bravo! You can move on.

IV. declare local in pfSense Group

always in pfSense he must be created a local group that will have the same name as the Active Directory group, this will allow pfSense to make the connection between the members of the Active Directory group and positioned on the pfSense group rights.

In the System, User Manager, access the “Groups” tab and click “Add”.


Name this group as that of the AD, so in my case I note “ pfSenseAccess ” but it does not specify in the description that he is an AD Group to differentiate, the description can be customized.

At the scope level, when it comes to an Active Directory group, “Remote” instead of “Local” is normally required, but I saw no real difference depending on the choice of the scope.

Finally, don’t add no member in this group and confirm.


Now that the group is created, we give him some rights.

V. assign rights to the local group

always in management groups, click the pencil icon to edit the newly created group.


Down to the level of the “Assigned Privileges” section and click on “Add”.


Then, all the privileges listed, you will see that it is really flexible, you can finely manage rights. It’s interesting to have a specific delegation. In this example, if this group to be able to handle the “Captive portal” part, here is what you need to select:


you could add other privileges to access the part of the log of the captive portal. Once your selection is made, click “Save”.

VI. define our AD server for authentication

this configuration step is necessary otherwise the connection to pfSense will rely on the local base and not on the AD. Always in System / User Manager / Settings, set your AD, for example “it – connect.local” as authentication server. Then, save.


This step is already completed and it closed the pfSense configuration, now we have to test this config.

VII. test the connection to the pfSense with an AD account WebGUI

open a nabrowser and go to the login page of pfSense. Then, try to log in with an AD account:


normally, once logged in, you should have access only to the “Captive Portal” under “Services”, all other menus are empty.


Well, this tutorial is over, now you can delegate the administration of your pfSense relying on AD accounts. It is important to use separate accounts for the administration to know who does what.