Security

Reply
Super Contributor II
Posts: 383
Registered: ‎09-05-2012

Endpoints database and the Available Attributes

Hey,

 

I have been spending a lot of time on the forums lately and have seen a lot of talk about the use of Endpoint attributes for Enforcement evaluation. This is something that I am familar with and I am using it currently.

 

When I look at the list of attributes that are available by default there is a large list which contains things like: OS Version, OS Type, Device Type, Device Vendor, etc.

  Aruba_Endpoint_Info.png

 

In the upper rigth corner of the screenshot above there is some information about the device. To my knowledge you cannot use this information to evaluate the device with the exception of the 'MAC Vendor' as it is an item that shows up in the devices request (according to the Access Tracker).

 

My question, I think, mainly refers to the attributes in the bottom left of the screenshot above. These attributes mainly seem to get populated only when you Onboard a device. For instance, I Onbarded a Windows 7 laptop and the attribute 'Device Type' appeared with 'Windows 7 Service Pack 1'. I have not seen many other attributes populated automatically though. 'OS Version' and 'OS Type' I don't think I have ever seen populated. So I was wondering what process, or what feature, has to happen/be enabled in order to populate these attributes. Ideally it would be nice to see them populated automatically. Currently we are doing a lot of the populating manually.

 

We do have DHCP finger printing working.

I was thinking that perhaps some of the information could come from the Audit Servers - NMAP? Since NMAP has the capability to detect OS.

 

If someone could help shed some light on this I would greatly appreciate it.

 

Cheers

Guru Elite
Posts: 20,553
Registered: ‎03-29-2007

Re: Endpoints database and the Available Attributes

Whatever attribute you add manually to an Endpoint in the Endpoint Database can be used in role mapping later to make a decision.  Below I add a Colins-Favorite-Color attribute and make it green in a station's properties in the Endpoint Database:

1.png

 

I can then use a role mapping condition referencing that endpoint attribute in my service.  Any custom attribute I add, becomes a dropdown that is usable when I create a role mapping that begins with "Endpoint".

 

2.png

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Super Contributor II
Posts: 383
Registered: ‎09-05-2012

Re: Endpoints database and the Available Attributes

@cjoseph

Thank you for your response.

I was aware that we could add custom attributes and that we can then use them later to do role mapping and other things. This is definitely a great option to have.

 

I was more curious about the attributes that already exist by default. Since they exist in the CPPM by default there is intent for them to be used, I am just not sure if the intent was to have them populated manually (an admin adds a value) or for them to be populated by some other means.

 

Cheers

Guru Elite
Posts: 20,553
Registered: ‎03-29-2007

Re: Endpoints database and the Available Attributes

[ Edited ]

The upper right attributes like MAC Vendor Can be used in Role Attributes, as well, using Authorization:Endpoints Repository.  I hope that is what you mean...

 

1.  The custom attributes in the dropdown that you have seen, probably have been added as a result of Onboarding adding a custom attribute to at lest one endpoint

2.  The Attributes in the Upper right Can also be used in Role Attributes

3.  You can also use IF-MAP to port the HTTP User Agent Strings and mDns Broadcast info from the controller into ClearPass (more than just DHCP fingerprinting):

 

6.3 release notes:

 

5.png

 

 

 

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Guru Elite
Posts: 8,169
Registered: ‎09-08-2010

Re: Endpoints database and the Available Attributes

The attributes at the top right are generated from the profiling process
which includes MAC OUI, DHCP fingerprinting and http header analysis.

Generally when the "profiled" status is yes, those attributes should be
there.

Tim Cappalli | Aruba ClearPass TME
@timcappalli | ACMX #367 / ACCX #480 / ACEAP / CWSP
Guru Elite
Posts: 20,553
Registered: ‎03-29-2007

Re: Endpoints database and the Available Attributes

[ Edited ]

bourne wrote:

@cjoseph

Thank you for your response.

I was aware that we could add custom attributes and that we can then use them later to do role mapping and other things. This is definitely a great option to have.

 

I was more curious about the attributes that already exist by default. Since they exist in the CPPM by default there is intent for them to be used, I am just not sure if the intent was to have them populated manually (an admin adds a value) or for them to be populated by some other means.

 

Cheers


Bourne,

 

Just to show you what can be done when you turn on IF-MAP on the controller:  I attached one iPad to the controller before turning on Ifmap, then I turned on IF-Map and attached another:

1.png

 

One is just classified as an IOS device:

2.png

 

The second is actually classified as an iPad:

 

3.png

 

IfMAP will send more granular information about your devices from your controller to CPPM, without onboarding for devices that share the same DHCP fingerprint like an iPad and an iPhone.

 

It will also pass on user-agent information, all without onboarding.

 

4.png

 

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Super Contributor II
Posts: 383
Registered: ‎09-05-2012

Re: Endpoints database and the Available Attributes

Hey guys,

 

Thanks a ton for the responses! The 'IF-MAP' feature was something that I was totally unaware of. It looks like it offers a more pin point finger print of what the device really is. Sounds like a great feature that I am definitely going to investigate and enable.

 

I just wanted to clarify on what I was trying to ask as I don't necessarily think I did such a good job on it.

 

Currently we use a custom attribute that is added to company owned Windows laptops. We do this to identify which devices have full access to our production network. Then in one of our Enforcement Profiles we use it to evaluate the user request. In order for a user to be allowed onto the wireless the request must come from a device which has this custom attribute (among other things).

 

When I look at the Event Viewer log I can see this attribute appear under the 'Computed Attributes' 

Endpoints_0001.png

 

