Check Point Gaia RADIUS authentication

The Check Point Gaia Operating System supports local authentication and external authentication using RADIUS or TACACS+. Check Point uses Role Based administration (RBA), which can assign a role to a user (local or external) with set permissions, including read-only. When using external authentication, the RADIUS server can be configured to set the role depending on the user’s AD group membership.

This post covers Check Point Gaia R81.10 external authentication against a Cisco ISE RADIUS server.

ISE certificate authentication

When deploying Cisco ISE for Network Access Control (NAC) using 802.1X, the most common authentication protocols used are PEAP/MSCHAPv2 or EAP-TLS, and to a lesser extent EAP-FAST and TEAP. PEAP/MSCHAPv2 is vulnerable as user credentials can be stolen or obtained by Man in The Middle (MiTM) attacks. EAP-TLS is considered more secure as the certificates cannot be duplicated or stolen off the device, eliminating some risks. However, EAP-TLS is generally considered more complex to initially setup and maintain, in comparison to PEAP/MSCHAPv2.

EAP-FAST is a Cisco proprietary protocol and requires the use of Cisco AnyConnect Network Access Module and licensing. TEAP (Tunnel Extensible Authentication Protocol) is relatively new and only supported since Windows 10 build 2004 and Cisco ISE version 2.7. Both are out of scope for guide.

WSA pxGrid integration with ISE

The Cisco WSA uses the pxGrid (Platform Exchange Grid) to subscribes to published information on Cisco ISE, to learn IP, Username, Security Group Tags (SGT) information of connected users authenticated by ISE. This information can then be used by WSA policies to transparently authenticate users. Using WSA integration with ISE, allows the WSA to know the authenticated users without having to prompt for authentication with a HTTP 407 proxy authentication error code, therefore not forcing the user to provide authentication credentials. WSA/ISE pxgrid integration authetication exchange takes less time and is less overhead on the WSA compared to other methods.

Certificates are used for mutual authentication between the WSA and ISE, three unique certificates are used, including:

• ISE Admin Certificate
  
• ISE pxGrid certificate
  
• WSA client certificate
  

The certificates can be signed by a public certificate (i.e., Verisign, Symantec etc), an Internal CA (i.e., Windows Server Certificate Authority) or using Cisco ISE Internal CA. Which ever CA is used WSA and ISE must trust the certificate(s) by having the root certificate in the certificate store.

This post covers pxGrid integration between ISE/WSA and assumes wired or wireless 802.1x is setup correctly and working.

ISE Phone Authentication

Most Cisco IP Phones support 802.1X authentication, they typically use pre-provisioned Manufacturer Installed Certificates (MIC) or customer deploy Locally Significant Certificates (LSC) for authentication. The MIC is pre-loaded on to each phone during manufacturing, whereas the LSC must be deployed by the customer from their Internal CA. Using a MIC only requires mutual trust between ISE and the Phone and is easier to implement.

However, the simplest method of authorising an IP Phone onto an 802.1X enabled network is using MAC Authentication Bypass (MAB), which merely relies on the Phone MAC address being permitted on the RADIUS server. MAB is inherently less secure that 802.1x, but simpler to deploy.

This post will cover deploying MAB and 802.1x using a MIC.

ISE Configuration

This section covers the steps to configure Cisco ISE to authenticate and authorise IP Phones.

Certificates

ISE already has the correct Root Certificate used by the Phones to sign the MIC installed in the Trusted Certificate store.

• Navigate to Administration > Certificates > Certificates Management > Trusted Certificates
  
• Ensure the Cisco Manufacturing CA SHA2 certificate is enabled.

Some older Cisco IP Phones may use the Cisco Root CA 2048 certificate, which is disabled as default. Just enable if required.

ASA AnyConnect VPN IP pool assignment using RADIUS

In most scenarios the VPN POOL(s) to assign IP addresses for AnyConnect Remote Access VPNs are statically configured under the tunnel-group. In some situations, it may be desired to dynamically assign the VPN Pool from a RADIUS server, perhaps to use a different IP address pool for certain types of users.

This post describes the steps to use Cisco Identity Services Engine (ISE) and Microsoft Windows Network Policy Server (NPS) RADIUS servers to dynamically assign the VPN Pool during authorisation.

