Installation Guide

Red Hat Enterprise Linux users need to take an additional setup step. If you are not using the RHN Subscription Management from Red Hat you need to enable the optional and extras channels by running the following as root:

In order to use the PacketFence repository:

Once the repository is defined, you can install PacketFence with all its dependencies, and the required external services (database server, DHCP server, RADIUS server) using:

In order to use the repository, create a file named /etc/apt/sources.list.d/packetfence.list:

Once the repository is defined, you can install PacketFence with all its dependencies, and the required external services (Database server, DHCP server, RADIUS server) using:

802.1X provides port-based authentication, which involves communications between a supplicant, authenticator (known as NAS), and authentication server (known as AAA). The supplicant is often software on a client device, such as a laptop, the authenticator is a wired Ethernet switch or wireless access point, and the authentication server is generally a RADIUS server.

The supplicant (i.e., client device) is not allowed access through the authenticator to the network until the supplicant’s identity is authorized. With 802.1X port-based authentication, the supplicant provides credentials, such as user name / password or digital certificate, to the authenticator, and the authenticator forwards the credentials to the authentication server for verification. If the credentials are valid (in the authentication server database), the supplicant (client device) is allowed to access the network. The protocol for authentication is called Extensible Authentication Protocol (EAP) which have many variants. Both supplicant and authentication servers need to speak the same EAP protocol. Most popular EAP variant is PEAP-MsCHAPv2 (supported by Windows / Mac OSX / Linux for authentication against AD).

In this context, PacketFence runs the authentication server (a FreeRADIUS instance) and will return the appropriate VLAN to the switch. A module that integrates in FreeRADIUS does a remote call to the PacketFence server to obtain that information. More and more devices have 802.1X supplicant which makes this approach more and more popular.

MAC Authentication is a new mechanism introduced by some switch vendor to handle the cases where a 802.1X supplicant does not exist. Different vendors have different names for it. Cisco calls it MAC Authentication Bypass (MAB), Juniper calls it MAC RADIUS, Extreme Networks calls it Netlogin, etc. After a timeout period, the switch will stop trying to perform 802.1X and will fallback to MAC Authentication. It has the advantage of using the same approach as 802.1X except that the MAC address is sent instead of the user name and there is no end-to-end EAP conversation (no strong authentication). Using MAC Authentication, devices like network printer or non-802.1X capable IP Phones can still gain access to the network and the right VLAN.

Wireless 802.1X works like wired 802.1X and MAC authentication is the same as wired MAC Authentication. Where things change is that the 802.1X is used to setup the security keys for encrypted communication (WPA2-Enterprise) while MAC authentication is only used to authorize (allow or disallow) a MAC on the wireless network.

On wireless networks, the usual PacketFence setup dictate that you configure two SSIDs: an open one and a secure one. The open one is used to help users configure the secure one properly and requires authentication over the captive portal (which runs in HTTPS).

The following diagram demonstrates the flow between a mobile endpoint, a WiFi access point, a WiFi controller and PacketFence:

Web authentication is a method on the switch that forwards HTTP traffic of the device to the captive portal. With this mode, your device will never change of VLAN ID but only the ACL associated to your device will change. Refer to the Network Devices Configuration Guide to see a sample web auth configuration on a Cisco WLC.

Relies on the port-security SNMP Traps. A fake static MAC address is assigned to all the ports this way any MAC address will generate a security violation and a trap will be sent to PacketFence. The system will authorize the MAC and set the port in the right VLAN. VoIP support is possible but tricky. It varies a lot depending on the switch vendor. Cisco is well supported but isolation of a PC behind an IP Phone leads to an interesting dilemma: either you shut the port (and the phone at the same time) or you change the data VLAN but the PC doesn’t do DHCP (didn’t detect link was down) so it cannot reach the captive portal.

Aside from the VoIP isolation dilemma, it is the technique that has proven to be reliable and that has the most switch vendor support.

When a host connects to a switch port, the switch sends a linkUp trap to PacketFence. Since it takes some time before the switch learns the MAC address of the newly connected device, PacketFence immediately puts the port in the Registration VLAN in which the device will send DHCP requests in order for the switch to learn its MAC address. Then pfqueue will send periodical SNMP queries to the switch until the switch learns the MAC of the device. When the MAC address is known, pfqueue checks its status (existing ? registered ? any security event?) in the database and puts the port in the appropriate VLAN. When a device is unplugged, the switch sends a linkDown trap to PacketFence which puts the port into the Registration VLAN.

When a computer boots, the initialization of the NIC generates several link status changes. And every time the switch sends a linkUp and a linkDown trap to PacketFence. Since PacketFence has to act on each of these traps, this generates unfortunately some unnecessary load on pfqueue. In order to optimize the trap treatment, PacketFence stops every thread for a linkUp trap when it receives a linkDown trap on the same port. But using only linkUp/linkDown traps is not the most scalable option. For example in case of power failure, if hundreds of computers boot at the same time, PacketFence would receive a lot of traps almost instantly and this could result in network connection latency.

If your switches support MAC notification traps (MAC learned, MAC removed), we suggest that you activate them in addition to the linkUp/linkDown traps. This way, pfqueue does not need, after a linkUp trap, to query the switch continuously until the MAC has finally been learned. When it receives a linkUp trap for a port on which MAC notification traps are also enabled, it only needs to put the port in the Registration VLAN and can then free the process. When the switch learns the MAC address of the device it sends a MAC learned trap (containing the MAC address) to PacketFence.

In its most basic form, the Port Security feature remembers the MAC address connected to the switch port and allows only that MAC address to communicate on that port. If any other MAC address tries to communicate through the port, port security will not allow it and send a port-security trap.

If your switches support this feature, we strongly recommend to use it rather than linkUp/linkDown and/or MAC notifications. Why? Because as long as a MAC address is authorized on a port and is the only one connected, the switch will send no trap whether the device reboots, plugs in or unplugs. This drastically reduces the SNMP interactions between the switches and PacketFence.

When you enable port security traps you should not enable linkUp/linkDown nor MAC notification traps.

If you have a business account and do not want to configure a test environment, you can skip the next section.

Sandbox account

To configure a sandbox paypal account for use in PacketFence, head to https://developer.paypal.com/ and either sign up or login into your existing account.

Then in the Sandbox menu, click Accounts

Create an account that has the type Personal and one that has the type Business.

Afterwards, go back into accounts, and expand the business account, then click Profile

Now click the Change password link and change the password and note it.

Do the same thing with the personal account you created

Configuring the merchant account

Login into the Paypal business account that you created at https://www.sandbox.paypal.com/ if you are using a sandbox account or on https://www.paypal.com/ if you are using a real account.

Next go in My Account → Profile in order to go into your profile configuration.

Next in the Selling Preferences you will need to select Website Payment Preferences

Configure the settings so they match the screenshot below.

You should turn on Auto Return, set the return URL to https://YOUR_PORTAL_HOSTNAME/billing/paypal/verify.

You should also take note of the Identity Token as it will be required in the PacketFence configuration.

Next go back in your profile configuration My account → Profile and select Encrypted Payment Settings

Now on this page you will need to submit the certificate used by PacketFence to Paypal (/usr/local/pf/conf/ssl/server.crt by default).

Once you have submitted it, note it’s associated Cert ID as you will need to configure it in PacketFence.

Still on that page, click the Download link to download the Paypal public certificate and put it on the PacketFence server under path : /usr/local/pf/conf/ssl/paypal.pem

Configuring PacketFence

Now, in the PacketFence administration interface, go in Configuration→Policies and Access Control→Sources and create a new source of type Billing → Paypal.

Where :

Stripe account

First go on https://dashboard.stripe.com, create an account and login.

Next on the top right click Your account then Account settings.

Navigate to the API keys tab and note your key and secret. The test key should be used when testing the configuration and the live key when putting the source in production.

Configuring PacketFence

Now, in the PacketFence administration interface, go in Configuration→Policies and Access Control→Sources and create a new source of type Billing → Stripe

Where :

Creating an account

First go on https://account.authorize.net to signup for a merchant account or http://developer.authorize.net/ for a sandbox account.

After you created your account you will be shown your API login ID and Transaction key. Note both of these information for usage in the PacketFence configuration.

Then login into your new account.

Then under Account click Settings.

On the settings page in the section Security settings, click MD5-Hash

Now enter a secret that will be shared between authorize.net and PacketFence.

PacketFence configuration

Next in the PacketFence administration interface, go in Configuration→Policies and Access Control→Sources and create a new source of type Billing→AuthorizeNet.

Where :

When using subscription based billing, it is advised to configure the billing tier so it has an almost infinite access duration (e.g. 20 years) as the billing provider will be contacting the PacketFence server when the subscription is canceled.

You should configure a billing tier for each subscription plan you want to have. This example will use the plan simple and advanced configured using the following parameters.

Then in your Stripe dashboard, you should go in Subscriptions → Plans.

Then create a new plan.

Where :

Now, following the same procedure, create the advanced plan.

As the subscription can be cancelled by a user, you need to setup your PacketFence installation to receive updates from Stripe.

Updates are sent using HTTP requests on a public IP.

You need to make sure that your PacketFence server is available through a public IP on port 80 and that your PacketFence server hostname resolves on the public domain.

Then, in Stripe, configure a Webhook so Stripe informs PacketFence of any event that happens in this Stripe merchant account.

In order to do so go in Your Account → Account Settings → Webhooks and click Add endpoint.

Where :

Now every time a user unsubscribes from a plan, PacketFence will be notified and will unregister that device from your network.

First, create a custom root module for our examples in order to not affect the default policy. In order to do so, go in Configuration → Advanced Access Configuration → Portal Modules, then click Add Portal Module and select the type Root. Give it the identifier my_first_root_module and the description My first root module, then hit save.

Next, head to Configuration → Policies and Access Control → Connection Profiles, select the connection profile you use (most probably default) and then under Root Portal Module, assign My first root module then save your profile. If you were to access the captive portal now, an error would display since the Root module we configured doesn’t contain anything.

You could add some of the pre-configured modules to the new Root module you created and that would make the error disappear.

In order to prompt fields without authentication, you can use the Null source with the Null Portal Module.

PacketFence already comes with a Null source pre-configured. If you haven’t modified it or deleted it, you can use it for this example. Otherwise, go in Configuration → Policies and Access Control → Sources and create a new Null source with a catchall rule that assigns a role and access duration.

