PacketFence Installation Guide

Tested with VMware ESXi, Fusion and Workstation with 16 GB RAM dedicated to the VM. Compatible with other VMware products. Requires 64-bit CPU host for long mode support. PacketFence ZEN comes as a pre-built OVF virtual disk. Import the OVF using vSphere Client or vCenter for ESX hypervisors.

The VM’s first network card receives IP through DHCP.

The virtual appliance passwords are:

Make sure that there is only one virtual network card created, and also make sure that the vEthernet is connected to a virtual switch (vSwitch). That virtual network card will be used as the PacketFence management interface.

Newer versions of VMware Player handle VLAN trunking a lot better. With that in mind, we can use a single interface on the VM. So, ensure that the VM host is plugged into a physical trunk port with VLAN 1,2,3,5,10 and 200 as the allowed VLAN. These VLANs will be used later in configuration examples.

This setup has been tested using VMware ESXi, Proxmox VE and VirtualBox and works with any hypervisor PacketFence supports as well as bare-metal servers.

A virtual machine or server with 16 GB of RAM dedicated to machine as well as 4 CPUs is required. Allocate at least 200GB of disk space for PacketFence.

Provision a virtual machine with the specifications above, mount the ISO in the CD/DVD drive of the machine and start it. The installer will open. Follow the instructions on screen to complete the installation.

First, ensure the server follows the specifications above, then burn the ISO onto a DVD or USB key and boot it on the server. The installer will open. Follow the instructions on screen to complete the installation.

All Systems:

As a first configuration step, enable 802.1X globally on the switch. Use the following:

The next step is to configure AAA so it will use the newly created PacketFence server. Replace the PF_MANAGEMENT_IP variable with the actual PacketFence management IP (172.20.100.2 in this example) in the following commands:

Once AAA is ready, configure some or all switchports to perform 802.1X. In this example, only configure port no. 10 to use 802.1X:

Write the switch configuration to memory.

From Configuration → Policies and Access Control → Authentication Sources, click New external source → Email. As Name and Description, specify email-source.

Additional options available

Then add an Authentication Rules with name catchall with no condition and with the following two Actions:

Click on Create to save the new authentication source.

Now let’s add our new Email-based authentication source to our guests captive portal. From Configuration → Policies and Access Control → Connection Profiles, click on the guest profile that we previously created. In the Sources, click on the (+) button and add the newly created Email source, email-source. Save the changes by clicking on the Save button.

Unplug and unregister your endpoint. Reconnect the endpoint - you should see the captive portal with the new Email-based registration option.

Now that you understand what authentication sources and alerting are, we will add an SMS authentication source on our guest portal. We previously used the 'Null` source but we will add another source. Portal profiles can provide multiple authentication sources.

From Configuration → Policies and Access Control → Authentication Sources, click New external source → SMS. As Name and Description, specify sms-source. Then add an Authentication Rules with name catchall with no condition and with the following two Actions:

You will also need to select the proper carriers to do your test. Make sure you include the one your are using for your cellular phone.

Click on Create to save the new authentication source.

To use Clickatell as an SMS source, first register at https://www.clickatell.com to get an API Key for the SMS integration. Then add it as an authentication source the same way as above, except choosing Clickatell instead of SMS in Add source → External. Enter a name, description and your Clickatell API key in the source configuration, then add the authentication rule.

Now let’s add our new SMS-based authentication source to our guests captive portal. From Configuration → Policies and Access Control → Connection Profiles, click on the guest profile that we previously created. In the Sources, click on the (+) button and add the newly created SMS source, sms-source. Save the changes by clicking on the Save button.

First unplug and unregister again the Microsoft Windows 7 endpoint. Then, connect the endpoint in switch port no. 10 - you should see the captive portal with the new SMS-based registration option. Note that the Null option will also be offered.

Many NAC solutions cannot support unmanageable devices like entry-level consumer switches or access-points. PacketFence inline mode supports these devices in-band. PacketFence becomes the gateway for the inline network, using IPTables/IPSet to NAT or route traffic to the Internet or other network sections.

No special configuration needed on unmanageable devices. Simply ensure the device communicates on the inline VLAN. All traffic passes through PacketFence as it serves as the VLAN gateway.

Access control relies entirely on IPTables/IPSet. When unregistered users connect to inline VLAN, PacketFence assigns IP addresses. Users are marked as unregistered in ipset session - web traffic redirects to captive portal, other traffic is blocked. After registration through captive portal (like VLAN enforcement), PacketFence updates the device’s ipset session to allow the user’s MAC address through.

Inline enforcement has several limitations due to its nature:

This is why it is considered a poor man’s way of doing access control. We have avoided it for a long time because of the above mentioned limitations. That said, being able to perform both inline and VLAN enforcement on the same server at the same time is a real advantage: it allows admins to maintain maximum security while they deploy new and more capable network hardware providing a clean migration path to VLAN enforcement.

VLAN assignment is currently performed using several different techniques. These techniques are compatible one to another, but not on the same switch port. This means that you can use the more secure and modern techniques for your latest switches and another technique on the old switches that doesn’t support latest techniques. As it’s name implies, VLAN assignment means that PacketFence is the server that assigns the VLAN to a device. This VLAN can be one of your VLANs or it can be a special VLAN where PacketFence presents the captive portal for authentication or remediation.

VLAN assignment effectively isolate your hosts at the OSI Layer2 meaning that it is the trickiest method to bypass and is the one which adapts best to your environment since it glues into your current VLAN assignment methodology.

When the VLAN isolation is working through SNMP traps all switch ports (on which VLAN isolation should be done) must be configured to send SNMP traps to the PacketFence host. On PacketFence, we use snmptrapd as the SNMP trap receiver. As it receives traps, it reformats and sends them into a redis queue, managed by pfqueue service. The multiprocessed pfqueue service reads these traps from the redis queue and takes a decision based on type of traps. For example, it can respond to them by setting the switch port to the correct VLAN. Currently, we support switches from Cisco, Edge-Core, HP, Intel, Linksys and Nortel (adding support for switches from another vendor implies extending the pf::Switch class). Depending on your switches capabilities, pfqueue will act on different types of SNMP traps.

You need to create a registration VLAN (with a DHCP server, but no routing to other VLANs) in which PacketFence will put unregistered devices. If you want to isolate computers which have open security event in a separate VLAN, an isolation VLAN needs also to be created.

In previous versions of PacketFence, it was not possible to have RADIUS enabled for inline enforcement mode. Now with the new hybrid mode, all the devices that supports 802.1X or MAC-authentication can work with this mode. Let’s see how it works.

You need to configure inline enforcement mode in PacketFence and configure your switch(es) / access point(s) to use the VLAN assignment techniques (802.1X or MAC-authentication). You also need to take care of a specific parameter in the switch configuration window, "Trigger to enable inline mode". This parameter is working like a trigger and you have the possibility to define different sort of triggers:

where ALWAYS means that the device is always in inline mode, PORT specify the ifIndex of the port which will use inline enforcement, MAC a mac address that will be put in inline enforcement technique rather than VLAN enforcement and SSID an ssid name. An example:

This will trigger all the nodes that connects to the GuestAccess SSID to use inline enforcement mode (PacketFence will return a void VLAN or the inlineVlan if defined in switch configuration) and the MAC address 00:11:22:33:44:55 client if it connects on another SSID.

The concept of having a RADIUS enforcement is to not use registration, isolation, nor the portal capabilities of PacketFence. Everything here is for RADIUS integration only. By default the management interface will be the RADIUS interface. If needed, it is possible to add another interface from Configuration → Network Configuration → Networks → Interface. When doing so, you must select Other as the type of interface. Moreover, you must select radius as an additionnal listening daemon.

Using RADIUS enforcement, everytime a device connects to the network, a matching production VLAN will be assigned, depending on the rules in Configuration → Policies and Access Control → Authentication Sources.