This guide assumes the basic configuration of ASA Remote Access VPN and authentication via ISE or NPS is already setup.

FDM Identity Policy and AD Realm

FTD Identity Policies are used to detect the user who is associated with a connection. In the firewall logs the connections will be logged against the IP address and the Username, which can help identify behaviour, traffic, and events, this is also useful when attempting to identify the source of policy breaches or attacks. The Identity Policies relies on the Username to IP address bindings learnt via pxGrid from ISE or ISE-PIC. These bindings are used in conjunction with the AD Group/User information imported the configured AD Realm.

The configuration steps in this post relates to Cisco Secure Firewall (FTD) version 7.0 using local FDM management, not FMC. This post is a direct follow-up to the FDM pxGrid integration with ISE ensure you complete the steps in this post before proceeding.

FDM pxGrid integration with ISE

This post covers configuring Cisco Secure Firewall (FTD), using Firepower Device Manager (FDM) with Cisco Identity Services Engine (ISE) to learn the Username to IP address and IP to TrustSec SGT bindings of users authenticated to the network using ISE as the RADIUS server. The bindings are communicated from ISE to the FTD securely using Cisco pxGrid. These bindings can be used in the Access Control rules to permit/deny traffic instead of IP addresses.

This post assumes that the FTD and ISE are configured and working correctly, refer to the following post for more information on ISE, TrustSec.

Cisco ISE integration with Cisco FMC
TrustSec enforcement

ISE TrustSec using RESTAPI

By default, Cisco ISE uses a PAC file transmitted over RADIUS to exchange TrustSec environment data between ISE and the Network Access Devices (NADs). From ISE version 2.7 and above, ISE now supports exchanging this information using REST API over HTTPS. Using HTTPS to transfer TrustSec environment data is faster, more reliable, and more secure than using RADIUS.

Requirements

• The communication between ISE and the NAD uses tcp/9603 to transfer TrustSec environment over HTTPS using REST.
• Cisco NADs (switches and routers) must be running software version 16.12.2, 17.1.1 or higher.
• The credentials on each NAD used to authenticate to ISE must be unique.

This post will assume that the basic ISE and TrustSec configuration has been applied and will cover enabling exchanging TrustSec environment data using RESTAPI over HTTPS.

The following software versions were used:

• Cisco Identity Services Engine (ISE) 3.0
• Cisco CSR1000v 17.3.1

802.1x Critical Authentication

In the unlikely event that all Cisco ISE Policy Service Nodes (PSN) become unavailable to process RADIUS requests, the Inaccessible Authentication Bypass (IAB) feature, also referred to a critical authentication on Cisco Catalyst switches can be used to fail-open. The switch grants temporary network access to the host and puts the port in critical-authentication state, which allows devices connecting to the network whilst the RADIUS servers are down to gain network access. Without IAB feature network access would otherwise be denied due to no AAA servers available to process the authentication request. This only applies to 802.1x Closed Mode, obviously if in 802.1x Open/Monitor mode full access is granted regardless of whether authentication passes or fails.

The purpose of this post is to describe the steps to configure a Cisco Catalyst switch for IAB and demonstrate how to test failover, it is assumed that ISE is setup and configured and devices are already authenticating successfully. Refer to the previous posts, for information on how to configure ISE for 802.1x authentication.

Initial Cisco ISE Configuration
Configuring Wired 802.1x authentication with ISE
Configured ISE Wired 802.1x Posture

ISE integration with Stealthwatch

This post describes the steps to configure Cisco Stealthwatch Management Centre (SMC) and Cisco Identity Services Engine (ISE) using pxGrid. Once integrated with ISE, the SMC will learn the user session information (IP address/username bindings), Static TrustSec mappings and Adaptive Network Control (ANC) mitigation actions for quarantining endpoints.

Versions used in this scenario: –

• Cisco Identity Services Engine 2.6 patch 3
• Cisco Stealthwatch Management Centre 7.1.2

This post will not describe how to initially setup either the SMC or ISE, the following posts describe how to setup ISE: –

ISE Initial Configuration
ISE Wired Authentication
ISE Adaptive Network Control (ANC)