Then go in Configuration → Advanced Access Configuration → Portal Modules and click Add Portal Module and select Authentication → Authentication::Null. Set the Identifier to prompt_fields and configure the module with the Mandatory fields you want and uncheck Require AUP so that the user doesn’t have to accept the AUP before submitting these fields.

Next, add the prompt_fields module in my_first_root_module (removing any previous modules) and save it. Now when visiting the portal, it should prompt you for the fields you define in the module. Then, submitting these information will assign you the role and access duration that you defined in the null source.

If you want to prompt additional fields during the authentication process for a module, you can define a Module based on that source that will specify the additional mandatory fields for this source.

You can also add additional mandatory fields to the default policies that are already configured.

This example will make the default_guest_policy require the user to enter a first name, last name and address so that guests have to enter these three information before registering.

Go in Configuration → Advanced Access Configuration → Portal Modules and click the default_guest_policy. Add firstname, lastname and address to the Mandatory fields and save.

Next, add the default_guest_policy to my_first_root_module (removing any previous modules). Now when visiting the portal, any of the guest sources configured in your connection profile will require you to enter both the mandatory fields of the source (ex: phone + mobile provider) and the mandatory fields you defined in the default_guest_policy.

The portal modules allow you to chain two or more modules together in order to make the user accomplish all of the actions in the module in the desired sequence.

This example will allow you to configure a Chained module that will require the user to login via any configured OAuth source (Github, Google+, …​) and then validate his phone number using SMS registration.

For the OAuth login we will use the default_oauth_policy, so just make sure you have an OAuth source configured correctly and available in your Connection Profile.

Then, we will create a module that will contain the definition of our SMS registration.

Go in Configuration → Advanced Access Configuration → Portal Modules then click Add Portal Module and select Authentication → Authentication::SMS.

Configure the portal module so that it uses the sms source and uncheck the Require AUP option since the user will have already accepted the AUP when registering using OAuth.

Then, add another Portal Module of type Chained. Name it chained_oauth_sms, assign a relevant description and then add default_oauth_policy and sms to the Modules fields

Next, add the chained_oauth_sms module in my_first_root_module (removing any previous modules) and save it. Now when visiting the portal, you should have to authentication using an OAuth source and then using SMS based registration.

Note that if you add want to keep some fields the user previously filled you can add Saved fields in the portal module. Per example the first module ask for the telephone number and the second too, then you can add telephone as a Saved fields and the second module will not ask for it.

This example will guide you through configuring a portal flow that will allow for devices to access an open SSID using an LDAP username/password but also give the choice to configure the Secure SSID directly from the portal.

First, we need to configure the provisioners for the Secure SSID onboarding. Refer to section Apple and Android Wireless Provisioning of this guide to configure your provisioners and add them to the connection profile.

Create a provisioner of the type Deny and add it with your other provisioners (putting any other provisioner before it). This will make sure that if there is no match on the other provisioners, it will not allow the device through.

Also in the connection profile add your LDAP source to the available sources so its the only one available.

Next, create a Provisioning portal module by going in Configuration → Advanced Access Configuration → Portal Modules. Set the Identifier to secure_boarding and the description to Board Secure SSID. Also uncheck Skippable so the user is forced to board the SSID should it choose this option.

Then, still in the Portal Modules, create a Choice module. Set the Identifier to login_or_boarding and description to Login or Boarding. Add secure_boarding and default_login_policy to the Modules field and save.

Next, add the login_or_boarding module in my_first_root_module (removing any previous modules) and save it. Now when visiting the portal, you will have the choice between login to the LDAP source and gain access to the network or directly use provisioning in order to configure your device for a Secure SSID.

Displaying a message to the user after the registration =

Using the Message module you can display a custom message to the user. You can also customize the template to display in order to display a fully custom page.

Go in Configuration → Advanced Access Configuration → Portal Modules, then click Add Portal Module and select Message. Set the Identifier to hello_world and the description to Hello World.

Then put the following in the Message field

Next, add default_registration_policy and hello_world in the Modules of my_first_root_module (removing any previous modules) and save it. Now when visiting the portal, you should have to authenticate using the sources defined in your connection profile and you will then see the hello world message.

Using the URL module, you can redirect the user to a local or external URL (as long as it is in the passthroughs). Then you can make it so the portal accepts a callback in order for the flow to continue.

In this example, the portal will redirect to an externally hosted PHP script that will give a random token to the user and then callback the portal to complete the registration process.

The example script is located in addons/example_external_auth/token.php and a README is available in that directory to set it up.

Once you have the script installed and working on URL: http://YOUR_PORTAL_HOSTNAME:10000/token.php, you can configure what you need on the PacketFence side.

Go in Configuration → Advanced Access Configuration → Portal Modules, then click Add Portal Module and select URL. Set the Identifier to token_system, the Description to Token system and the URL to http://YOUR_PORTAL_HOSTNAME:10000/token.php.

Next, add default_registration_policy and token_system in the Modules of my_first_root_module (removing any previous modules) and save it. Now when visiting the portal, you should have to authenticate using the sources defined in your connection profile and then you will be redirected to example token system. Clicking the continue link on that system will bring you back to the portal and complete the registration process.

When using such security event feature, setting the grace period is really important. You don’t want to put it too low (ie. A user re-enable his network, and get caught after 1 bytes is transmitted!) or too high. We recommend that you set the grace period to one interval window.

