11-06-2023 08:09 AM
We have RHEL8 Workstations in our environment that are failing dot1x authentication using EAP-TLS. We are attempting to perform cert based dot1x authentication but getting no help from Red Hat at all.
Linux machine is configured with EAP-TLS with no password and no identity in identity field.
In the Cisco ISE > RADIUS live logs the only attempt that I'm seeing is authentication failure (5436 RADIUS packet already in the process) and then it moves to MAB authentication.
Has anyone came across any problem with RHEL8 machines not playing nice with Cisco ISE? Is there any documentation that could be helpful to get dot1x working on RHEL8 WS?
Solved! Go to Solution.
11-07-2023 02:46 PM
I have successfully configured EAP-TLS on RHEL 7 & 8 in the past (including configuration using Ansible). You need to ensure the client has the Root CA certificate chain (ideally signed by the same CA as the ISE EAP certificate), the private key for the identity certificate (the private key must be secured with a password), and the identity certificate. The supplicant would then be configured to use those three objects similar to the following example screenshot.
The 'Identity' field is optional, but can be useful as a matching condition in the ISE Policy to differentiate it from other use cases.
An example AuthZ Policy using the Identity value:
11-06-2023 12:15 PM
Hi @SDhaliwal
It helps to know if this is wired or wireless 802.1X ?
I assume you're struggling with wired, which has many more moving parts than wireless. If Wired then send us the output of
show run | sec radius
show run | inc aaa
Is this your first 802.1X deployment, or is the RADIUS platform tried and tested with other operating systems like Windows/MAC ?
I have not setup the native supplicant in any Linux distribution, but I would suppose that under the hood they use the wpa_supplicant software stack. And that is very reliable.
11-06-2023 02:41 PM
Hello @Arne Bier
This is not my first 802.1x deployment and yes it is wired that I'm struggling with. We don't have MAC in our environment and we have both Wired and Wireless cert based 802.1x authentication for windows supplicant working successfully.
On Linux WS, we were attempting to use Cisco Secure client NAM module but it is not supported as mentioned in cisco documentations. I'm not sure what do you meain by wpa_supplicant software stack under the hood but I will confirm it with our Linux Admins.
Thank you.
11-06-2023 03:52 PM
I can't get RHEL Desktop ($$$) but it should be related to Fedora/CentOS - have you tried the native supplicant through the GUI?
11-07-2023 08:19 AM
Yes, I have and Linux's native supplicant is the only option I have in this scenario. Our Linux Admin changed the configs not to use password with the cert and no identity in identity field.
I'm completely at lost on how to go about this situation.
11-07-2023 02:35 PM
Interesting. When I briefly had a play with this, the interface was expecting a password for the private key. I was unable to configure the supplicant without the password that protects the private key. That's not an 802.1X thing - it's a security mechanism in the Linux supplicant to protect the private key. It should be possible in your case too. BTW, if your private key is currently not password protected, then you can add a password to it with openssl - just search the web for the openssl command.
The identity is only the 'outer' identity that is used for the RADIUS User-Name. You should put some text string in there, even if the string is something like "anonymous".
I believe that the nmcli command is useful to monitor what's configured and they also provide some monitoring funcitonality. You must make some packet captures either on the switch interface (with Cisco switches use the "monitor capture" command) or vvia tcpdump on the Linux host itself. Have a look at the EAPOL traffic in Wireshark
11-07-2023 02:46 PM
I have successfully configured EAP-TLS on RHEL 7 & 8 in the past (including configuration using Ansible). You need to ensure the client has the Root CA certificate chain (ideally signed by the same CA as the ISE EAP certificate), the private key for the identity certificate (the private key must be secured with a password), and the identity certificate. The supplicant would then be configured to use those three objects similar to the following example screenshot.
The 'Identity' field is optional, but can be useful as a matching condition in the ISE Policy to differentiate it from other use cases.
An example AuthZ Policy using the Identity value:
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide