Cisco & FreeRadius – EAP-TLS Wired 802.1x

In this guide, we are going to look at the setup of a cisco network using 802.1x wired authentication.

This lab consists of the following:

• lab-dc01 - Windows Server 2019 AD-DS Server with AD-CS Roles
• lab-frad01 - Ubuntu 22.04 server for running FreeRadius
• dot1x-rtr - Cisco C1111-4P Router to connect clients to. This router has a built-in switch
• tst-lpt - Windows 11 Client to test the connection to the network, domain joined to the lab.local domain

FreeRadius EAP-TLS Setup

In order to have FreeRadius authenticate based on certificates, we need to setup the eap module with some certificate information.

On the fresh install of Ubuntu 22.04, you can install FreeRadius directly using apt:

sudo apt install freeradius

Once it is installed, we need to generate some certificates which will be classed as the server certificate. That is, the certificate that is presented to the client when connecting.

Create a csr request file using the following:

cat << 'EOF' > req.conf
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = GB
ST = State
L = Locality
O = Test LAB
OU = IT
CN = lab-frad01.lab.local
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = lab-frad01.lab.local
EOF

Replace the instances of lab-frad01.lab.local and the other location and org information to match your requirements.

Next we need to create a certificate signing request from that request file:

openssl req -new -out lab-frad01.lab.local.csr -newkey rsa:2048 -nodes -sha256 -keyout lab-frad01.lab.local.key -config req.conf

This should generate you two files, lab-frad01.lab.local.csr and lab-frad01.lab.local.key

Cat the output of lab-frad01.lab.local.csr, it should resemble base64:

nick@lab-frad01:~$ cat lab-frad01.lab.local.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIDCDCCAfACAQAwbzELMAkGA1UEBhMCR0IxDjAMBgNVBAgMBVN0YXRlMREwDwYD
...
pr27+OsuuFMQLBfZ
-----END CERTIFICATE REQUEST-----

We need to take this output and use it to generate the certificate on the AD-CS Server.

In my case, I have installed the web enrolment part of the AD Certificate Services role, so I can go to http://lab-dc01.lab.local/certsrv:

Click on Request a certificate and then advanced certificate request at the bottom of the page.

You should see the following:

Copy and paste the contents of the lab-frad01.lab.local.csr file into the top box and select Web Server as the Certificate Template. If this is not visible, you may have to ensure its published into Active Directory on the CA Server.

Click on Submit and the certificate should get signed:

Change the selector to 'Base 64 encoded' and download the certificate. We will move this back onto lab-frac01 and call it lab-frad01.lab.local.cer.

Finally, we need to get the CA in base64 form too. Open the certificate that you just generated in Windows and to go the Certification Path tab:

Click on the Certificate Authority at the top and then click 'View Certificate'. On that window, go to the 'Details' tab and then click 'Copy to file'.

Click Next, select Base-64 encoded and save this locally. It should be copied to the freeradius server too, we will call this lab-root-ca.cer.

Thats all the certificates we need generated and copied across now. For completeness, you can delete the .csr file but its worth keeping the req.conf file for future reference as you will need to renew this certificate at some point.

We need to move these certificate files so that FreeRadius can use them in its configuration:

mv lab-frad01.lab.local.cer /etc/freeradius/3.0/certs/
mv lab-frad01.lab.local.key /etc/freeradius/3.0/certs/
mv lab-root-ca.cer /etc/freeradius/3.0/certs/

You will have to do that either as root or with superuser permissions as the freeradius folder is not accessible for standard users.

Now we need to edit the eap configuration file to specifically call out these files.

Edit the file /etc/freeradius/3.0/mods-available/eap using your favorite CLI text editor.

Firstly, we need to change default_eap_type from md5 to tls:

Then under tls-config tls-common, we need to set the following attributes:

• private_key_file = /etc/freeradius/3.0/certs/lab-frad01.lab.local.key
• certificate_file = /etc/freeradius/3.0/certs/lab-frad01.lab.local.cer
• ca_file = /etc/freeradius/3.0/certs/lab-root-ca.cer

private_key_password can be commented out with a # as we didn't specify a password for it.

You should now be able to restart the freeradius service:

sudo service freeradius restart

And it should restart without any issues. If you have problems starting the service, you can use freeradius -X to run it interactively and see what the problem is. It's normally very good at that!

Last thing we need to do with FreeRadius is to create a client for the switch:

Edit /etc/freeradius/3.0/clients.conf and add the follwing to the end of the file:

client dot1x-rtr {
   ipaddr = 192.168.0.180
   secret = cisco123
}

And restart freeradius again!

Thats all of the FreeRadius setup done.

Cisco Configuration

We need to setup the Cisco device with its dot1x configuration and point it at the FreeRadius server.

Enter the following commands in configuration mode:

Note: Enabling aaa is global across the device, if this isn't already enabled, you may see changes to how you can authenticate to your device.

! Enable AAA syntax and commands
aaa new-model

! Create radius server object for freeradius
radius server lab-frad01
 address ipv4 192.168.0.181 auth-port 1812 acct-port 1813
 timeout 2
 retransmit 1
 key cisco123

! Create group and reference radius server
aaa group server radius dot1x-auth
 server name lab-frad01

! Point 802.1x auth to the RADIUS Group
aaa authentication dot1x default group dot1x-auth
aaa accounting dot1x default start-stop group dot1x-auth
aaa authorization network default group dot1x-auth

! Enable 802.1x
dot1x system-auth-control

! I need to do this in my case because im using an SVI
ip radius source-interface Vlan1

There are loads of configuration parameters for the interfaces themselves, but this base configuration will get the port working with 802.1x:

interface GigabitEthernet0/1/0
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator

AD-CS Auto Enrolment

In order for a machine on our network to be able to authenticate with FreeRadius, it needs a certificate, as do our users. In order to have these automatically generated, we need to configure auto enrolment.

On your AD-CS server, navigate to the Certificate Templates and right-click to manage them:

Right-click on the Computer template and select Duplicate Template. Then under the General tab, change the name and display name to signify its use:

Also ensure both of the AD checkboxes are selected.

Under the Security tab, add the Domain Computers computer group:

Add the Read, Enroll and AutoEnroll permissions.

Click OK to close the window.

Back on the Certification Authority window, right-click on Certificate Templates and select New > Certificate Template to Issue

Select the Template we just created and click OK:

Right-click on the User template and select Duplicate Template. Then under the General tab, change the name and display name to signify its use:

Again, ticking the boxes for AD Publishing.

Under the Security tab, select the Domain Users group:

Add the Read, Enroll and AutoEnroll permissions.

Back on the Certification Authority window, right-click on Certificate Templates and select New > Certificate Template to Issue

Select the Template we just created and click OK:

In all of the above, you can change the groups if you would rather not have all Domain Computers and Users get certificates. For the user certificate, make sure the users have an email address.

You can change this behavior on the Subject Name tab of the Template:

Uncheck 'Include e-mail name in subject name' and 'E-mail name' below.

Finally, we need to create a GPO in order for these to be enrolled automatically.

Create a new Group Policy Object:

Give the Object a name and then edit it:

Under User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.

Right click on Certificate Services Client - Auto-Enrollment:

Configure the settings as per the below:

Under Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.

Right click on Certificate Services Client - Auto-Enrollment:

Configure the settings as per the below:

On a client machine, run a gpupdate /force and you should see the certificates appear for Local User and Local Computer:

Dot1x Group Policy Settings

The final part of the configuration is to setup the GPOs on the lab.local domain so that our test machine knows the settings it needs.

Open up Group Policy Management for the domain and create a new GPO:

Edit the policy and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services

Locate the service Wired AutoConfig and set the mode to 'Automatic'.

Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies

Give the policy a name:

Under the Security tab, set the method to 'Microsoft: Smart Card or other certificate':

Click on Properties next to the method:

Tick the CA Certificates that was used to sign the certificates:

Its also a good idea to set the server name too, so that we only allow authentication attempts to the lab-frad01 server. Ensure this matches the common name on the server certificate you created for FreeRadius.

There are multiple instances of lab-new-CA in the list. However, they are the same CA so we only need to select one of them.

For extra granularity, click the Advanced button on the 'When connecting' section:

Here we should tick the certificate issuers we want to use for passing to FreeRadius. Above I have selected the internal CA as expected.

Click OK and then OK again to save the GPO.

Testing and Verification

Thats all the configuration we need to setup Wired 802.1x.

Lets jump onto the laptop and connect it to a non-dot1x enabled port in order to complete a gpupdate /force. This should force the machine to download the policy from AD.

With the settings we have used in the GPO. When the machine is at the login screen, it will use the machine certificate, and then once a user has logged in, the users certificate should be used. We can see this on the switch using show commands too.

I can't easily show the laptop at the login screen, but we can see from the following show command what the device has authenticated as:

dot1x-rtr#show authentication sessions interface g0/1/0 details 
            Interface:  GigabitEthernet0/1/0
               IIF-ID:  0x05ACA06A
          MAC Address:  4ccc.6adb.e5ec
         IPv6 Address:  Unknown
         IPv4 Address:  Unknown
            User-Name:  host/TST-LPT.lab.local
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  single-host
     Oper control dir:  both
      Session timeout:  N/A
    Common Session ID:  D900A8C000000012BFDDACA9
      Acct Session ID:  0x0000000f
               Handle:  0xc5000008
       Current Policy:  POLICY_Gi0/1/0

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Security Policy:  Should Secure
      Security Status:  Link Unsecured

Server Policies:

Method status list:
       Method           State
        dot1x           Authc Success

Above, we can see the device has authenticated as host/TST-LPT.lab.local which is a good identifier its using the device certificate, which is expected.

Then, if we login as a user:

dot1x-rtr#show authentication sessions interface g0/1/0 details 
            Interface:  GigabitEthernet0/1/0
               IIF-ID:  0x05ACA06A
          MAC Address:  4ccc.6adb.e5ec
         IPv6 Address:  Unknown
         IPv4 Address:  Unknown
            User-Name:  [email protected]
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  single-host
     Oper control dir:  both
      Session timeout:  N/A
    Common Session ID:  D900A8C000000012BFDDACA9
      Acct Session ID:  0x00000012
               Handle:  0xc5000008
       Current Policy:  POLICY_Gi0/1/0

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Security Policy:  Should Secure
      Security Status:  Link Unsecured

Server Policies:

Method status list:
       Method           State
        dot1x           Authc Success

We can see this has changed to [email protected] which shows we are now using the user certificate.

Windows also shows us that we are connected and signed in:

One caveat here, if its the first time the user has logged in, the user certificate may not be generated as the device will switch from the computer cert and fail to authenticate to the network as the user cert doesn't exist:

In this case, its sometimes less painful to switch to device only certificates as we know these are present. Or have the first logon be on a non-dot1x network. Neither of which are elegant solutions.

But, there you go, thats the setup of 802.1x from start to finish. I did hit some interesting curveballs with some of the older lab switches I have. The exact same configuration on a 3750-X on its latest firmware refused to work. So watch out for that if you are testing this in a lab and using more dated equipment. The specific issue with the 3750-X was that it wasn't relaying a RADIUS Access-Request to FreeRadius, despite me being able to see the client was sending an EAP-Response... weird!