When using 802.1x authentication (wired or wireless) on a Windows computer joined to an Active Directory Domain, Windows Group Policies Objects (GPO) can deploy the Native Supplicant configuration. The native supplicant can use different authentication methods, the common method being PEAP/MSCHAPv2 which uses Username and Password authentication. Slightly less common due to the perceived complexity is EAP-TLS which uses computer and/or user certificates.
This blog post describes the configuration of PEAP/MSCHAPv2, this requires only valid username and password for successful authentication.
Group Policy Configuration
Create a new GPO (or if required modify an existing policy) link the policy to an OU that the computers will inherit the policy configuration
Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services
Locate the Wired AutoConfig service and double click to edit
Select Define this policy setting
Ensure Automatic is selected as startup mode
Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies
Right click and select Create A New Wired Network Policy for Windows Vista and Later Releases
Name the policy appropriately, e.g. Wired Authentication Policy
Click the Security tab
Select the desired Authentication Mode it would be recommended to use User or Computer authentication, in order for both the Computer and User to be authenticated in order to grant network access in order to process Computer and User Group Policies.
Select the authentication method, e.g. Microsoft: Protected EAP (PEAP)
Ensure Validate server certificate is selected
Select the Trusted Root Certification Authorities certificate is selected (this certificate must be present in the Trusted Root certificate store of the RADIUS server and the client computer)
Ensure the authentication method is Secured password (EAP-MSCHAPv2)
Leave other settings as default
Click Ok to complete the configuration
Apply the GPO to a test computer
Open the Services MMC and check the status of the Wired AutoConfig service, this needs to be running
Open the Local Area Connection Properties, if the service is running the Authentication tab will be present
Notice that configuration is not possible as this settings have been applied from the GPO previous configured.
If the Wired AutoConfig service is not started, the Authentication tab will not be present.
Confirm the Trusted Root Certificate is present in the Local Computer certificate store. This certificate should automatically be present if joined to the Active Directory Domain.
Assuming the RADIUS server is configured correctly and the same Trusted Root Certificate is trusted by the Computer and the RADIUS server. Refer to this previous blogpost that describes how to configure Cisco ISE for Wired 802.1x authentication.
In a previous post Cisco TrustSec was discussed and enforcement implemented on Cisco CSR1000v router using Cisco ISE to dynamically classify the traffic. In this post we will implement enforcement on a Cisco ASA Firewall. Unlike a Cisco switch or router when configuring TrustSec enforcement, when using the ASA as the enforcement point the TrustSec matrix on ISE is not utilised. Instead the ASA downloads the CTS environment data (SGTs), these are defined in a normal ASA access list as the source and destination.
The advantage of using an ASA Firewall for TrustSec enforcement over a Cisco switch or router is that the ASA firewall rules are stateful, unlike the ACLs on a switch or router which are not stateful.
Scenario In this blog post we will setup a simple lab, using ISE and ASAv. ISE will be configured with TrustSec SGTs’, SXP and a basic Authorization Policy. Secure communication between the ASA and ISE will be established by the use of a PAC file (Protected Access Credential). The ASA will use this secure channel to authenticate and establish a radius connection to ISE to download the CTS environment data, which contains the SGT table. An SXP connection between ISE and ASA will be established to transfer the static SXP bindings (the servers in the DC) and the dynamically assigned bindings for the authenticated users.
Basic configuration of ISE is not covered in this post. The posts below describe in greater detail configuration of ISE and TrustSec:-
Using Cisco ISE you can apply variables such Downloadable ACL (DACL) or VLAN from an External Identity Source (e.g Active Directory) and apply these values during authorization. For example instead of defining multiple authorization rules such as – If AD:ExternalGroup membership equals “GroupName” then assign static attributes”DACL_1″ and “VLAN_1”.
The same can be achieved by extracting the attributes from an External Identity Source such as AD, resulting in 1 authorization rule instead of multiple.
MACsec provides secure communication on wired networks; it encrypts each packet on the wire so that communication cannot be monitored. There are 2 deployment types:- User facing/downlink MACsec or switch-to-switch MACsec.
When using downlink MACsec a supplicant that supports 802.1x with MACsec is required, Cisco AnyConnect version 3.0+ supports this functionality. When AnyConnect is configured with MACsec it authenticates the user/computer using 802.1x and then encrypts all traffic using MACsec that is sent to the directly attached Access Layer switch. Once the packet has been received by the Access Layer switch the packet is decrypted, this allows the possibility to apply QoS polices or monitor with Netflow. The switch could then route packet in clear text or if switch-to-switch MACsec is enabled re-encrypt the traffic.
Switch-to-Switch MACsec secures the packets on a hop by hop basis, decrypting and encrypting on each network device (meaning all traffic inside the switches are in clear text). The MACsec sessions are completely independent as they are routed through the network.
Cisco ISE and Firepower can exchange attributes such as TrustSec SGT (Security Group Tag), endpoint profile information and IP address via pxGrid. These attributes can then be used in Firepower Access Control Policies to permit/deny access as required. In addition, this integration can also be used to quarantine users/hosts in the event the user performs a malicious activity. When Firepower detects the malicious activity this will match a correlation rule on the FMC, which instructs ISE to perform a remediation action such as sending a CoA (Change of Authorization) and quarantining the user by apply a DACL and/or applying a new SGT.
This post will describe how to configure the pxGrid integration between the FMC and ISE, it is assume that you already have a working ISE environment with users/computers authenticating using dot1x and a working Firepower FMC/FTD environment.
Refer to these previous ISE posts on how to configure ISE, dot1x authentication and more information about configuring TrustSec.
The following software versions were used:-
Firepower Management Centre 188.8.131.52
Firepower Threat Defence Virtual 184.108.40.206
Identity Services Engine 2.4
Windows Server 2008 R2 (Domain Controller and PKI)