I've been unable to find this in any of the CP docs.
Assume I have MobileIron as an endpoint server and endpoints in the repository. Do I just need a single service with auth method EAP-TLS and auth source Endpoints Repository or is there more to it?
This one? TechNote_ClearPass_MDM_Integration_V2
Yes, used it get CP and MDM talking, but no mention of the required service config.
Here is an example of what I have running in my lab.
A. Add the root cert of the server that is signing the devices TLS cert B. Allow OCSP to the server that is signing the certs if the device will check to see if the cert is revoked or deleted
4. I'm only checking Employee and Staff users in AD devices for MDM that is why the Students are different.
5. In CPPM 6.4 you can even send a Message to the mobile deivice through you enforcement profile and it will send it to Mobileiron via clearpass exchange.
A. Is the user in the employee group in my AD B. Did the device authenticate with TLS C. Is it not a device that can be MDM managed (laptop, Desktop, ETC)
A. Is the user in the employee group in my AD B. Did the device authenticate with TLS C. Is the device Rooted or Jailbroken D. Is the device managed by MDM
6. Is it an employee in AD and isn’t managed by MDM or have a TLS cert
7. Same as 4 but for Staff Users in AD 8. Same as 5 but for Staff Users in AD 9. Same as 6 but for Staff Users in AD 10. Is a student and authenticates with a TLS cert 11. Same as 6 but for Students users in AD
Endpoint Screen Shot
Thanks Troy, kudos for you.
Can you post your Authentication tab for this service?
So still a bit unsure of the minimum required auth source here.
Is it the Onboard Devices Repo? I assumed this was only use with Onboard not an an MDM.
you only need your AD to auth the user
Could you provide the screenshot for Employee-ExpireCert Profile please?
So this is a pretty basic question I realise, but why would AD be involved in authentication?
I would have thought the certificate itself is the authentication if it is signed correctly. Perhaps some attributes of the cert can be accessed and queried in AD but this would be an authorisation function.
All the certificate is, is a means to securely present your user credentials. You will still need the AD to authenticate the username that is presented by the cert.
It wasn't initially clear how this worked, but after a couple of days in the lab it makes sense.
I took the MDM out of the equation and just focused on the CA. The bit that was missing from my understanding is how (in an MS environment) the certificate is issued to a domain member and clearpass uses the UserDN to auth - whether it's a User or Computer.
Still a couple of issues, but I will post separate if needed.
@tarnold wrote:All the certificate is, is a means to securely present your user credentials. You will still need the AD to authenticate the username that is presented by the cert.
Would it be fair to say that the certificate itself is a credential? My customer only uses machine certificates and therefore the AD lookup is disabled. CPPM is not configured in any way to communicate with AD.
If the machine presents a valid and trusted cert, then they can connect.
> Would it be fair to say that the certificate itself is a credential? My customer only uses
> machine certificates and therefore the AD lookup is disabled. CPPM is not configured in
> any way to communicate with AD.
To split hairs about it, the AD part of the authentication is actually step 2.
Step 1 of the authentication is the fact you accepted the certificate. By defintion a message that can be decrypted with a public key must have been encrypted by whomever had the private key. If you can read the message and you trust the CA of the cert you've already authenticated them.
Step 2 is authenticating an attribute of the cert against AD. Depending on the context this could be considered authorization not authentication. For example if you want to allow any cert on the network but apply a special role to certs belonging to AD users.
The clearpass way of doing things doesn't makes these distinctions clear. For example it would make sense to have an authentication source that is a list of trusted CAs for this service. Instead there is a global trust list and an implicit authentication of the cert.
So Chris what are you using as an authentication source for your service, given you have to have something in there?
Yes, I guess I would consider the AD integration part to be "Authorisation". As you are using an attribute to make a policy decision, post authentication.
If I recall correctly, I found that I had to modify the default EAP-TLS 'Authenticaton Method' and untick 'Authorisation'. This allowed me to have NO Authentication Source in the service.
I struggled with this for a while.
The customer only needed basic authenitcation, no authorisation. If you have a valid cert then you can connect.
I know it works on both wireless and wired dot1x, I often see some strange clent certificates from non SOE devices that are presented to CPPM, these are denied auth (which is to be expected).
> If I recall correctly, I found that I had to modify the default EAP-TLS 'Authenticaton Method' and
> untick 'Authorisation'. This allowed me to have NO Authentication Source in the service.
Wow, disable authorisation to allow basic authentication, that is confusing. It is kind of an admission that the AD part is authorisation though :)
>The customer only needed basic authenitcation, no authorisation. If you have a valid cert then you can connect.
Great, hopefully this thread helps someone who needs the same. Again this would make more sense if the CA trust list was an authentication source.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.