You will first need to create an SSO role on the web interface on the PaloAlto firewall.

Go to Device → Admin Roles → Add.

Create the role name SSO_Role, under the XML API tab, enable everything and validate it with OK.

Now you have created the role, you will associate an user with it.

Go to Device → Administrators → Add.

Go on this URL: https://@IP-of-PaloAlto/api/?type=keygen&user=xmluser&password=xmluser.

It should display:

Now that we have the key, we will configure the PaloAlto firewall in PacketFence.

Go to Configuration → Integration → Firewall SSO → Add Firewall → PaloAlto.

Now we will check that PacketFence is sending information when a user registers on the portal. If the process worked, you will see the entry in the PaloAlto database.

Use SSH on the PaloAlto firewall and run this command:

You will first need to create a filter to parse the SSO line that PacketFence will send. This can be done in User Identification→User Mapping

Next, configure the filter to be used in a syslog receiver on the Palo Alto. In order to do so, go in User Identification→User Mapping and configure a syslog sender.

Next you need to configure the firewall in PacketFence.

Go to Configuration → Integration → Firewall SSO → Add Firewall → PaloAlto.

Now we will check that PacketFence is sending information when a user registers on the portal. If the process worked, you will see the entry in the PaloAlto database.

Use SSH on the PaloAlto firewall and run this command:

You will first need to install OpenVAS along with XYZ and ABC in order to manage OpenVAS remotely via the omp command line.

In order to validate proper connectivity from PacketFence to OpenVAS for remote management, execute the following command (replacing admin by the user you wish to use for PacketFence to communicate with OpenVAS):

The output of the above command should provide you the version of OpenVAS. Otherwise, ensure all the necessary components are in place for management through the omp command line client and that PacketFence is able to communicate with OpenVAS on port 9390.

You will need to configure an alert policy in OpenVAS to inform PacketFence of the completion of a task. The httpd.portal daemon takes care of handling this callback so you’ll want to make sure that you have "portal" in your additionnal listening daemons on your management interface in PacketFence.

In order to create the alert policy, go in the Greenbone Security Assistant, then in "Configuration→Alerts" and create a new alert with the following configuration

Where:

Once you have connectivity working between PacketFence and OpenVAS, use the Greebone Security Assistant to obtain the following information for configuring PacketFence

Alert ID

Navigate to "Configuration→Alerts", then click on the alert you’ve configured above to view it, and note down the ID of the alert.

Scan config ID

Navigate to "Configuration→Scan Configs" and then select the scan configuration you would like to use to scan the hosts. In this scan config view, note down the ID.

Report format ID

Navigate to "Configuration→Report Formats" and then select the "CSV Results" report format. In this view, note down the ID.

Because of the CPU intensive nature of an automated vulnerability assessment, we recommend that it is hosted on a separate server for large environments. To do so, a couple of things are required:

If you are using the OpenVAS scanning engine:

If you are using the Nessus scanning engine:

First, you will need to create credentials for PacketFence so that it can perform API calls on Rapid7. In order to do so, go in Administration and click on "Create" in the "Users" section in Rapid7. Then configure the appropriate username and password and make sure the account is enabled.

Next, in the roles of that user, select the "Custom" role and assign at least the following privileges to the new user:

Next, in "Site access" and "Asset group access", ensure you provide access to this user to all the assets and sites it needs to manage. When in doubt, grant access to all sites and asset groups.

Once you have the user created, you need to create the scan engine by going in Configuration → Compliance → Scan Engines and creating a new scan engine of the type "Rapid7"

Notes on the configuration:

With the scan engine now created, you need to assign it to the connection profile that your endpoints use. In order to do so, go in Configuration → Connection Profiles, select your connection profile and add your scan engine there.

With the scan engine integration completed, PacketFence will now automatically start scans on the endpoints it sees DHCP for and you will be able to view the Rapid7 information of the endpoints by going in the Nodes tab in PacketFence and then viewing a node and browsing its Rapid7 tab.

In Rapid7:

Enable: Must be checked. Alert Name: Rsyslog to PacketFence or else. Maximum Alerts to send: blank (none) Scan events: Check all. Vulnerability Events: Any severity ; Check as well Confirmed, Unconfirmed, Potential Notification Method: Select Syslog message Syslog Server: PacketFence cluster VIP or server IP for a standalone

First, logon to PacketFence Server with a ssh terminal, then create the fifo pipe file that PacketFence will use to get data from Rapid7.

Create a new file named /etc/rsyslog.d/nexpose-log.conf with the following content

Next, modify /etc/rsyslog.conf to accept syslogs data on udp 514 by uncommenting the following two lines:

Restart the rsyslog service

At this point PacketFence must be able to get the Rapid7 audit results via syslog.

In the Packetfence administration interface, go to Configuration → Integration → Syslog parsers and add a new Nexpose syslog parser

Once done, restart the following services

Now that PacketFence is properly configured to receive information from Nexpose, we can configure it to perform some actions on the alerts it receives. In the PacketFence GUI, go to Configuration → Compliance → Security Events and create a new security event.

Make sure you set the following parameters in the Definition tab:

Next, in the Triggers tab:

For more info on security event actions, go to the Blocking malicious activities with security events section of this guide.

