802.1X is a standard for network access control that provides an extra layer of security for wired and wireless networks. It ensures that only authorized devices and users can connect to the network. The “X” in 802.1X stands for “port-based authentication.”
Implementing Certificate-based authentication requires some additional setup and infrastructure, such as a certificate authority to issue and manage certificates. It also requires devices and clients capable of supporting the 802.1X protocol.
Today we are trying to deploy the 802.1X configuration to our macOS clients using Microsoft Intune. The prerequisite for this should be an already configured SCEP setup and an SCEP configuration profile in Intune.
Our basic configuration profile for the network authentication is quite manageable.
In this example, we instruct the client to use EAP Type TLS (Code 13). In order for the client to ensure that the correct Radius server is at the other end, the client checks if the Radius server has a certificate from our ROOT Certification Authority. The Server Trust area should contain the explicit server name, a wildcard can also be used for testing.
After deployment you will find a new identity setting in you macOS Keychain and also the new SCEP Certificate.
With this we have sent the client the basic requirements for 802.1X and the user could now identify himself with the network, but when connecting the user gets the following message:
Normal users fail already at this input screen, because they don’t know which certificate is meant, and they don’t know that they want to set up a device based authentication and the Radius server expects the AD object name as account name. Even experienced IT admins often forget the following dollar sign at an AD computer object, this is used to distinguish computers from user objects.
In addition, this type of configuration has a decisive disadvantage. If you store 802.1X credentials in the user context, they are stored in the login keychain. This also means that the network connection is only established when the user is logged in. This is a showstopper for all those who need a network connection in the loginwindow like e.g. AD/Directory login. In addition, we wanted to create an EAP SystemMode connection, but when the user initiates the connection, other users cannot connect to the network.
How can we prevent the users from this issue?
The first thing I would say is that Microsoft have to be a look into Configuration Profile Reference from Apple. On page 111 you can find all information about deploying EAPClientConfiguration. From my side i think the Key “UserName” is not included in the Intune EAP Client Configuration Profile.
“Optional. Unless you know the exact user name, this property
wonʼt appear in an imported configuration. Users can enter
this information when they authenticate.“
If the key is present in the profile, the system parses a generic password item and links it to our existing identity (see above) and we can establish a connection without user interaction.
How can i solve my issue right now?
I have found a solution that creates the generic password item manually and you can use the script as an approach to solve your problem.
Please note that this is only a workaround and has to be executed again e.g. on a profile re-deployment.
How can i debug EAP TLS on the client?
Open the terminal app and run this command:
log stream –predicate ‘subsystem contains “com.apple.eapol”‘ –info –debug
If you liked the article then I would be happy about a like on twitter.
Links and Resources: