Security

As you know we used to have the rule in the early 6.0 releases where you could check for device conflict. 

 

In 6.4 that feature has been re-enabled.

 

• Conflict triggers

–Fingerprint from same source changing over time resulting in two different device profiles

• Profiled as Computer, but assigned MAC address of a Printer
• If old category and new category differ, conflict flag set to TRUE

–Fingerprint from different sources resulting in two different device categories

• Profiled as Computer from DHCP but SmartDevice from HTTP
• Profiler will check fingerprint dictionary to resolve disparity
• If device category different from dictionary, conflict flag set to TRUE

• Additions to tips_endpoint_profiles

–conflict (boolean)

–other_category (varchar(100))

–other_family (varchar(100))

–other_name (varchar(100))

• These are available as authorization attributes

 

 

 

 

 

great, nice to see it return.

Hi,

 

If there is a Conflict the MAC Auth doesn't fail automatic or ? I still need to put in a Rule in my Enforcment or ?

 

Rule would be like:

 

Conditions:

Authorization:[Endpoints Repositroy]:Conflict EQUALS true

 

Actions:

[RADIUS_CoA] [Aruba Terminate Session]

 

thanks a lot

Martin

Your logic is correct. You will need to put it at the top of your enforcement. Personally I would create a captive portal role to tell the user why they cannot connect or they will just keep trying to connect then call the help desk.

In 6.5 (shipping later this month) we will have the ability to trigger an automatic CoA when we detect a conflict.

things just get better :)

Has this feature been added? If so, how do you incorporate it in your guest MAC authentication service for instance?

you should be able to use the device conflicat category and based on that assign a different role or perform some other action.

i tried getting a device in conflict status last week, but were unable to make it work. using version 6.5.4 btw.

 

i first connected with a windows laptop, was profiled correctly, fingerprint clear. then i reboot with a linux boot usb and again it was profiled correctly, only nothing showed up for conlict or such in the endpoint repository.

 

as both were main category computer it might not have been enough to trigger the conflict, would be nice if we get some more details on how it exactly works, so i also changed the MAC address of the laptop of that of a Thinclient and tried to auth. again this auth worked fine, the entry in the end point repository was updated with the linux computer hostname, but no conflict.

 

so anyone got this working (the case with DHCP finger print as method, not difference between HTTP en DHCP method) and can provide some more information on your setup?

 

as a side note it is mentioned we can do a CoA on conflict, but i don't see the category conflict on the profiling tab. i also assume i don't need the profiling tab in the service to get the conflict status enabled on the end point repository.

If you had changed it to something like a printer, the conflict should have been activated.

Sent from Nine

ok, so it triggers only on main category changing? if i have printer profiled and take that MAC address for my laptop and let it auth then it should trigger?

Hi,

I just test the feature, and i get a strange behavior....

I connect my tel cisco and it is profiled with the DHCP finger print.

After wait 5 minutes i disconnect the tel Cisco IP.

After that, I connect my Win8.1 laptop, (with the same MAC Adress of my TEL IP Cisco), now in the endpoint, it detect the conflict, but the value of the conflict attribut still "false" (in the access tracker)

For me, at this step, the vlaue of the conflict would be "TRUE" ! Could you tell me more ?

 

Regards

 

Yann

I had some time to test today and experienced the same Yann, but i believe i understand why.

 

i also took an ipphone and authed it. waited a while, unplugged it and connected my laptop with the MAC of the ipphone and it authed fine. when i looked in the endpoint respository i saw the the conflict. eventhough it was both done based on DHCP fingerprint (i don't use IF-MAP or something else).

 

but the auth had gone through fine. if i look at the tracker it still showed conflict=false and all old details for the request. when i tried again (disconnect laptop and connect again) it was flagged as conflict and my reject profile triggered.

 

this makes sense. the fingerprint in the endpoint repository is only updated after the device has passed authentication and does the DHCP request. so the first auth request with the "fake" client will always go through, there isn't much to do about this i believe.

 

so it does work for me in 6.5.4 only not as well as hoped, but well can't have it all :)

 

as a solution you could consider short reauth times.

 

personally i had hoped for an option in the profiling tab for the conflict category perhaps with a second delay or such. i also hope we might be able to trigger on any chance of fingerprint, would still like to know if my computer with windows suddenly becomes a linux system. sure there might be logical reasons, but it is detected i can choose what to do.

hi boneyard,

 

it's a good explanation of the mode of operation, I had already had a return of Aruba on this.

 

Thanks lot

 

Yann