For Android provisioning support, you must activate and adjust the passthroughs. You might need to adapt them depending on your geolocality.

In the administation inferface, go in Configuration → Network Configuration → Networks → Fencing. Activate Passthrough and make sure the following passthroughs domains are present:

Then run the following commands so that passthroughs become effective:

Mac OS X/iOS require the provisioning profile to be signed if you want to remove the untrusted warning when installing the profile. For more information, please refer to the PKI guides referred earlier in Configure the feature above.

Let’s say that you now need to add some Linux computers as corporate devices.

Those devices cannot be authenticated via Machine Authentication, so we will need to use EAP-TLS and provide those devices with a certificate.

First of all make sure that your RADIUS certificate from the PacketFence server and the certificates that you will be provided are delivered from the same CA, else your authentication will not work. To enable EAP-TLS you will need to reconfigure the new RADIUS server certificate in the file conf/radiusd/eap.conf.

While creating the RADIUS server certifcate make sure to have the Extended key usage: servAuth.

Under the section tls-config tls-common, search for ‘private_key_file’, ‘certificate_file’ and ‘ca_file’. Those should contain respectively the path of:

If you have an OCSP capable PKI you can configure it in the section OCSP in the eap.conf file.

Lastely you will need to restart RADIUS to ensure the use of the new configuration and certificates. Please do the following:

Make sure everything happens without errors.

Now that your RADIUS is ready to handle EAP-TLS, configure your SSID connection profile on the corporate device using this method. Generate a client certificate for your device and install it on.

Please configure an EAPTLS source which can be found while adding a new sources under Internal->, simply give it a name, a description and a catch-all rule. This will allow you to validate the authentication via EAP-TLS.

You can now create a new Portal Profile for EAP-TLS. Under the tab configuration, section Policies and Access Control->Connection Profiles, Add profile and select as a filter the Sub Connection Type as EAP-TLS, add your source EAP-TLS. Check the box "Automatically register devices".

You now have a full flow working for your corporate devices.

The following is an example on how to configure an EAP-TLS connection for Windows/Android/Mac OS X/iOS

Mac OS X/iOS require the provisioning profile to be signed if you want to remove the untrusted warning when installing the profile. You need to sign it with a Certification Authority already trusted by the device such as e.g. VeriSign. Configuring this has to be done in the Signing tab in the "Apple devices".

Fill out the fields with the contents of the Base64 encoded certificates. To extract this information from a pem formatted certificate, copy the file content included between the begin and end tag, not including the delimiters themselves.

Certificate file example:

Copy everything between the BEGIN and END lines, but not the lines themselves. Repeat this operation for the certificate key and intermediate certificate.

One important step is to enable the MDM profile like in this screenshot. Note that this will require you to create an MDM certificate with Apple. Refer to the MobileIron documentation for specifics about this step.

Login in the PacketFence administration interface, then go in the Configuration tab, then in Provisioners. Click Add provisioner then select mobileiron.

Now configure this new provisioner with the information you got above.

Here are the URIs that should work by default. Replace accountName by your real account/instance name at MobileIron.

In order for the provisioner to be used by your captive portal you need to add it in its configuration. Go in Connection Profiles, then select the portal you want to modify and add mobileiron as a provisioner.

In order to enable the boarding passthrough for the device enrollment, you will need to restart the iptables service of PacketFence.

You can do this using the command line by doing /usr/local/pf/bin/pfcmd service iptables restart or in the administration interface under Status / Services.

Once this is done, click Register a new application. The only thing important here is to set the callback URL to http://127.0.0.1/opswat.

Once you created the application, note the client key and client secret for usage below.

First you will access this page using your browser (replace -clientid- by your client ID that you got when creating the application):

Authorize the application and you will then be redirected to an unavailable page but the URL will contain the code in it’s parameters (ex: http://127.0.0.1/opswat?code=wJ2RTE).

We will now use the code at the end to generate the access and refresh token using another HTTP request that will be done in your browser. Replace -clientid- and -clientsecret- by the client id and secret of your application. Then add the code you got above at the end of this URL.

You should now be presented with a JSON response that contains the access and refresh token. Take note of both of these values for the PacketFence configuration. Example:

Login in the PacketFence administration interface, then go in the Configuration tab, then in Provisioners. Click Add provisioner then select opswat.

Now configure this new provisioner with the information you got above.

Now that you have created the provisioner, go in the Connection Profiles menu on the left and select the default portal. Click Add Provisioner and select the new OPSWAT Metadefender Endpoint provisioner that was created earlier.

First you need to configure what you consider as a critical issue in your OPSWAT Metadefender Endpoint console.

You will do that through the Configure menu. Then you’ll see a column that allows you to flag what is considered as a critical issue.

Now in order to enforce the compliance of the devices using the flagged critical issues above, you will need to configure the provisioner you created above to activate the enforcement.

Back in the provisioner configuration, go in the Compliance tab.

You now have to configure the security event that is raised when a device is noncompliant. Using the Generic security event should fit your needs for now, and you can modify the template after.

Then configure the Critical issues threshold and put it at the minimum critical issues a device needs to have before it gets isolated.

Putting 1 into that field will isolate the device whenever there is at least one critical issue with the device.

You can then hit Save and now the device will get isolated whenever it’s found as noncompliant.

You can now customize the security event template from the Connection Profile section. Simply select your connection profile and then go in the Files tab.

You can then modify the template security_events/generic.html so it displays additional information.

You can also customize this security event from the Security Events section of the administration interface. Refer to the PacketFence Administration Guide for additional information about this.

Login in the PacketFence administration interface, then go in the Configuration tab, then in Provisioners. Click Add provisioner then select SentinelOne.

Where:

Now that you have created the provisioner, go in the Connection Profiles menu on the left and select the default connection profile. Click Add Provisioner and select the new SentinelOne that was created earlier.

Once you have completed the configuration, you need to restart pfdns in order for the SentinelOne specific passthroughs to be taken into consideration.

On your computer open a browser and access https://192.168.1.100:8446/sepm.

Accept any certificate error and login with your SEPM credentials.

On the left of the screen, click Add an application and give it a name.

You should now see your application in the list on the right.

Take note of the Client ID and Client Secret of your application

First you will access this page using your browser (replace -clientid- by your client ID that you got when creating the application)

Authorize the application and you will then be redirected to an unavailable page but the URL will contain the code in it’s parameters (ex: http://127.0.0.1/?code=wJ2RTE).

We will now use the code at the end to generate the access and refresh token using another HTTP request that will be done in your browser. Replace -clientid- and -clientsecret- by the client id and secret of your application. Then add the code you got above at the end of this URL.

You should now be presented with a JSON response that contains the access and refresh token. Take note of both of these values for the PacketFence configuration. Example:

Login in the PacketFence administration interface, then go in the Configuration tab, then in Provisioners. Click Add provisioner then select sepm.

Now configure this new provisioner with the information you got above.

Now that you have created the provisioner, go in the Connection Profiles menu on the left and select the default portal. Click Add Provisioner and select the new SEPM provisioner that was created earlier.

In order to enable the boarding passthrough for the device enrollment, you will need to restart the iptables service of PacketFence.

You can do this using the command line by doing /usr/local/pf/bin/pfcmd service iptables restart or in the administration interface under Status / Services.

For the integration with PacketFence, the following subroles need to be installed in ADCS:

Before you start the configuration, a hotfix is necessary due to a Microsoft issue. After restarting the ADCS service, the server cannot enroll new certificates and display the following error message: "The RPC Server is unavailable". The hotfix is available here: https://support.microsoft.com/en-us/kb/2633200

Communication between the MSPKI and PacketFence will be using port 80.

For the deployment of ADCS you will need to configure Network Device Enrollment Service (NDES). This subrole will allow us to exchange certificates with the MSPKI server via Simple Certificate Exchange Protocol (SCEP).

Every configuration change has to be done by an account with administrative privileges.

Microsoft SCEP (MSCEP) includes by default a challenge password, which is unique and dynamically generated for each device which wants to enroll. In a BYOD deployment, this can be a barrier as a user cannot register a device by himself without the intervention of an administrator. Since we use NDES with PacketFence, our security to obtain a certificate would be the credentials necessary to access the enrollment system.

To disable the challenge password you need to modify the following key in the Windows registry.

Click Start and enter regedit.

Navigate to Computer->HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Cryptography->MSCEP->EnforcePassword.

Change the value of EnforcePassword to 0 (default is 1).

Best practices recommends to extend the URL length to avoid issue with longer request.

To do so, enter the following command in the CLI on the NDES server:

The goal is to deliver certificates for user Authentication, this means you will need to setup a specific template.

First, the certificate template needs at least the following Enhanced Key Usage and Key Usage:

The next step is to duplicate a template where those Key Usage, and Enhanced Key Usage are already configured. We advise to duplicate the template User and change the necessary settings.

To duplicate the template, you need to navigate through Server Manager->Roles->Active Directory Certificates Services->Certificate templates. Now right click the template User and select Duplicate this template.

Once duplicated, right click your new template, go to Properties. Navigate to the tab Subject Name. Make sure to select Supplied in the request over Built from information in Active Directory, otherwise the requested CN will be overwritten by NDES.

To allow NDES to use this template you need to navigate to Server Manager->Roles->Active Directory Certificates Services, expand <ServerDNSName>, right click Certificate template and choose New template to issue, in the list select your newly created template.

Now that you choose the template to deliver you need to configure it in the registry.

To access the registry editor, press Start and type regedit.

While in the registry navigate to Computer->HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Cryptography->MSCEP.

You should have a list of three keys entries:

The default value should be IPSECIntermediateOffline. Replace each value with your newly created template name.

At this point, you need to reboot the NDES server to apply changes to the registry.

The use of SCEP with PacketFence also require a change in the IIS configuration.

Navigate to Server Manager->Web(IIS), expand Default web site then select CertSrv->mscep. Select Authentication, and double click Anonymous Authentication. Make sure that Application pool identity is selected.

For the configuration of OCSP, the following changes are necessary.

First we need to allow the use of the template OCSPResponseSigning by the server, to do so navigate to Server Manager->Roles->Active Directory Certificates Services, expand <ServerDNSName>, right click Certificate template and choose New template to issue, in the list select OCSPResponseSigning.

After the installation of OCSP we need to create a Revocation Configuration.

To create the Revocation Configuration navigate to Server Manager->Roles->Active Directory Certificate Services and expand OnlineResponder: <ServerDNSName>. Right click Revocation Configuration, select Add Revocation Configuration, click Next, choose a name for your configuration and click Next.

Choose Select a certificate for an existing enterprise CA, click Next. Click Browse and find your enterprise CA in the list, select it, click OK and then Next. Choose Automatically select a signing certificate, make sure Auto-Enroll for an OCSP signing certificate is selected, then choose the default template of OCSP which is OCSPResponseSigning in the dropdown list next to Certificate Template:. You need to add providers only if you wish to use a CRL in addition to OCSP.

Once created, right click the revocation configuration and select Edit properties, go to the Signing tab, then select Enable NONCE extension support then click OK.

Make sure that your OCSP server appears in the CA settings. Right click your CA, choose Properties. Navigate to the tab Extension, in the dropdown list Select extension choose Authority Information Access (AIA). Make sure that you have the following in the list of locations: http://<ServerDNSName>/OCSP.

If you do not have it, add it via the button Add.... In this menu type the http:// then insert <ServerDNSName> and type /OCSP, validate by clicking OK. Also verify that Include in the online certificate status protocol(OCSP) extension is selected.

By default OCSP has a two days delay to refresh it’s CRL information. Which means if you revoke a certificate on MSPKI, it will take two days before PacketFence detects the certificate is revoked. If this delay is too long for your needs, you can change it on the NDES server. To do so, navigate to Server Manager->Roles->Active Directory Certificate Service and right click Enterprise PKI, in the menu select Options.... The delay can be changed by modifying the value of Set CRL status to Expiring when expiring in: to your convenience.

Using the Microsoft PKI involves that all your certificates will be delivered by the root CA of the MSPKI.

As for RADIUS authentication you will need to generate a certificate for PacketFence.

To generate the RADIUS certificate, the template WebServer will be used.

The next step is to create the request (CSR), a private key from the PacketFence server and submit the CSR to the NDES server. Connect to PacketFence via SSH and type the following in the CLI to generate the CSR and sign it with the private key:

You will be prompted for some information, here is an example of a valid configuration.

No fields are mandatory other than the CN.

Once you have your CSR you will submit it to the NDES server.

To submit the request you need to copy the content of the request (CSR) on the MSPKI enrollment website. The URL to input the request will be: http://<ServerDNSName>/CertSrv/.

When reaching the website, click Request a certificate, select advanced certificate request. Paste the content of your CSR file and select the template Web Server. Click Submit. On this page select Base 64 encoded and click Download certificate.

This will give you the certificate (public key) for PacketFence.

Now download the CA file by reaching the following URL in your browser: http://<ServerDNSName>/CertSrv/.

Click Download a CA certificate, certificate chain or CRL, select your CA certificate in the list, select Base 64 as the encoding method and finally click Download CA certificate.

Copy those files to PacketFence.

It is recommended to create a separate directory to separate EAP-TLS certificates from server certificates:

RADIUS EAP-TLS authentication requires three files, the CA certificate, the server certificate and the server private key.

Copy those files in your newly created folder:

Ensure that the files are readable by the user pf:

In order to use the certificates generated by the MSPKI, edit the radius EAP configuration file.

Edit /usr/local/pf/conf/radiusd/eap.conf and replace the following lines with references to your new certificates in the tls configuration block:

E.g.

Certificate revocation checks have to be configured in the OCSP sub-block of tls.

For example:

Restart radiusd to regenerate the new configuration files and enable EAP-TLS using your CA signed certificates:

Using the PKI requires configuring the PKI providers section in the PacketFence GUI under Configuration->Users->PKI Providers. The provider configuration defines how PacketFence connects to the MSPKI and what information will be sent.

Add a new PKI provider and select SCEP.

Fill out the form for a PKI provider according to your Certificate of Authority configuration.

For the URL it will be http://<ServerDNSName>/CertSrv/mscep/.

You do not need any Username/Password combination for this configuration.

The "Server cert path" and "CA cert path" both need to be absolute (e.g. /usr/local/pf/conf/ssl/tls_certs/MyCA.pem is an absolute path).

The "Common name attribute" field defines how the certificate will be generated and what type of "ownership" will associate the certificate to the connection. If you select MAC address, a certificate will be generated using the MAC address as the identifier. If you select Username, a certificate will be generated using his login name on the authentication backend.

Provisioners allow devices to automatically configure themselves to connect to the proper SSID (if applicable), use the proper authentication method (e.g. EAP-TLS) and trust the CA certificate and any certificate signed by it.

Provisioners are configured in the PacketFence administration GUI under Configuration->Users->Provisioners.

Add a new provisioner for each of the classes of devices to be supported amongst Android, Apple Devices and Windows. Fill out the form, choosing a different Provisioning Id per provisioner.

The following is an example on how to configure an EAP-TLS connection for Windows/Android/Mac OS X/iOS

Mac OS X/iOS require the provisioning profile to be signed if you want to remove the untrusted warning when installing the profile. You need to sign it with a Certification Authority already trusted by the device such as e.g. VeriSign. Configuring this has to be done in the Signing tab in the "Apple devices".

Fill out the fields with the contents of the Base64 encoded certificates. To extract this information from a pem formatted certificate, copy the file content.

Certificate file example:

Copy everything from the BEGIN to END lines. Repeat this operation for the certificate key and intermediate certificate.

Provisioners have to be enabled on the Connection Profiles configuration in the PacketFence GUI.

Under Configuration->Main->Connection Profiles, select each of the provisioners created above which should be active for the profile. If no connection profile is defined, configure the "default" profile to use the provisioners created.

Android devices require passthroughs to be created to allow them to fetch the configuration application from the Google Play Store.

Add the following to the "Fencing" section of the Configuration tab in the PacketFence GUI.

This is a way to do the procedure of enrollment manually, mainly for debugging purposes.

First you need to generate a request and its private key via the openssl command. Type following commands in PacketFence CLI:

This will create 2 files in your current directory, local.csr and local.key.

Now you need to obtain the CA and some specific certificates from the MSPKI.

Now you need to use the "CEP encryption" certificate and the "Enrollment agent". Both were obtained when doing the sscep getca. You should have at least three certificates with the same name and a different number at the end. e.g. MyCA.crt-0 (Enrollment agent certificate), MyCA.crt-1 (CEP encryption certificate) and MyCA.crt-2 (CA certificate).

To display the content of each certificate use following commands:

In the output search for X509v3 extensions:. When using the sscep enroll command you will need the "Enrollment agent" certificate as an argument for -c and the "CEP Encryption" certificate as an argument for -e. -d is use for the debug output. -l is the local file where your certificate will be save.

To verify your certificate against the OCSP you can use the following openssl command:

If you need to add domains to passthroughs, we advise you to capture the traffic coming from the device which cannot access the Google Play Store. To do this you can use tcpdump for instance, collect the IP address of the device then run the following in PacketFence CLI:

This will output any DNS requests from the device to PacketFence. You will need to find google related domain and add them to your passthroughs list.

PacketFence PKI can be installed on a standalone machine or on the PacketFence server itself. Communication between the PKI and PacketFence proper will take place over a REST API over port 9393.

to:

Allow TCP traffic over ports 9393 and 9292 through iptables:

Uncomment the following lines.

Restart the iptables service:

Debian

In order to use the repository, create a file named /etc/apt/sources.list.d/packetfence.list:

Once the repository is defined, you can install packetfence-pki using:

CentOS/RHEL

Installing on RHEL or CentOS requires the packetfence and packetfence-extra repositories. Install them first and then install the packetfence-pki package itself.

After you login there are few steps to follow to have the PKI working for an EAP-TLS configuration with PacketFence. You will need to configure the following items:

Follow the four step wizard to create your certification authority, your client and server profile and your REST API configuration.

Fill out the following fields that will be used to generate the certification authority.

This profile will be used to generate the RADIUS server certificate and key. The server certificate is used by the RADIUS server to authenticate its end of the connection to the client.

Fill out the following fields that will be used to generate the certificate profile to use for generating server certificates.

The following fields should be configured according to your preferences and will fill out the email sent when exporting the certificate:

This profile will be used to generate the RADIUS client certificate and key. The client certificate is used by the 802.1X supplicant to authenticate its end of the connection to the server.

The fields shown above are required to allow use of the REST API over which PacketFence and the PKI exchange authentication information. A username and password are mandatory.

To change PKI default password, you will need to change admin user password. Password can be changed in Configuration → Users after editing a user.

Additional users for specific tasks may be created under Configuration → Users .

All fields are mandatory. Users can be associated with the REST API configuration.

You can manage certificates profiles under Certificate → Profiles.

It is recommended to create a separate directory to separate EAP-TLS certificates from server certificates:

RADIUS EAP-TLS authentication requires three files: the CA certificate, the server certificate and the private key.

The CA certificate generated by the PacketFence PKI will be placed in /usr/local/packetfence-pki/ca/. Copy the CA certificate (and not it’s private key) to the directory created above and make sure it is readable by the "pf" user.

In the case where the PKI was installed on the same server as PacketFence, this will mean for example:

Since the server certificate is stored in the PKI database, you will have to sign and export it to the PacketFence server.

On the PKI web interface, under Certificates click on the "sign" icon for the certificate for your RADIUS server. This will automatically sign the certificate with your CA. Use the Send certificate or Download certificate to export it. The certificate will be exported in p12 format which combines both the certificate and its key. The password to decrypt the file will be send by email.

Copy the p12 formatted file to the tls_certs directory on the PacketFence server:

Then, convert the p12 file to the pem format using the openssl tool:

Ensure that the files are readable by pf:

Using the PKI generated certificates requires editing the RADIUS EAP configuration file.

Edit the /usr/local/pf/conf/radiusd/eap.conf file and replace the following lines with references to your new certificates in the tls-common configuration block:

E.g.

Certificate revocation checks also have to be configured using OCSP in the same block.

For example:

Regenerate the new configuration files and restart radiusd to enable EAP-TLS using your CA signed certificates:

Using the PKI requires configuring the PKI providers section in the PacketFence’s web admin interface under Configuration → Advanced Access Configuration → Users. The provider configuration defines how PacketFence connects to the PKI REST API and which profile will be used.

Add a new PKI provider and select PacketFence PKI.

Fill out the form for a PKI provider according to the PKI configuration profile you created earlier. Pay attention to the username and password which have to match an authorized user in the PKI configuration.

The "CA cert path" and "Server cert path" fields both need to be absolute (e.g. /usr/local/pf/conf/ssl/tls_certs/MyCA.pem is an absolute path).