If I look at the rest of the 'Computed Attributes' I do not see any of the other attributes/parameters generated by DHCP FP that are available in the Endpoint Profile of the device itself. Below is a screenshot of the Endpoint Profile for the device which is being used to make an authentication request.

Endpoints_0002.png

 

We do not Onboard these devices. We use EAP-PEAP to authenticate them.

 

If I look at the values that are available from the drop down list for 'Attributes' 

Endpoints_0003.png

I have marked the attributes that were added by us. Everything else in this list was already there. I believe this appears in the CPPM by default. These attributes are available to be evaluated in either your Role Mapping rules or in Enforment Policies.

 

Here is a shot from just an example Role Mapping rule

Endpoints_0004.png

 

Okay so hopefully I am not completely making this confusing up until this point. I thin I am having a hard time explaining what's going through my head :(

 

We say that we can use the values that are computed via DHCP finger printing, HTTP analysis, etc. to evaluate requests. I have been under the impression that we can only use values that actually show in the client request (show in the Event Viewer). So if we go back the screenshot of the client request above, there is no value that tells me what the Operating System is for exmaple. But we have a parameter from DHCP FP which is 'OS Family' = 'Windows' in the Endpoint Profile.

 

And if we look at the Attributes in the drop down list the ones that would identify the OS for example might be 'OS Version' or 'OS Type'.

 

But in the values available from the DHCP finger printing there is no parameter called 'OS Type'. There is however 'OS Family'. So does 'OS Type' = 'OS Family'? 

 

But even if it did, I don't think I could evaulate it because it isn't a 'Computed Attribute' contained within the Client Request. Because technically in the Endpoint Profile for the device the attribute hasn't been defined.

 

It would seem that when the attribues are 'computed' only attributes that have been defined in the 'Attributes' section of the Endpoint Profile can be used to do evaluation. The one exception to this (at least to me at this point) is the 'MAC Vendor' which can be evaluated using 'Connection:Client-Mac-Vendor'.

 

So to refine my original question. I don't think I am fully following how we can use the parameters generated by the DHCP FP, HTTP analysis, etc to evaluate a client request (with the exception of the 'MAC Vendor'). Aruba provides us a list in the drop down menu of the values that we can evaluate, we can add custom values, which great. But values generated by DHCP FP do not seem to be available.

 

Sorry for the long winded explanation! As I started to read your responses and go over my original question I started realizing maybe I didn't ask it correctly.

I don't think I did a much better job either, but hopefully I helped a little. There is probably something I am not getting!

 

Thanks again!

 

Cheers

Guru Elite
Posts: 8,169
Registered: ‎09-08-2010

Re: Endpoints database and the Available Attributes

[ Edited ]

Do you have the [Endpoint Repository] [Local SQL DB] as an additional authorization souce in your service policy? You can only make policy decisions from computed attributes that are available from authentication and authorization sources in the service.

 

cp_authorization-endpoint.PNG

 

 


Tim Cappalli | Aruba ClearPass TME
@timcappalli | ACMX #367 / ACCX #480 / ACEAP / CWSP
Guru Elite
Posts: 20,553
Registered: ‎03-29-2007

Re: Endpoints database and the Available Attributes

Bourne,

 

The Endpoint user repository is a list of device attributes, by mac address.  You can turn on Machine Authentication on your domain machines, and CPPM will store a custom role of [MACHINE AUTHENTICATED] that you can always use to evaluate along with user authentication to validate a machine.  For devices that are non-domain, you can simply add an attribute manually to the device's entry in the endpoint repository and combine that with user authentication for elevated privileges, or onboard those devices that have not machine authenticated.

 

Endpoint attributes are normally collected after the device does DHCP (fingerprinting) or after the device opens an http conversation (user agent).  Both attributes can ONLY be collected after initial authentication, so you cannot collect them realtime during authentication to make a decision; it is stored information from a previous connection.

 

To be truly secure you can deploy EAP-TLS using autoenrollment through a combination of group policy and onboarding for non-domain devices.  The only thing you would be checking is the validity of the certificate and you can also check the status of the computer or user account that would be attached to that certificate.  

 

Long story short, don't put yourself through the trouble of checking tons of attributes when maybe EAP-TLS and/or machine authentication would be the simpler solution.

 

 

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Super Contributor II
Posts: 383
Registered: ‎09-05-2012

Re: Endpoints database and the Available Attributes

@cappalli

 

I confirmed that I do NOT have [Endpoint Repository] [Local SQL DB] in the Authorization list!

As soon as you mentioned it you sparked a bunch of thoughts in my head. This could definitely explain

a few things. I unfortunately am no longer at work and will have to wait until tomorrow to do a test. I will get testint first thing in the morning. If this is the thing that I am missing then I feel like a complete moron because it is very obvious having seen it!

 

Thank you sir.

 

@cjoseph

 

I 100% agree that perhaps the role [MACHINE AUTHENTICATED] is better to use.

At the time we initally developed our rules doing machine authentication was not possible. We do not have AD and were having problems getting machines to authenticate against our OpenLDAP. Eventually we discovered what we were doing wrong, but this was much later after we built the rules.

 

I follow you with regards to the attributes and when they are collected! And I have see it first hand as well through testing.

 

I would agree that EAP-TLS is the better way to go. We have been avoiding Onboarding company owned laptops because we do not want to consume an Onboard license. But we still wanted to maintain some control over what devices were able to connect.

 

That being said it might be a good time to re-evaluate how we are authorizing company owned laptops/computers and see if there is a better more straight forward way of doing it.

 

I definitely appreciate your feedback! Thank you!

 

 

Cheers

Search Airheads
Showing results for 
Search instead for 
Did you mean: