Security

Is it possible to use the Onboard feature to distribute certificates that would be host based and not user based.  Specifically the certificates should be:

1) named for the machine being onboarded (not the user doing the onboarding) 

2) be installed in the local computer certificate store (not the user's store)

3) be presented by the computer for EAP-TLS authentication when machine authentication happens (before the user logs in) 

 

We already have the certificate authority setup and are using Onboard to issue certs and provision devices with certs tied to the user identity (specifically the user that authenticates to the onboard page), those certs get installed in the users certificate store, and get presented for EAP-TLS when the user logs into the machine.    That is all working fine, but that doesn't meat the requirements of some of the use cases we have, and we would like to be able to use a similar process to do the same thing to issue machine certs to be used for wireless authentication.  

 

Any ideas or is this beyond the scope of what Onboard can do?  

Are these managed or unmanaged devices?

Managed, but by other organizations in our business.   They actually belong to multiple other domains.  

Ok, made some progress but am at a sticking point.  I have an Onboard page setup to attempt to issue device certs.   It's a copy of the service that I am using to Onboard users with user certificates.  The "User" onboard works exactly as I would like.   It creates a cert called "username" and puts it in the users certificate store and provisions the machine to present that user certificate for EAP-TLS whenever that user logs in.  Both the "User" onboarding page and the "Device" onboarding page have username and password authenticaton so I can control WHO can onboard a machine. 

 

The problem is that the "device" page takes the username used to authenticate and uses that as the name for the certificate and installs it in the local machine certificate store.  

 

So instead of having a certificate called "hostname" in machine certificate store that is presented when the machine does machine authentication.  I have a certificate called "username" that is in the local machine certificate store.   So when the machine attempts to do machine authentication using EAP-TLS the access tracker shows a username of "host/username" instead of "host/hostname"   

 

I can't figure out how to control how the certificate fields get populated, specifically the CN= field.   There is a way to select "Custom Fields" in the "web login" portion of the Provisioning Settings for this Onboard service.   But there is no option to pick the hostname as one of those fields.   And I'm not sure how I would make that get populated into the certificate.  

Onboard provisioning is not designed for machine identity certs.

How are these devices being managed?

It varies. Some are members of an AD domain that has its own CA setup. Most are either members of AD domains that do not have a CA, and are not in the same forest. Many are Linux or Macs that don’t belong to any domain. I’m going to trust the admins in those other business units to approve devices for onboarding (we will have to set an attribute in the endpoints database before they can be onboarded).

Unfortunately I didn’t get to shop for the groceries. I just have to prepare the meal.

Machine identity can only be used when it is actually attested to, like an EMM enrolling on behalf of the machine.

Please excuse my ignorance here and thanks for your help.  Do you truly mean "can only be used" or "should only be used" when attested to?   

 

In my case I'm not trying to use any automated means to attest to the machines worthiness for onboarding, if we had EMM in place this would be much easier.   I'm using the process of trusting the other domain admins to attest to it being OK to onboard a particular advice.  Is that not possible? Or just inadvisable?  or just a matter of what risk we are willing to tolerate in that process?  

 

Assisted Onboarding is for end users to self-enroll which results in a device-bound user identity. Assisted Onboarding does not issue certificates with machine identities.

Is there some other capability in clearpass that we could use to automatically distrubute machine based certs?   

 

Is there a way to make the clearpass CA functionality itself available to admins that I want to allow to generate CSRs for machines that I would later use for EAP-TLS?   Something short of giving them access to the clearpass management website?

 

I know I can manually generate certs that match hostnames, export them, distribute them to admins who then install them on devices and configure the devices to use them for machine authentication, but that doesn't scale well.   

SCEP, EST and the REST API are available and can all be used to programmatically request certificates.

Ok.  Would that be explained in the Onboard Documentation?   Thats beyond my capabiltiy but I can point others there.

 

Back to the machine vs. user certificate issue, I just want to make sure I understand the options in the Onboard > Network settings.   When you go to network settings and go to the Authentication section and select "machine" for the certificate store on a windows device, the intent of that is to place a user's certificate in the local machine store?  So when the device goes through machine authentication it will present whatever user onboarded that machine's certificate for EAP-TLS, and then when the user (say a different user) logs in afterwards it might present a different user cert for user autethentication?   That seems odd.   It seems like you could end up with a machine certificate store that is full of a bunch of different users certificates.   How would it determine which to present for machine authentication?  

 

That is simply the storage of the certificate. Putting a certificate in the machine store does not make it a machine identity certificate. The reason those knobs exist are for personal devices where the user may have more than 1 local account. Since the cert is ultimately a user < > device bound cert, it often makes sense to put it in the machine/system store for global use.

Ok.  Thanks for all your help.   

 

We will have to try something else.