Skip to main content

We are implementing 802.1x using Cisco ISE on the back end. Currently, the project is in a testing stage, so we are using very basic configurations on the client side. The protocols used are PEAP and MSCHAPv2.

 

I’ve created a configuration profile that enables PEAP in the login window context and deploys the certificate.

 

When this configuration profile is deployed, the 802.1x connection can be made manually in the Network system preference pane and it works as intended – prompting the user for credentials and placing the connection in the appropriate VLAN.

 

Our Macs are all joined to AD. We would like our users to authenticate to the 802.1x network at the login window. All the guides I found for this seem to imply that this is a basic configuration that should work with the settings I’ve deployed.

 

I’ve tried using ProfileCreator and Jamf to create the configuration profile with both producing the same results. The only thing I’ve really been able to try is adding the certificate payload the configuration profile. I’ve also tried checking off “Use Directory Authentication” to no effect.

These are the only settings being deployed in the configuration profile, besides the certificate.

 

 

To do this right you'll need a bit more than just a profile.  JAMF Integration with ISE as MDM - Cisco Communityhttps://community.cisco.com › kxiwq67737 › JA... this explains it right from Cisco.  The integration into Jamf solves your issue with making sure the device is compliant, this also will ensure that its one stop shop for the profiles. - https://docs.jamf.com/10.41.0/jamf-pro/documentation/Network_Integration.html?hl=cisco

To do this right you'll need a bit more than just a profile.  JAMF Integration with ISE as MDM - Cisco Communityhttps://community.cisco.com › kxiwq67737 › JA... this explains it right from Cisco.  The integration into Jamf solves your issue with making sure the device is compliant, this also will ensure that its one stop shop for the profiles. - https://docs.jamf.com/10.41.0/jamf-pro/documentation/Network_Integration.html?hl=cisco


thank you for this, we haven't reached this stage yet. Actually, I don't think we'll be using machine compliance. We're going to implement user-based roles (a user's group membership - in this case faculty, staff, IT) will determine which VLAN the machine is connected to.

I'm going to share this with our network admin to see about further MDM integration in the future.

thank you for this, we haven't reached this stage yet. Actually, I don't think we'll be using machine compliance. We're going to implement user-based roles (a user's group membership - in this case faculty, staff, IT) will determine which VLAN the machine is connected to.

I'm going to share this with our network admin to see about further MDM integration in the future.


you got it.....the profile route can be handled by ADCS in the PKI certificates portion of JAMF - this would define a trusted certificate that comes from the networking folks and can be defined with $user variable in the template for your purposes of 802.1x networking.  in theory with no certs, an AD bound machine should get the cert from the CS yet it would be generic unless you have a system that divides out traffic that based on the username, this will not work on 802.1x wireless, you would need a machine+user cert. to accomplish that.
https://community.jamf.com/t5/jamf-pro/802-1x-authentication-with-certificates/td-p/262303

I've resolved this issue. The prerequisite for all of this to work is that the machine must be joined to AD.


Firstly, "Any Ethernet" does not work. You need to specify your interface. In my case, I used First Active Ethernet.

Secondly, Use Directory Authentication must be checked to have a consistent connection to the quarantine VLAN.

Lastly, the certificate common name must be included in the Trust tab. I didn't need to deploy the cert as well, but this is probably because it's signed by an external CA (Digicert). You may have to test this if using an internal CA.

 

Some things to note:

  • If the supplicant is deployed at the login window, the machine stays connected on the quarantine VLAN and has to be rebooted before it can be used.
  • If the supplicant is deployed when a user is logged in, the machine stays connected on the quarantine VLAN and the supplicant will work after the user logs off and logs back in again.
  • If a local user logs into the machine, it remains connected to the quarantine VLAN.
  • If the cable is somehow disconnected and then reconnected while a user is logged in, the machine briefly connects to the quarantine VLAN before changing to the appropriate VLAN for the user.
Terms & ConditionsCookie settings