DNS enforcement allows you to control the network access of the device by using the pfdns service on PacketFence.

The architecture of DNS enforcement is as following :

This enforcement mode used by itself can be bypassed by the device by using a different DNS server or by using its own DNS cache.

The first can be prevented using an ACL on your routing equipment, the second can be prevented by combining DNS enforcement with Single-Sign-On on your network equipment. Please see the Firewall Single-Sign-On documentation for details on how to accomplish this.

In order to configure DNS enforcement, you first need to go in Configuration → Network Configuration → Networks → Interface then select one of your interfaces and set it in DNS enforcement mode.

After, you must configure a routed network for this interface by clicking New routed network. See the Routed Networks section of this document for details on how to configure it.

Once this is done, you must restart the pfdhcp and pfdns services.

In previous sections, we correctly configured our switch to do 802.1X. Now let’s slightly modify that configuration so that we enable MAC authentication and 802.1X on a new switch port. This will demonstrate the configuration differences.

Once AAA is ready, we can configure some or all switchports to perform MAB (MAC Authentication Bypass) and 802.1X. In our example, we will only configure port no. 11 without VoIP support:

If you want to test some ports with a VoIP phone (ex: Voice VLAN 200), add the following lines to your interface configuration:

Finally, for some operations (like VoIP), PacketFence still need to have SNMP access to the switch. Make sure you configure the two SNMP communities like:

When done, don’t forget to save your configuration changes using the write mem command.

You can now test the registration process. In order to do so:

On the computer:

Register the computer using the Null authentication source.

Once a computer has been registered, make sure:

For VLAN assignment issues, verify switch configuration and trace RADIUS attributes as described in RADIUS Debugging and Network Connectivity Issues in the Troubleshooting section.

We’ve updated the structure of domain.conf file since v14.0, the section name stored in domain.conf file has been changed from domain identifier to hostname + domain identifier combination. This change causes a node in a cluster to read domain settings from its own individual section identified by its unique hostname. Therefore, it is not required to use %h as (or as a prefix / suffix of) the machine account anymore. Now it’s technically possible to have fully customized domain settings for a specific node.

In order to troubleshoot unsuccessful binds, please refer to the following file : /usr/local/pf/log/packetfence.log. Search for ntlm-auth-api-domain for all ntlm-auth-api entries.

To check the service status and journal log, use

for domain specific logs. Replace [domain_id] with the domain

To test the authentication process, use the following command

Now define the domain to use as the default one by creating the following realm in Configuration → Policies and Access Control → Domains → REALMS.

Next, restart PacketFence in Status → Services

First configure the domains in Configuration → Policies and Access Control → Domains → Active Directory Domains.

Once they are configured, go in Configuration → Policies and Access Control → Domains → REALMS.

Create a new realm that matches the DNS name of the domain AND one that matches the workgroup. In the case of this example, it will be DOMAIN.NET tied to mydomain.

Where :

Now associate DEFAULT and NULL realms to the domain.

The following realm configuration should now be in place

PacketFence supports multiple domain authentications as well as authentications performed against domains and subdomains.

But be aware that according to Windows Domain Controller’s architecture and implementation, PacketFence cannot be joined on a subdomainif the subdomain shares the Domain Controller with the existing parent domain.

The only way to join PacketFence on a subdomain is to join it on a subdomain who has its own Domain Controller that belongs to a parent domain.

Check Microsoft’s Learn, FAQ and discussions about subdomain computer joining. https://learn.microsoft.com/en-us/answers/questions/342052/can-create-an-sub-domain-and-add-user-uder-the-cre

PacketFence supports domain trust relations to be passed to the correct Domain Controller. However, there isn’t a way to configure the trusted domain settings from the Admin UI.

To authentication resources on a trusted domain, use the "--domain=" option in ntlm_auth_wrapper. Manually modify PacketFence’s FreeRADIUS mschap module template file located at /usr/local/pf/conf/radiusd/mschap.conf Locate the best mschap section that works for the situation and add a --domain=DOMAIN_TRUST_SETTINGS to the ntlm_auth_wrapper executable path.

After saving the changes, re-generate the FreeRADIUS configuration by restarting radius services and test if it works.

To use Google as a OAuth2 provider, get an API key to access their services. Sign up here : https://code.google.com/apis/console. In the Google APIs Console, go into Credentials → Create Credentials → OAuth client ID → Web Application, then enter a name and use this URI for the Authorized redirect URIs field : https://YOUR_PORTAL_HOSTNAME/oauth2/callback. Of course, replace the hostname with the values from general.hostname and general.domain. Save to get the Client ID and Client secret.

Keep the default configuration, modify the App ID & App Secret (Given by Google on the developer platform) and Portal URL (https://YOUR_PORTAL_HOSTNAME/oauth2/callback).

Also, add the following Authorized domains : *.google.com, *.google.ca, *.google.fr, *.gstatic.com,googleapis.com,accounts.youtube.com (Ensure to have the google domain from the appropriate country like Canada ⇒ *.google.ca, France ⇒ *.google.fr, etc…​)

Once the client id, and API key are available, configure the OAuth2 provider. This can be done by adding a Google OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add Google as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Facebook as an authentication source, an API code and a secret key are also needed. To get one, go here: https://developers.facebook.com/apps. When creating the App, specify the following as the Website URL: https://YOUR_PORTAL_HOSTNAME/oauth2/callback Of course, replace the hostname with the values from general.hostname and general.domain.

To find the secret, go in the newly created app, and click on Settings → Basic.

While in Settings → Basic, add YOUR_PORTAL_HOSTNAME in the App Domains field. Next, add the product Facebook Login. Click on Set up, and choose Web platform. Go through the 5 steps, then on the left side of the screen, go in Settings under Facebook Login. For Valid OAuth Redirect URIs, enter https://YOUR_PORTAL_HOSTNAME/oauth2/callback and then save changes.

Also, add the following Authorized domains : *.facebook.com, *.fbcdn.net, *.akamaihd.net, *.akamaiedge.net, *.edgekey.net, *.akamai.net (May change)

Once the information is available, configure the OAuth2 provider. This can be done by adding a Facebook OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Keep the default configuration, modify the App ID & App Secret (Given by Facebook on the developer platform) and Portal URL (https://YOUR_PORTAL_HOSTNAME/oauth2/callback).

Moreover, don’t forget to add Facebook as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Github, an API code and a secret key are also needed. To get one, create an App here: https://github.com/settings/applications/new. When creating the App, specify the following as the Callback URL https://YOUR_PORTAL_HOSTNAME/oauth2/callback

Of course, replace the hostname with the values from general.hostname and general.domain.

Once the information is available, configure the OAuth2 provider. This can be done by adding a GitHub OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add GitHub as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Kickbox, an API key is needed. To get one, first create an account on https://kickbox.io, then navigate to https://app.kickbox.com/settings/keys. Click on API Keys → Create Key. Pick a name and choose Production mode and Single verification.

Once the API key is available, configure the OAuth2 provider. This can be done by adding a Kickbox authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add Kickbox as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use LinkedIn, an API code and a secret key are also needed. To get one, create an App here: https://developer.linkedin.com/. When creating the App, specify the following as the Callback URL https://YOUR_PORTAL_HOSTNAME/oauth2/callback

Get more details about how to configure the LinkedIn application inside Microsoft documentation.

Of course, replace the hostname with the values from general.hostname and general.domain.

Once the information is available, configure the OAuth2 provider. This can be done by adding a LinkedIn OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add LinkedIn as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

Using OpenID Connect is a bit different than other OAuth2 sources. The reason behind that is because setting up a custom OpenID Connect source or depending on a provider for it. Configuration like token path, authorize path or API URL are specific to the setup. For more information on how to create one’s own or get a host please visit: https://openid.net/connect/.

When creating the App, specify the following as the Callback URL, https://YOUR_PORTAL_HOSTNAME/oauth2/callback.

Of course, replace the hostname with the values from general.hostname and general.domain.

OpenID connect have different ways to be configured, create a client ID and a client secret to work with PacketFence.

Once the information is available, configure the OAuth2 provider. This can be done by adding an OpenID OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add OpenID as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Twilio, first create an account on https://www.twilio.com. From the console (dashboard) https://www.twilio.com/console create a 3rd Party Integration. Note the Account SID and Auth Token for later use. From the Phone Manager https://www.twilio.com/console/phone-numbers/incoming click the + button to Buy a number with SMS capability - no payment is needed to start using this phone number right away.

Once the information is available, configure the OAuth2 provider. This can be done by adding a Twilio OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Enter the Account SID, Auth Token and Phone Number (From) from above. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add Twilio as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Windows live, an API code and a secret key are also needed. To get one, create an App here: .https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade When creating the App, specify the following as the Callback URL https://YOUR_PORTAL_HOSTNAME/oauth2/callback replacing the hostname with the values from general.hostname and general.domain.

Once the information is available, configure the OAuth2 provider. This can be done by adding a WindowsLive OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

The App ID in PacketFence will be Application (client) ID in the Azure portal.

The App secret must be a client secret created in the Certificates & secrets section of the app on Azure AD. Note that Azure AD secrets do expire so set a reminder to update the secret before it expires.

Moreover, don’t forget to add WindowsLive as a Source from the connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

Open the admin interface and go to Configuration → Policies and Access Control → Authentication Sources.

First, create RADIUS sources for each Eduroam servers you want to define.

To do that click New internal source and choose RADIUS.

Fill the Name, Description, Host, Port, Secret and disable Monitor. (The information to configure that source could be found on the Eduroam platform)

Next click on Exclusive Sources and click on New exclusive source then Eduroam.

Associate the Radius sources you previously configured in Eduroam RADIUS AUTH section, define the radius listening port and keep the type to Keyed Balance.

In order to handle correctly external and internal students with the Eduroam source, you will need to:

Go to Configuration → Policies and Access Control → Connection Profiles → New Connection Profile.

Create a connection profile named External Eduroam authentication Check Automatically register devices then create a Realm filter eduroam. Make sure to add the previously created Eduroam source to match on the external users.

Go to Configuration → Policies and Access Control → Connection Profiles → New Connection Profile.

Create a connection profile named Local Eduroam authentication Check Automatically register devices then create a SSID filter Eduroam. Make sure to add the AD source to match on the local users.

First, you need to refer to the previous step Configure the Eduroam source.

For this use case, there is no need to create a connection profile in PacketFence. FreeRADIUS will only perform a NTLM Auth and won’t send RADIUS request to PacketFence API.

PacketFence supports SAML authentication in the captive portal in combination with another internal source to define the level of authorization of the user.

First, transfer the Identity Provider metadata on the PacketFence server. In this example, it will be under the path /usr/local/pf/conf/idp-metadata.xml.

Then, transfer the certificate and CA certificate of the Identity provider on the server. In this example, they will be under the paths /usr/local/pf/conf/ssl/idp.crt and /usr/local/pf/conf/ssl/idp-ca.crt. If it is a self-signed certificate, then you will be able to use it as the CA in the PacketFence configuration. Make sure -----BEGIN CERTIFICATE----- and -----END CERTIFICATE---- headers are present in these certificate files.

Then, to configure SAML in PacketFence, go in Configuration → Policies and Access Control → Sources and then create a new Internal source of the type SAML and configure it.

Where :

Once this is done, save the source and you will be able to download the Service Provider metadata for PacketFence using the link Download Service Provider metadata on the page.

Configure the identity provider according to the generated metadata to complete the Trust between PacketFence and the Identity Provider.

In the case of SimpleSAMLPHP, the following configuration was used in metadata/saml20-sp-remote.php :

For users to access the Identity Provider login page, activate passthroughs and add the Identity Provider domain to the allowed passthroughs.

To do so, go in Configuration → Network Configuration → Networks → Fencing, then check Passthroughs and add the Identity Provider domain name to the Passthroughs list.

Next, restart pfdns services to apply the new passthroughs.

First select a billing provider and follow the instructions below.

Once you have configured one or more billing source, you need to define billing tiers which will define the price and target authentication rules for the user.

In the admin interface, go to Configuration → Advanced Access Configuration → Billing tiers

Then click Add billing tier and configure it.

Where :

PacketFence supports subscription based billing using Stripe as a billing provider.

PacketFence allows users to extend their access before it has ended. In order to do so, enable Allow access to registration portal when registered accessible via the Captive Portal tab of the Connection Profiles. Once this is activated, the users can reach https://PORTAL_IP/status and select Extend access in order to be able to access the billing section after they have registered.

This should provide the information about whether or not the username/password combination is valid

These information are available through the POST fields of the request

The server should reply with two attributes in a JSON response

Example JSON response :

This should provide the actions to apply on a user based on it’s attributes

The following attributes are available for the reply : access_duration, access_level, sponsor, unregdate, category.

Sample JSON response, note that not all attributes are necessary, only send back what you need.

In PacketFence, you need to configure an HTTP source in order to use an external API.

Here is a brief description of the fields :

Currently, PacketFence requires that multi-factor authentication be disabled for the PacketFence app. If you use Azure AD premium, you can create a rule to exclude this only for the PacketFence application. If you don’t use Azure AD premium, this must be disabled for all your users.

With this configuration, you can now use this source in your connection profiles to authenticate and authorize users on the captive portal and use it with EAP-TLS to authorize users (getting the role and access duration) as long as your EAP-TLS certificates use the distinguished name of the Azure AD users as their common name. Additionally, you can use this source for authenticating users in the admin interface and for VPN access.

In the admin interface, go to Configuration → System Configuration → Admin Login and enable 'SSO Status'. To enforce SSO policy for login (disable username/password), disable 'Allow username/password authentication'.

Configure 'SSO Base URL' if PacketFence captive portal uses different name than 'Hostname' and 'Domain' values in 'General Configuration'.

Configure connection profile for administrator authentication. In the admin interface, go to Configuration → Policies and Access Control → Connection Profiles and create new connection profile:

Restart api-frontend and httpd.portal. Admin interface login page shows new 'Single Sign On' option (text changeable in 'Admin Login' configuration).

Any portal authentication mechanism (SAML, Akamai MFA, TOTP, etc) can authenticate administrators. Refer to appropriate sections in this guide to configure features on administrator authentication connection profile.

Adjust captive portal policy configuration for administrator authentication as needed. Portal modules provide flexibility and customization. Modify 'Default admin SSO policy' in Configuration → Advanced Access Configuration → Portal Modules or create custom policy for administrator authentication connection profile. See Portal Modules section for captive portal customization.

This should provide the information about whether or not the username/password combination is valid

These information are available through the POST fields of the request

The server should reply with two attributes in a JSON response

Example JSON response :

This should provide the actions to apply on a user based on it’s attributes

The following attributes are available for the reply : access_duration, access_level, sponsor, unregdate, category.

Sample JSON response, note that not all attributes are necessary, only send back what you need.

In PacketFence, you need to configure an HTTP source in order to use an external API.

Here is a brief description of the fields :

Currently, PacketFence requires that multi-factor authentication be disabled for the PacketFence app. If you use Azure AD premium, you can create a rule to exclude this only for the PacketFence application. If you don’t use Azure AD premium, this must be disabled for all your users.

With this configuration, you can now use this source in your connection profiles to authenticate and authorize users on the captive portal and use it with EAP-TLS to authorize users (getting the role and access duration) as long as your EAP-TLS certificates use the distinguished name of the Azure AD users as their common name. Additionally, you can use this source for authenticating users in the admin interface and for VPN access.

In the admin interface, go to Configuration → System Configuration → Admin Login and enable 'SSO Status'. To enforce SSO policy for login (disable username/password), disable 'Allow username/password authentication'.

Configure 'SSO Base URL' if PacketFence captive portal uses different name than 'Hostname' and 'Domain' values in 'General Configuration'.

Configure connection profile for administrator authentication. In the admin interface, go to Configuration → Policies and Access Control → Connection Profiles and create new connection profile:

Restart api-frontend and httpd.portal. Admin interface login page shows new 'Single Sign On' option (text changeable in 'Admin Login' configuration).

Any portal authentication mechanism (SAML, Akamai MFA, TOTP, etc) can authenticate administrators. Refer to appropriate sections in this guide to configure features on administrator authentication connection profile.

Adjust captive portal policy configuration for administrator authentication as needed. Portal modules provide flexibility and customization. Modify 'Default admin SSO policy' in Configuration → Advanced Access Configuration → Portal Modules or create custom policy for administrator authentication connection profile. See Portal Modules section for captive portal customization.

Provides users a choice between multiple sources using advanced filtering rules, manual selection of the Sources and selection of the Portal Modules.

All the defined "Sources" and "Modules" are available for use. Mandatory fields can be defined in the module, but they will only be shown if applicable to the Source.

Dynamically select a Source from the Connection Profile based on an object attribute (Object Class, Authentication Type, Authentication Class).

Manually define specific roles when registering a device. This is useful for a technical crew to register new devices.

In Configuration → Advanced Access Configuration → Portal Modules, click "New Module" and select type "Other → Select Role". In "Admin Roles" chose the user role(s) that is required to use this module. In "Roles" choose the user role(s) that can then be assigned.

For example; technicians in the AD group technical support will have the role technical support while registering. In "Admin Roles" add technical support, then in "Roles" add default, voice and guest. Technicians that have the technical support role will be prompted to assign either the default, voice or guest role when registering a new device.

The on_failure and on_success "Actions" allow the creation of a more complex workflow and permit the root portal module change based on the result of authentication.

Consider that a root portal module is linked to an Authentication::Login module and associated with a Connection Profile. In order to present a Guest authentication if the login failed, configure a New Root Module called "Guest portal policy" with the "Module" set to Authentication::SMS, and in the previous "Authentication::Login" module add the "Action" on_failure ⇒ Guest portal policy.

To automatically create the database tables required by the Survey, the MySQL pf user must be granted the CREATE and ALTER privileges. The MySQL root user must be used to GRANT these privileges.

Access the MYSQL CLI as the root user:

From the MySQL CLI grant the privileges:

Configure the survey in /usr/local/pf/conf/survey.conf. Here is an example of a survey:

The Captive Portal will now collect some data from the user (ex: survey1 field firstname) and some data contextually (ex: survey1 data ssid).

The available parameters to collect user data are defined as:

The available parameters to use contextual data are defined as:

In Configuration → Advanced Access Configuration → Portal Modules, click "New Module" and select type "Other → Survey". Use the following setting then click Create:

Add the survey to an existing Portal Module (Choice, Chained or Root) or create a New Root Module dedicated for the survey:

In "Policies and Access Control → Connection Profiles → Name of the profile", ensure the correct "Root Portal Module" is selected.

The data collected from the example survey is stored in the survey_survey1 database table. Create a Report for the survey in /usr/local/pf/conf/report.conf and add the following parameters:

Refer to the Reports section of this document for advanced configuration.

Once configured, optionally for security, it is recommended to revoke the CREATE and ALTER privileges from the pf user. The MySQL root user must be used to REVOKE these privileges.

Access the MYSQL CLI as the root user:

From the MySQL CLI revoke the privileges:

In Configuration → Network Configuration → Networks → Fencing → Passthroughs, add passthroughs with the format:

When pfdns receives a DNS request for a passthrough domain it will forward the unaltered DNS record for the FQDN instead of a response for the Captive Portal. An ipset entry will be added to permit the device to access the real external IP address for the FQDN via iptables routing.

In Configuration → Network Configuration → Networks → Fencing, add a comma-separated list of FQDNs in "Proxy Passthroughs", including wildcard domains like *.example.com. Only TCP port 80 is used, so do not specify ports. Click Save.

When pfdns receives a DNS request it will respond with the IP address of the Captive Portal, and when the device makes a HTTP request on the Captive Portal for a FQDN that has a configured passthrough the request is forwarded through mod_proxy.

In Configuration → Compliance → Security Events, choose Security Event 1300003, configure how the event is handled when a device is parked:

Match machine authentication on secure wireless ssid:

Match machine authentication from a previous connection and is connected on a secure ssid:

Match user authentication and machine authentication on a secure ssid:

Match user authentication without machine authentication on a secure ssid:

Match without machine authentication (BYOD):

Example of attributes that can be filtered:

PacketFence uses Apache for its captive portal, administration interface and Web services. The PacketFence Apache configuration is located in /usr/local/pf/conf/httpd.conf.d/.

purposes:

These files are dynamically generated with Perl and services are only activated on the network interfaces needed for each purpose.

The other files in this directory are managed by PacketFence using templates, so it is easy to modify these files based on the configuration. SSL is enabled by default to secure access.

During installation self-signed certificates will be created in /usr/local/pf/conf/ssl/ (server.key and server.crt). The certificates can be replaced anytime by either a 3rd-party or existing wildcard certificate without issue. Please note that the CN (Common Name) needs to be the same as the one defined in the PacketFence configuration file /usr/local/pf/conf/pf.conf.

In certain circumstances - for example to show an AUP after a successful 802.1X connection - "SSO emulation" may be used so that users do not need to re-enter their credentials on the portal after having entered them during 802.1X EAP. The connection profile option Reuse 802.1X credentials can be enabled for this purpose. The username used during the 802.1X connection will be reused with the different authentication sources to recompute the role from the portal.

As a security precaution, this option will only reuse 802.1X credentials if there is an authentication source matching the provided realm. This means, when users use 802.1X credentials with a domain part (username@domain, domain\username), the domain part needs to be configured as a realm under the RADIUS section and an authentication source needs to be configured for that realm. When users do not use 802.1X credentials with a domain part, only the NULL realm will be matched IF an authentication source is configured for it.

Upper case string.

Example:

assigns the upper case value of Calling-Station-Id to PacketFence-UserName.

Lower case string.

Example:

assigns the lower case value of User-Nam to PacketFence-UserName.

Join strings.

Example:

assign the joined string of the values and separator to PacketFence-UserName.

A part of a string.

Example:

assigns the first 6 characters of a string to PacketFence-UserName.

EUI48 format of a MAC address.

Example:

assigns the EUI48 MAC address to PacketFence-UserName.

A random integer between a range.

Example:

assigns a random integer between 10620 and 12600 to Session-Timeout.

Log a message in packetfence.log.

Example:

logs the value of the RADIUS request attribute User-Name appended with " logged".

Replace a string or character.

Example:

replace the character "z" by the character "r" from User-Name and assign it to PacketFence-UserName.

Regular expression match on a string or character.

Example:

extract the value from TLS-Client-Cert-Common-Name before the @ sign and assign it to TLS-Stripped-UserName.

LDAPfilter actions override the internal LDAP filter that PacketFence creates internally (uid=$username) so a custom filter can be created that matches specific needs.

Example user search that checks permission based on some criteria:

set_role_on_not_found defines a role if the rule does not match.

Adding the action set_role_on_not_found = REJECT will reject the device if the LDAP filter match returns empty. On the other hand, if a filter match is found then the set_role action is applied.

role_from_source checks if the LDAP attribute exists, if so it is added in the ldap_attribute context (available in the RADIUS filters).

Example that takes the LDAP attribute customRadius value and adds it in the RADIUS answer. In the authentication rule add an action "Role from source" to customRadius. Next create a RADIUS filter that will add the custom RADIUS attributes: