Skip to main content
Solved

802.1X EAP-TLS + Jamf + Clearpass - Need some conceptual info.

  • February 14, 2025
  • 5 replies
  • 808 views
R
Forum|alt.badge.img+5

I asked this same question on the Clearpass forum, in case there are more people there that are doing similar things, but I'm hoping for someone with the conceptual understanding to just give me a nudge in the right direction regarding this setup.

We have been using 802.1x with Machine certificates issued by AD, with ClearPass and Windows machines for a couple years now. I understand the process that the windows machine joins the domain, get's a certificate, and then our clearpass servers are domain joined and can authenticate the machine with Active Directory using some of our various AD servers. All of that works well, and makes sense to me.

Now we're extending it to macbooks and adding Jamf, so that we can also set up certificates on the macbooks (they will not be domain joined) via SCEP/NDES integrated with our windows CA, with the goal of them also doing 802.1x with EAP-TLS.

So far, we have the SCEP process working fine, and the macbooks obtain their certificates from our CA via SCEP.

We also created a configuration profile in Jamf for our wifi network that has 1 SCEP payload, 1 Network payload, and not knowing which certs we needed, we our certificate payloads are currently our root, our NDES server, one called Sub Cert that I think is our root again (at the suggestion of Jamf), And then I added our ClearPass server certificate for RADIUS/EAP, and also just in case, the ClearPass RADSEC certificate. I'm not sure if all that is needed or if some aren't. In the network payload, I have our SCEP Proxy as the identity certificate. For "username" field, I have $COMPUTERNAME so that when it hits clearpass I see the computer name. Then on the trust tab, I have the "Trusted Server Certificates Name" set with our Clearpass certificate CN. I'm not really sure if all of this is proper, but, we did go from getting timeouts in the activity monitor on clearpass, to rejected authentications.

Now here's where my knowledge is falling real short and I need the guidance the most:

On the Clearpass side, our normal windows machines basically authenticate with an authentication method of "EAP-TLS", and the authentication sources are 3 of or domain controllers, and clearpass is joined to them in AD. That all makes sense.

But, when authenticating these Macbooks, I get failures because it can't authenticate via the domain controllers. That makes sense, because as far as I know, although our certificates are issued to the macbooks by our windows CA, since the macbooks aren't domain joined, it's not like our AD servers will HAVE knowledge of our certificates that get presented by the macbooks. So I'm trying to understand exactly what the Clearpass would look like, to do this authentication. Do I need to perhaps import our NDES cert into clearpass? I can see that being a possibility but then what would my "authentication source" be? It would have to be local somehow then, right? Or, am I supposed to be trying to get these non-domain macbooks' certificates somehow into AD so that when we bounce the auth off of our AD servers, it knows how to do that?

We're currently on 6.9.13, and are in the middle of renewal of our support contract. Once that's done, we'll be upgrading to 6.11, and at that point we can probably install the Jamf Clearpass connector, but I don't know if that's a required feature, or just gives some nice abilities.

Can anyone paint me a picture of what I'm really looking to do, on the Clearpass side, to get these authentications working, given the above? If I knew the concept well enough, I think I could move forward and maybe have some luck, but right now the clouds are just too thick to see what I'm looking to do.

Thanks for any guidance you can provide.

Best answer by RVTim

I wanted to follow up and provide info in this post now that we have solved this issue and are actively authenticating macbooks via clearpass. Hopefully this will be helpful for others as they do similar processes.

On the Jamf side, you have to have all of the previous SCEP server implementation portion working, or whatever you use to get the machine certificates issued and applied to the macbook. Then, you create a new configuration profile for the network.

For EAP-TLS you want to choose "Computer Level" in the level dropdown.

 



 

 

 

 

 

 

 

 


Then, you need to make sure you have the proper certificate payloads in the Certificate payload section.  We have 3 of them in ours:  The root cert, an intermediate cert, and I'm not sure why but another copy of the root.  This portion was done by someone before I did my portion of the integration.  I did not scroll and screenshot all 3.

 

 

 

 

 

 

Then you have to set up the network payload.  Give it an SSID, and more likely than not, you will want to disable MAC address randomization, depending on your environment.   With our environment, leaving mac randomization active would wreak havoc because we have certain portions of the authorization that are based on the mac-address of the macbook.  Make sure you choose WPA2 Enterprise, or perhaps WPA3 if you're running that.

 

 

 

.

.

As you get down to the EAP types, select TLS.  I don't know that the username field is necessarily required, but, by putting $COMPUTERNAME in the username field, the activity monitor logs on clearpass will show the computer's name in the username field, so it's handy for troubleshooting and log viewing.   For identity certificate, you want to choose your SCEP proxy certificate.

.

 

.

.

After completing the network tab, it is important to click over to the TRUST tab as well.  Here you can select under trusted certificates, the root, and the sub cert.  One other very important thing (ours would not work without this) is to add under "Trusted Server Certificate Names" the hostname of the clearpass server(s) as they appear in their certificates.  Our CN on the clearpass server cert for example, was something like  "Clearpass.ourcompany.com" and so you need to add that as a trusted server certificate name here in Jamf.  When we did not have this here, all we would get on clearpass in activity monitor was a bunch of timeouts as it tried to authenticate.

.

.

 

.

.

Save that network payload, and then go to the SCEP payload and make sure your cert stuff is filled in here as well.  I didn't do this portion of the integration, but hopefully this will make sense to you when you get there.

.

.

.

.

That's what we needed on the Jamf side.  Now for the Clearpass side.  Checking your certificate store, you need to make sure your server certificate has the right CN= name that I referenced above in the SCEP/Network payloads.  So if your clearpass server cert says the CN=clearpass.yourcompany.com, make sure that's what you have under the trusted servers in the jamf trust tab under the network profile. 

.

.

 

.

.

Now here's one of the big areas where I got stuck, not knowing exactly how this would look for a non-Active Directory configuration with non-Windows machines.  When I started my process, in clearpass, I cloned my regular 802.1X EAP-TLS service that we were using to authenticate windows machines using machine certificates, and authorize them as well, and assign their VLANs.  The problem is, we were using the same "AUTH METHOD" that we were using for the windows machines: EAP-TLS, except if you open the actual EAP-TLS method setting, we had the "Authorization required" box checked, because you could do that with AD integration for authorization.  These macbooks are NOT AD joined, so we had to remove that checkbox, which means, clone your EAP-TLS method in the auth method config area, and create a new one just for doing these machines, but without that checkbox for "authorization required" checked.

.

.

 

.

.

 

 

 

 

 

 

 

 

 

.

.

Then, once you're back in the authentication session's main page, you can have the EAP-TLS method that you just cloned, chosen in the top section.  One issue we faced was that since I cloned this service, we  had multiple AD servers chosen on the lower half, as "Authentication Sources", so that a few of our AD servers could authenticate them.  Those were causing failures when authenticating macbooks that weren't AD integrated, because when the macbook would attempt connection, it would look in AD for the machine info and not find it, and authentication would fail.  I didn't realize I could just leave the whole list of sources empty, and people I had been hearing from on the aruba forum were saying basically that "you just need the server cert to authenticate it", and that didn't really explain it, but it did get me to consider removing them and then it indeed worked.   I had been wondering what other source I could create/use, but it turns out you don't need one.

.

.

 

 

.

So it was a learning curve, not having AD to deal with, and not really understanding where all these various certificates get placed, and what you're authenticating against.  It's actually much simpler than I had originally thought, but without a good overview to read, it leaves you banging your head on the whole conceptualization of this process.

At present, we aren't using the jamf connector in clearpass, so we do trigger some of the service properties on specific things, to provide a little more security.  For instance, the macbooks need to be in a local mac address list in clearpass, which is used to determine which service to use.  We did that so that the windows machines wouldn't get hung up trying to authenticate using the macbook/jamf service.  In the authorization part of the clearpass service service config, we have some specific values that the machine must have populated in it's authentication request, in order for it to be allowed on the network.  For instance, if you don't have the proper AV software installed by the proper vendor, configured with a few settings we use at our company, you don't get on the network.  Additionally, it checks to make sure there are no viruses currently being detected by AV.  Things like that can make it so that no machine that isn't owned by your company, and configured as per your org's requirements, won't get on even if they found a way to get a cert installed.

I have a feeling we can even do a bit more, once we get the jamf connector installed, at a later date.  For now, it feels great to have this working, and Jamf has helped secure our org better than using PEAP would, where we would have to worry about man-in-the-middle certificate attacks and username/password compromises.  Hope this helps anyone else doing this type of integration.

 

 

 

 

 

    tender

    5 replies

    agungsujiwo
    Forum|alt.badge.img+8
    • agungsujiwo
    • Contributor
    • February 17, 2025

    Hi @RVTim ,

    We have implemented WPA/WPA2 Enterprise using ClearPass and Jamf. The required certificate is a CPPM certificate, which needs to be included in the configuration profile.

    To create the Wi-Fi Configuration Profile:

    1. Add a Certificate payload and upload the CPPM certificate.
    2. Add a Network payload and configure the following settings:
      • Protocol: Set to PEAP.
      • Authentication: Enter the username and password.
      • Identity Certificate: Select the CPPM certificate.
    3. Under Trust settings:
      • Enter the username and password.
      • Select the Identity Certificate (CPPM certificate).
      • Set Outer Identity to PEAP.
      • Add Trusted Certificates and enable Allow Trust Exceptions if needed.

    If your MacBook is already connected to the Wi-Fi network, you can find the CPPM certificate in the Keychain Access app. You can export and save the certificate, then upload it to Jamf for deployment.

     

     

    Shyamsundar
    R
    Forum|alt.badge.img+5
    • RVTim
    • Author
    • New Contributor
    • February 17, 2025

    Hi @RVTim ,

    We have implemented WPA/WPA2 Enterprise using ClearPass and Jamf. The required certificate is a CPPM certificate, which needs to be included in the configuration profile.

    To create the Wi-Fi Configuration Profile:

    1. Add a Certificate payload and upload the CPPM certificate.
    2. Add a Network payload and configure the following settings:
      • Protocol: Set to PEAP.
      • Authentication: Enter the username and password.
      • Identity Certificate: Select the CPPM certificate.
    3. Under Trust settings:
      • Enter the username and password.
      • Select the Identity Certificate (CPPM certificate).
      • Set Outer Identity to PEAP.
      • Add Trusted Certificates and enable Allow Trust Exceptions if needed.

    If your MacBook is already connected to the Wi-Fi network, you can find the CPPM certificate in the Keychain Access app. You can export and save the certificate, then upload it to Jamf for deployment.

     

     


    Thanks.  That is basically mirroring what I'm being told on the ClearPass forum as well.  The only thing is, your example speaks to using PEAP, which is what we have been doing.   We're looking to use that certificate for EAP-TLS, for machine authentication.   I believe really the only difference in this case is that we uncheck the PEAP box in the Protocol selection, but we check the TLS box.   Then, we don't need a username and password combo, however, it may be that we need to put something like $COMPUTERNAME in the username box.  Or maybe it just isn't required.

    I'm not sure if we'll need to allow trust exceptions or not, but I should know once we get to test it again.

    At any rate, it's getting closer at least.

    R
    Forum|alt.badge.img+5
    • RVTim
    • Author
    • New Contributor
    • Answer
    • February 19, 2025

    I wanted to follow up and provide info in this post now that we have solved this issue and are actively authenticating macbooks via clearpass. Hopefully this will be helpful for others as they do similar processes.

    On the Jamf side, you have to have all of the previous SCEP server implementation portion working, or whatever you use to get the machine certificates issued and applied to the macbook. Then, you create a new configuration profile for the network.

    For EAP-TLS you want to choose "Computer Level" in the level dropdown.

     



     

     

     

     

     

     

     

     


    Then, you need to make sure you have the proper certificate payloads in the Certificate payload section.  We have 3 of them in ours:  The root cert, an intermediate cert, and I'm not sure why but another copy of the root.  This portion was done by someone before I did my portion of the integration.  I did not scroll and screenshot all 3.

     

     

     

     

     

     

    Then you have to set up the network payload.  Give it an SSID, and more likely than not, you will want to disable MAC address randomization, depending on your environment.   With our environment, leaving mac randomization active would wreak havoc because we have certain portions of the authorization that are based on the mac-address of the macbook.  Make sure you choose WPA2 Enterprise, or perhaps WPA3 if you're running that.

     

     

     

    .

    .

    As you get down to the EAP types, select TLS.  I don't know that the username field is necessarily required, but, by putting $COMPUTERNAME in the username field, the activity monitor logs on clearpass will show the computer's name in the username field, so it's handy for troubleshooting and log viewing.   For identity certificate, you want to choose your SCEP proxy certificate.

    .

     

    .

    .

    After completing the network tab, it is important to click over to the TRUST tab as well.  Here you can select under trusted certificates, the root, and the sub cert.  One other very important thing (ours would not work without this) is to add under "Trusted Server Certificate Names" the hostname of the clearpass server(s) as they appear in their certificates.  Our CN on the clearpass server cert for example, was something like  "Clearpass.ourcompany.com" and so you need to add that as a trusted server certificate name here in Jamf.  When we did not have this here, all we would get on clearpass in activity monitor was a bunch of timeouts as it tried to authenticate.

    .

    .

     

    .

    .

    Save that network payload, and then go to the SCEP payload and make sure your cert stuff is filled in here as well.  I didn't do this portion of the integration, but hopefully this will make sense to you when you get there.

    .

    .

    .

    .

    That's what we needed on the Jamf side.  Now for the Clearpass side.  Checking your certificate store, you need to make sure your server certificate has the right CN= name that I referenced above in the SCEP/Network payloads.  So if your clearpass server cert says the CN=clearpass.yourcompany.com, make sure that's what you have under the trusted servers in the jamf trust tab under the network profile. 

    .

    .

     

    .

    .

    Now here's one of the big areas where I got stuck, not knowing exactly how this would look for a non-Active Directory configuration with non-Windows machines.  When I started my process, in clearpass, I cloned my regular 802.1X EAP-TLS service that we were using to authenticate windows machines using machine certificates, and authorize them as well, and assign their VLANs.  The problem is, we were using the same "AUTH METHOD" that we were using for the windows machines: EAP-TLS, except if you open the actual EAP-TLS method setting, we had the "Authorization required" box checked, because you could do that with AD integration for authorization.  These macbooks are NOT AD joined, so we had to remove that checkbox, which means, clone your EAP-TLS method in the auth method config area, and create a new one just for doing these machines, but without that checkbox for "authorization required" checked.

    .

    .

     

    .

    .

     

     

     

     

     

     

     

     

     

    .

    .

    Then, once you're back in the authentication session's main page, you can have the EAP-TLS method that you just cloned, chosen in the top section.  One issue we faced was that since I cloned this service, we  had multiple AD servers chosen on the lower half, as "Authentication Sources", so that a few of our AD servers could authenticate them.  Those were causing failures when authenticating macbooks that weren't AD integrated, because when the macbook would attempt connection, it would look in AD for the machine info and not find it, and authentication would fail.  I didn't realize I could just leave the whole list of sources empty, and people I had been hearing from on the aruba forum were saying basically that "you just need the server cert to authenticate it", and that didn't really explain it, but it did get me to consider removing them and then it indeed worked.   I had been wondering what other source I could create/use, but it turns out you don't need one.

    .

    .

     

     

    .

    So it was a learning curve, not having AD to deal with, and not really understanding where all these various certificates get placed, and what you're authenticating against.  It's actually much simpler than I had originally thought, but without a good overview to read, it leaves you banging your head on the whole conceptualization of this process.

    At present, we aren't using the jamf connector in clearpass, so we do trigger some of the service properties on specific things, to provide a little more security.  For instance, the macbooks need to be in a local mac address list in clearpass, which is used to determine which service to use.  We did that so that the windows machines wouldn't get hung up trying to authenticate using the macbook/jamf service.  In the authorization part of the clearpass service service config, we have some specific values that the machine must have populated in it's authentication request, in order for it to be allowed on the network.  For instance, if you don't have the proper AV software installed by the proper vendor, configured with a few settings we use at our company, you don't get on the network.  Additionally, it checks to make sure there are no viruses currently being detected by AV.  Things like that can make it so that no machine that isn't owned by your company, and configured as per your org's requirements, won't get on even if they found a way to get a cert installed.

    I have a feeling we can even do a bit more, once we get the jamf connector installed, at a later date.  For now, it feels great to have this working, and Jamf has helped secure our org better than using PEAP would, where we would have to worry about man-in-the-middle certificate attacks and username/password compromises.  Hope this helps anyone else doing this type of integration.

     

     

     

     

     

    K
    agungsujiwo
    Forum|alt.badge.img+8
    • agungsujiwo
    • Contributor
    • February 20, 2025

    I wanted to follow up and provide info in this post now that we have solved this issue and are actively authenticating macbooks via clearpass. Hopefully this will be helpful for others as they do similar processes.

    On the Jamf side, you have to have all of the previous SCEP server implementation portion working, or whatever you use to get the machine certificates issued and applied to the macbook. Then, you create a new configuration profile for the network.

    For EAP-TLS you want to choose "Computer Level" in the level dropdown.

     



     

     

     

     

     

     

     

     


    Then, you need to make sure you have the proper certificate payloads in the Certificate payload section.  We have 3 of them in ours:  The root cert, an intermediate cert, and I'm not sure why but another copy of the root.  This portion was done by someone before I did my portion of the integration.  I did not scroll and screenshot all 3.

     

     

     

     

     

     

    Then you have to set up the network payload.  Give it an SSID, and more likely than not, you will want to disable MAC address randomization, depending on your environment.   With our environment, leaving mac randomization active would wreak havoc because we have certain portions of the authorization that are based on the mac-address of the macbook.  Make sure you choose WPA2 Enterprise, or perhaps WPA3 if you're running that.

     

     

     

    .

    .

    As you get down to the EAP types, select TLS.  I don't know that the username field is necessarily required, but, by putting $COMPUTERNAME in the username field, the activity monitor logs on clearpass will show the computer's name in the username field, so it's handy for troubleshooting and log viewing.   For identity certificate, you want to choose your SCEP proxy certificate.

    .

     

    .

    .

    After completing the network tab, it is important to click over to the TRUST tab as well.  Here you can select under trusted certificates, the root, and the sub cert.  One other very important thing (ours would not work without this) is to add under "Trusted Server Certificate Names" the hostname of the clearpass server(s) as they appear in their certificates.  Our CN on the clearpass server cert for example, was something like  "Clearpass.ourcompany.com" and so you need to add that as a trusted server certificate name here in Jamf.  When we did not have this here, all we would get on clearpass in activity monitor was a bunch of timeouts as it tried to authenticate.

    .

    .

     

    .

    .

    Save that network payload, and then go to the SCEP payload and make sure your cert stuff is filled in here as well.  I didn't do this portion of the integration, but hopefully this will make sense to you when you get there.

    .

    .

    .

    .

    That's what we needed on the Jamf side.  Now for the Clearpass side.  Checking your certificate store, you need to make sure your server certificate has the right CN= name that I referenced above in the SCEP/Network payloads.  So if your clearpass server cert says the CN=clearpass.yourcompany.com, make sure that's what you have under the trusted servers in the jamf trust tab under the network profile. 

    .

    .

     

    .

    .

    Now here's one of the big areas where I got stuck, not knowing exactly how this would look for a non-Active Directory configuration with non-Windows machines.  When I started my process, in clearpass, I cloned my regular 802.1X EAP-TLS service that we were using to authenticate windows machines using machine certificates, and authorize them as well, and assign their VLANs.  The problem is, we were using the same "AUTH METHOD" that we were using for the windows machines: EAP-TLS, except if you open the actual EAP-TLS method setting, we had the "Authorization required" box checked, because you could do that with AD integration for authorization.  These macbooks are NOT AD joined, so we had to remove that checkbox, which means, clone your EAP-TLS method in the auth method config area, and create a new one just for doing these machines, but without that checkbox for "authorization required" checked.

    .

    .

     

    .

    .

     

     

     

     

     

     

     

     

     

    .

    .

    Then, once you're back in the authentication session's main page, you can have the EAP-TLS method that you just cloned, chosen in the top section.  One issue we faced was that since I cloned this service, we  had multiple AD servers chosen on the lower half, as "Authentication Sources", so that a few of our AD servers could authenticate them.  Those were causing failures when authenticating macbooks that weren't AD integrated, because when the macbook would attempt connection, it would look in AD for the machine info and not find it, and authentication would fail.  I didn't realize I could just leave the whole list of sources empty, and people I had been hearing from on the aruba forum were saying basically that "you just need the server cert to authenticate it", and that didn't really explain it, but it did get me to consider removing them and then it indeed worked.   I had been wondering what other source I could create/use, but it turns out you don't need one.

    .

    .

     

     

    .

    So it was a learning curve, not having AD to deal with, and not really understanding where all these various certificates get placed, and what you're authenticating against.  It's actually much simpler than I had originally thought, but without a good overview to read, it leaves you banging your head on the whole conceptualization of this process.

    At present, we aren't using the jamf connector in clearpass, so we do trigger some of the service properties on specific things, to provide a little more security.  For instance, the macbooks need to be in a local mac address list in clearpass, which is used to determine which service to use.  We did that so that the windows machines wouldn't get hung up trying to authenticate using the macbook/jamf service.  In the authorization part of the clearpass service service config, we have some specific values that the machine must have populated in it's authentication request, in order for it to be allowed on the network.  For instance, if you don't have the proper AV software installed by the proper vendor, configured with a few settings we use at our company, you don't get on the network.  Additionally, it checks to make sure there are no viruses currently being detected by AV.  Things like that can make it so that no machine that isn't owned by your company, and configured as per your org's requirements, won't get on even if they found a way to get a cert installed.

    I have a feeling we can even do a bit more, once we get the jamf connector installed, at a later date.  For now, it feels great to have this working, and Jamf has helped secure our org better than using PEAP would, where we would have to worry about man-in-the-middle certificate attacks and username/password compromises.  Hope this helps anyone else doing this type of integration.

     

     

     

     

     


    Is your PEAP still running, and can EAP-TLS work alongside it, or must you choose one over the other?

    Can this also be applied to iPads?

    R
    Forum|alt.badge.img+5
    • RVTim
    • Author
    • New Contributor
    • February 20, 2025

    Is your PEAP still running, and can EAP-TLS work alongside it, or must you choose one over the other?

    Can this also be applied to iPads?


    Yes, we still do have PEAP running, until we can get each MacBook into Jamf.  They can work alongside each other.  I am not positive but I would be willing to wager that this could also apply to iPads.  
    The way we currently have the 2 services for EAP-TLS and PEAP in clearness, we have a local host list in clearness for each group, PEAP and EAP-TLS, with the Mac addresses of the PCs that we want to use each service in separate lists.  So the service only applies first to MacBooks with Mac addresses in the EAP-TLS MacBook list.  Those would be in Jamf today.   Then, the next service down in the list is the one that does PEAP, and that has its own Mac address list.  So if a machine is in that one, it will use that service, and require PEAP.   So you could definitely use them simultaneously.   Then below those are the services for windows PCs, wired and wireless, to use EAP-TLS.  We have a service first that looks for requests coming from wireless APs that will do EAP-TLS on the PCs, and another service that looks at requests coming from our switches with EAP requests (because we do NAC on our switch ports), to allow PCs on the wired network as well.   It's pretty nice.  These days we can know that someone can't simply walk in the building and plug into our network and access anything at all, because the port simply won't work at all unless they have a company certificate AND a few other requirements.   Nothing is un-hackable I'm sure, but this is definitely a step in the right direction compared to what I've seen in my last 25 years of networking.

     

    Terms & ConditionsCookie settingsAccessibility statement