Hi All,
I am hoping somebody might be able to shed some light or offer some suggestions on the following. This is quite complex, so apologies for the length of the post!
I am working with a customer where we already have the following components in place.
- Aruba controllers (x2) specifically for VIA clients (remote access) (AOS6.4.4.8).
- Aruba controllers (x4) specifically for internal wifi (AOS6.4.4.8).
- Clearpass (v6.6)
- Airwatch on-premisis (not cloud) (v8)
- Fully functioning AD
- Corporate issued laptops and iPhones for users
In terms of WORKING/TESTED operational aspects, the following is in place.
- Laptops and users doing EAP-TLS across wired, wifi and VIA. The laptops and users exist in AD.
- Clearpass RADIUS certificate is issued by AD, and laptop/user certs delivered directly via AD GPO. So everything trusts everything so far and is happy.
- Corporate issued iPhones are enrolled in Airwatch, and are cross populating into the Clearpass endpoint repository (context server etc. all setup and working).
- Corporate issued iPhones are issued certificates by Airwatch, which in this case is a subordinate/intermediate of the AD CA.
- Corporate issued iPhones working across wifi doing EAP-TLS. Again, this is ok at a basic level because Clearpass and iPhones were all issued certificates by the same CA, and they all trust each other.
- OCSP also working from Clearpass point of view.
The specific challenge I’m facing is as follows.
Working off the initial success with working laptops/users, we made the iPhones work on internal wifi, by simply adding the endpoint repository to the wifi authentication service (within the authentication services). From what I can see, this was fairly trivial in that the wifi authentication of course contains the mac address of the device, and the cert CN as the username. Clearpass trusts the iPhone certificate and vice versa, so that bit is fine and the outcome is what we need (we can build interesting TIPS etc.).
I then moved on to get the iPhone working with VIA, and hit an interesting problem. The first relevant observation in terms of VIA authentications into Clearpass, is that the RADIUS request from the controller embeds a client MAC address of “000000000000” (because it’s a layer 3 connection). This is fine regarding the laptops and AD users, because with AD set as an authentication source, the cert CN can be found in AD as an “object”. However, with the iPhones in Airwatch (having set the endpoint repository as a second authentication source), it’s different. Specifically, we need to bear in mind the iPhones DON’T exist in AD (this is corporate policy and won’t change). The iPhone relevance to AD is only in terms of the fact that Airwatch “fetched” a certificate from AD for the phone to use. What appears to happen with the endpoint repository default filters (which we haven’t changed yet), is that the search is predominantly leveraging the MAC address (in this case all-zeros). And the Airwatch iPhones in the repository as you’d expect exist with their real MAC addresses as the “primary” identifier (not sure on terminology here). As a result, what you get in the access tracker is “can’t find user” in either AD or the endpoint repository. I performed a quick experiment to prove the my theory, where I added a “spoof” endpoint with an all-zeros MAC into the repository. This worked, in that the iPhone VIA connection using EAP-TLS succeeds and you can do normal TIPS things with it as a result.
The concern I have is I don’t want to leave it like this, because it doesn’t feel right from a security perspective. What would be better, is if the RADIUS username was legitimately “found” by Clearpass during the authentication. The RADIUS username of course being the same as the certificate CN, which is in fact contained within the endpoint entries (gathered from Airwatch). It’s within an attribute in the endpoint named “Username”. In our perfect world, we’d also want to check the endpoint “Ownership” was marked as “Corporate”. That way, we couldn’t be wrong about the iPhone being legitimate (we can sort out TIPS aspects later, but I need to “find” information first). It strikes me this might be possible by adding to or altering the SQL filters on the endpoint authentication source, but if I do this I must be sure the changes don’t affect “normal” wifi-guest implementation considerations (which will also be leveraging mac-caching, and be configured later in the project).
So my question is, is it possible to create an SQL filter to do this, and would anybody care to suggest how I’d write it? I’m not an SQL expert.
In the course of researching this prior to posting, I’ve reviewed a lot of the tech notes and VRDs. The vast majority I’ve reviewed (lost count of which ones) discuss wifi authentications with nothing regarding VIA. This is all fine, I guess I’m just pointing out that I can’t find a “best practice” or “template” solution for this. Have I missed something? As an example, the following thread touches on the subject…
http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/SQL-Query-of-Airwatch-Endpoint-attributes/td-p/228103
However, having tried that approach I got a number of errors thrown up in Clearpass when trying to add the filters and it didn’t work. The errors were regarding the syntax, implying that “tips_endpoints_attr_view” doesn’t exist. This made me think the post is out of date???
Any thoughts gratefully received! Kudos if somebody suggests a filter change that works of course.