Security

Hi All,

 

Another clearpass question from me...

 

I've got onoboarding setup and tested it using iPads and android devices. Both android and iPad devices go through the onboarding process and reconnect and gain entwork access, however the iPads don't appear to be using the onboard repository.

 

When an onboarded android authenticates you can see the user in the format <ad username>:#:mdps_generic. I can see in the access tracker that it's authentication source is [Onboard Devices Repository] and if I delete the device from the onboard device list, I'm promoted the re-onboard.

 

Now here's the issue. When I connect my ipad after onboarding I get the following in the access tracker:

 

Service:	cppm-onboard Onboard Provisioning
Authentication Method:	EAP-TLS
Authentication Source:	AD:domaincontroller.domain.local
Authorization Source:	RAS AD
Roles:	[Employee], [User Authenticated]
Enforcement Profiles:	[Allow Access Profile], cppm-onboard Onboard Post-Provisioning
Service Monitor Mode:	Disabled

 

If I delete the onboarded iPad device, the iPad can still connect.

 

I seem to have provisioned the device against AD rather than against the onboarded device repository. Not sure how. :smileyfrustrated:

 

Can someone point me in the right direction?

 

Thanks

James

The iPad is authenticating with a certificate (EAP-TLS) rather than a unique username and password like the Android onboarding process.   Despite it showing AD as the authentication source, the certificate is on CPPM.   Where do you delete the onboarded iPad device?

 

Also, check how your EAP-TLS authentication method is setup?    Is it using OCSP to verify whether the cert is valid?   If it is, it should detect a deleted/revoked certificate and not allow access.

I was expecting to see all onboarded devices authenticate and show in the access tracker as "<username>:#:mdps_generic".

I was looking in the onboard devcie section under identity on CPPM, that's where I deleted the device. That makes no difference for an IOS device.

 

Have had a dig around and can see the certificate on the Onboard + Workspace section.

Thanks Clembo. 

I've had customers say/do the same thing.   The common name of the certificate issued to the clients is based on the username entered in the onboarding process (usually their AD name).   The mdps_generic name given to Android's does not follow that same behavior, thus the difference seen in Access Tracker.  

 

If you delete revoke/delete the certificate, it should remove the device from the Onboard Device list.   

 

You could also make the presence in the Onboard Devices repository a condition of yoru role assignments, that way if it is deleted there (but not within the CA), you can still controll access.   

 

Gotcha. Thanks for the info Clembo.

Hey,

 

I am seeing similar behavior.

 

I was messing around with the service templates. I wanted to compare what they generated to what we are using. That is when I noticed that the '[Onboard Devices Repository]' was being used as the 'Authentication Source' in the Enforcement Policy.

 

I then went and checked authentication requests coming in from already Onboard devices and noticed that none of them are reporting the '[Onboard Devices Repository]' as the authentication source. I was even able to remove '[Onboard Devices Repository]' from the authentication tab of the service and everything kept functioning.

 

If I delete/revoke the certificate the device will not be able to authenticate.

This includes both Android and Apple devices.

 

What you decscribe Clembo makes sense.

 

I should have been paying closer attention!

 

Is this at all related to how you set the 'Key Type' under ClearPass Onboard > Onboard + Workspace > Deployment and Provisioning > Provisioning Settings > <Your profile> > General Tab?

 

I have seen had issues in the past with this setting and what type of information gets sent during an authentication request.

 

Cheers

 

Hi all,

 

I am facing the same issue. I have deleted client certificate from onboard. But he is still able to authenticate and get the acccess to the network.

 

I understood that in EAP-TLS method, I didnt enable OSCP pr OSCP url.

And in certificate authority , we said do not include OSCP responder URL.

 

So its not checking the validity of the certificate.

 

Are above things are making iOS device to get onto the network???

 

Thanks & Regards

Srikanth Soogoor

Unless ocsp is enable the client will be able to get online

So i have to include ocsp in CA.

And also in EAP-TLS method ri8?

 

Thanks

Srikanth Soogoor

If the ocsp is in the cert from the CA the client should reject itself. If you have CPPM check ocsp and you have local host as the address it will look in its repository for cert/client validity

Can you explain me how to do check in cppm

 

Cheers

Srikanth Soogoor

 

I'm traveling so i can't send you a screen shot so if someone else could post one that would be great.

You will need to in you Auth method copy tls with ocsp and put in either the direct address or local host.

Is this what you're looking for?

 

You may also want to give this thread a read.

tarnold provides some great information in it!

 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/IOS-devices-can-connect-after-certificate-has-been-revoke/m-p/58710/highlight/true#M6534

Ya.. i am looking for the same .

But my doubt is ... i didn't included ocsp with url responder in certificate issuing.

If i enable override ocsp url from client....hows it going to work ?

 

Do i have enable ocsp with url in certificate issuing and in eap-tls authentication method??\\

 

Please find the attachments

I think Troy explained it pretty well in this thread: http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/IOS-devices-can-connect-after-certificate-has-been-revoke/m-p/58710/highlight/true#M6534

 

From Troy's post:

 

"override ocsp url from client. and what that does is give you the option to force ocsp to the location you designate. In a subscriber model you can tell the server where to check for the revocation. Either itself buy using the default Local host where the server will look at itself or a specified address which you can get by looking at the root CA in the certificate section."

 

So if you enable this option and enter "http://localhost/guest/mdps_ocsp.php/1" as the URL Clearpass will check the validity of the certificate.

 

It doesn't matter if you didn't include OCSP responder URL as you can force it to check by doing the above anyway.

 

I hope this helps.

 

-James

I had spoken to an Aruba tech about where to place the OCSP URL and he recommended to place it in the EAP-TLS method as if can offer more flexibility. So as the other's have said not having it in the certificate is okay.

 

I was wondering if anyone knows if you can provide more then one OCSP URL in the client override option?

You can only have one per service auth method, but you could trigger a different service based on the cert properties.

Hmm that is interesting.

The triggering of a service based on cer properies is interesting and could be useful!

What would the service look like as I don't see any options under the 'Service' tab that refer to the certificate properies?

 

When I had spoken with the Aruba tech. they were unsure if you could provide multiple OCSP URL's.

Thank you for clearing that up!

 

I just looked and remembered that you can only use the cert properties in a role/enforcement.

What is the reason for multiple OCSP address?

Fair enough :smileyhappy:

I was afraid that I had once again missed something obvious!

 

We have a single service that does all our of user authentication for a specific SSID.

We have two types of a users that hit this service, we have our users who are from the offices that are local and then our users who visit from overseas.

 

We created two separate certificate authorities within Onboard to make it easier to filter out devices/users.

Currently we have modified the OCSP URL inside the CA so the OCSP check hits the correct CA.

 

After speaking with Aruba and having it suggested that it is probably a better solution to do the override through the EAP-TLS method we started investigating how this could be done.

 

The end goal was to eventually simply the services by splitting them apart.

None of this is a necessity.

I am mainly trying to make sure that our configuration is as good as it can be and easy to follow.

 

Thank you,

 

Cheers